The friction nobody warns you about
Point an agent at a CRM built for a sales rep and watch what happens. It signs in through a shared service account, because the platform never built a real identity for anything other than a human with a password. It fills out a lead form through cascading dropdowns designed for a mouse and a monitor. It gets rate-limited or blocked outright, because the platform's bot detection exists to stop repeated, machine-speed requests, which is exactly what the agent produces. None of this is theoretical. It's what happens the first week anyone tries to wire an agent into Salesforce, Hubspot, WordPress, or any system built over the last fifteen years on one quiet assumption: a person is clicking the buttons.
That assumption doesn't hold anymore for a growing slice of daily software use. A small but real set of teams have stopped patching around it and started building for the other kind of user instead.
Software built for a different kind of user
Comp AI's CRM is a plain example. It's open source, and its maintainers describe it as agent-first rather than human-first with an API bolted on afterward. The difference shows up once you look closely. Each agent gets its own scoped identity instead of sharing a login, so a write can be traced back to the specific agent and task that made it, instead of showing up as an anonymous change from "the integration." The primary interface is a documented schema an agent can read and call directly, instead of a page it has to guess its way through by parsing rendered HTML. Permissions run narrow by default too: an agent that updates deal stages doesn't automatically get the power to delete contacts, the way a human admin login usually does without anyone deciding it should.
None of that is exotic engineering. It's what a system looks like once you stop assuming the reader of your interface has eyes and a mouse, and start designing for something that reads structured data and calls structured actions instead.
The part that needs real care: write access
Reading data is the easy problem. Writing to a production database is where agent-native design earns its keep or fails badly. dbward is built around a specific failure mode: an agent with direct write access to production is one bad decision away from a customer seeing wrong data, or a record getting deleted with no clean rollback. So instead of handing an agent a database credential and hoping, dbward puts a diff between the agent and the database. The agent proposes a change, dbward turns it into a reviewable diff, and a human has to approve it before anything runs against production.
That design has a real tradeoff worth naming plainly. If every write needs a human to click approve, the review step shifts downstream, from doing the task to checking the task. Whether that's still a win depends on how much of the review load can shift toward auto-approval for low-risk changes, leaving real escalation for anything touching billing or customer-facing content. I haven't seen public numbers on that split yet. What would change my mind here: seeing that ratio in practice. If low-risk writes clear on their own and only the risky ones queue for a human, the approval layer is doing real work. If most writes still stack up for review regardless of risk, the bottleneck just changed shape.
Content systems that draft instead of type
Microfeed applies the same shift to a CMS. It's open source and runs on Cloudflare, and it showed up on Hacker News as a content system built from the start for an agent to operate. Building on Cloudflare's edge stack matters for a specific reason here. A human visitor loads a page once and reads it for a few minutes. An agent drafting and revising a post makes dozens of small calls in quick succession: checking a draft, verifying an edit took effect. That pattern rewards low latency and cheap compute at the edge far more than it rewards a rich-text editor built for someone clicking through a toolbar.
Across these three projects, the pattern repeats: an identity per actor instead of one shared login, and a schema an agent can call instead of a page it has to parse. Review sits where the risk is, not spread evenly across every action.
Where the rebuild doesn't pay off yet
None of this means every CRM or CMS a team runs today needs replacing this quarter. If agent-issued writes are still a small fraction of total activity in a given system, tearing out working software for an agent-native rebuild won't clear its cost. The math changes the day agent-issued writes start to make up the majority of what happens inside a system, the day the permission model and the audit trail turn out to have been built for a kind of user that no longer accounts for most of the traffic there.
At Isotropic, we see both cases inside the same client's stack. Some systems get an integration layer in front of software that stays otherwise unchanged: scoped agent identity, and an approval gate modeled on dbward's pattern for the writes that carry real risk. Other systems, the ones an agent touches dozens of times an hour rather than once a day, get replaced outright with something built agent-first from the schema up. Which path fits depends on which kind of user is doing most of the work inside that system right now.
FAQ
Frequently asked questions
What makes software 'agent-native' instead of just having an API?
Agent-native software treats an AI agent as the primary user, not a human clicking through a browser. Each agent gets its own identity so a write can be traced to the specific agent and task that made it. The main interface is a documented schema an agent can call directly, instead of a page it has to parse. Permissions stay narrow by default too, so an agent that updates one field doesn't automatically get power to delete records.
Why do platforms like Salesforce or HubSpot break when you connect an AI agent to them?
These platforms were built over the last fifteen years on one assumption: a person is clicking the buttons with a mouse. An agent signs in through a shared service account because there's no real identity built for anything but a human with a password. It fills out forms through dropdowns designed for a monitor, and it can get rate-limited or blocked outright because bot detection exists to stop the repeated, machine-speed requests an agent produces.
How does dbward let an AI agent write to a production database safely?
dbward puts a diff between the agent and the database instead of handing over a direct credential. The agent proposes a change, dbward turns it into a reviewable diff, and a human has to approve it before it runs against production. That protects against a bad decision causing wrong data or a deletion with no clean rollback. The tradeoff is that review work shifts downstream unless low-risk changes can clear on their own and only high-risk writes queue for a human.
When does it make sense to rebuild a CRM or CMS instead of just adding an integration layer?
If agent-issued writes are still a small share of activity in a system, replacing working software isn't worth the cost yet. An integration layer, scoped agent identity plus an approval gate for risky writes, can sit in front of the existing system instead. The math changes once agent-issued writes make up most of what happens inside that system, because the permission model and audit trail were built for a kind of user that no longer accounts for most of the traffic. At that point a system an agent touches dozens of times an hour benefits from being rebuilt agent-first from the schema up.