Build software for agents, not just humans
Tun KelteschPublished
Most business software has two kinds of users today: people in a browser or an app, and other systems calling an API. A third kind is arriving. An employee asks Claude, ChatGPT or Cursor to "log last week's supplier invoices" or "close the tickets that were fixed in the last release", and the agent does it by calling your software directly.
For a company that builds or runs software, the practical question is which of your products and internal tools should an agent be able to use, and what has to be true inside them first.
How agents reach software
The common route is the Model Context Protocol (MCP), an open standard for describing the actions a system offers ("list invoices", "create ticket") so any compatible agent can call them. One server then works with many different agents. The protocol is maintained in the open; its current version is dated 28/07/2026, and the maintainers report "close to half-a-billion downloads a month" across the main SDKs (both checked 26 September 2026).
Many tools your teams already use publish an official server. Checked on each vendor's documentation on 26 September 2026:
| Product | What an agent can do | Controls the vendor documents |
|---|---|---|
| Stripe | Read and write payments data | Agent-specific keys; human approval via a link for refunds and outbound payments |
| GitHub | Repositories, issues, pull requests | OAuth or personal token, a read-only mode |
| Sentry | Errors and issues | Scoped to one organisation or project |
| Notion | Read, create, update pages | Workspace owners can see and revoke connections |
| Qonto | Business banking, read and write | OAuth |
| Linear | Issues and projects | OAuth or API key |
Two numbers on usage, both from the companies themselves. When Databricks announced it was acquiring Neon, it wrote that agents had gone from 30% to over 80% of the databases created on the platform; Neon sells to people building with agents, so that figure describes its own market. Anthropic's Economic Index of September 2025 found that 77% of business use through its API showed automation patterns, where the model completes a task instead of helping a person do it.
The protocol is the small part
Putting an MCP server in front of an existing system is a modest amount of code. The official SDKs handle the transport, and in our experience a first read-only tool runs within a day. The work that decides whether agent access is safe to switch on sits inside the product.
The rule we start from: an agent can never do anything the same person could not do in the app. It may do less. That rule is cheap to keep when the agent's tools call the same internal functions the app calls, with the same permission checks. It gets expensive when agent access is bolted onto the outside and re-implements permissions in a second place, because the two copies drift apart the first time someone changes one of them.
Writes are where the engineering goes
Reading data through an agent carries privacy risk but rarely breaks anything. Writes can: an agent that misreads "delete the duplicate" can remove the wrong record at machine speed.
When we built agent access for one of our own products, most of the effort went into four things around writes.
Confirmation before every write. The server instructions and each write action's description tell the agent to act only after the user has confirmed that exact change. Actions are labelled as read-only or destructive in a standard way, so clients such as Claude Code and ChatGPT show their own approval prompt. A preview action computes the result on the server, so the numbers the user approves are the numbers that get saved.
A history of every write, from every client. Each change records who made it, whether a person or an agent, which agent, the reason the agent gave, and full before-and-after snapshots. The part that took longest was logging human writes from the app too. Without them, the system cannot tell whether a person edited a record after the agent did, and an undo would silently overwrite that person's work.
Time-boxed undo. An agent's change can be reversed for a limited window. Undo is refused when someone else has touched the record since, and a group of changes made in one request reverses together or not at all.
Scoped, expiring credentials and a switch per action. Tokens are separate from app logins, stored only as hashes, limited to read or write, and they expire. Each action has its own on/off setting, so one can be withdrawn without a deploy, and a missing setting counts as off.
Where it breaks, and when it is premature
Confirmation depends on the client. Several agent tools have an auto-approve mode, and once a user turns it on, nothing the server says forces a prompt. Stripe's answer for high-risk actions is an approval link a human must open, valid for 24 hours. The other answer is history and undo, and at that point rollback is the safety mechanism that actually holds.
Prompt injection is unsolved. Simon Willison's "lethal trifecta" describes the dangerous combination: an agent with access to private data, exposure to text someone else wrote, and a way to send data out. Two incidents show it in practice. Invariant Labs reported in May 2025 that a malicious public GitHub issue could steer an agent into leaking private repository data. General Analysis reported in July 2025 that text in a Supabase support ticket steered an agent running with an all-access key into copying a private table back into the ticket. Any field your users fill in, a ticket title or a customer note, can carry instructions to someone else's agent.
The foundations are still moving. The July 2026 protocol version broke compatibility with earlier ones. Anthropic's engineering team published a different way for agents to call tools that cut one example from 150,000 tokens to 2,000. What you build now will need revisiting.
Demand can be thin. For many products, the people asking for agent access are a handful of developers. Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027. If your customers never ask and your staff do not use agents, a read-only pilot for internal use is the sensible scope.
Data also leaves. When a user connects an AI provider, whatever the agent reads goes to that provider. For records that include other people's personal data, that is a GDPR question to settle before the first external user connects.
What to check first
In roughly this order:
- Does every write go through one place? If the app, the admin panel and the API each change data their own way, agent access inherits all three. Fix this first.
- Pick a few actions, reads first. Start with what people ask for most, usually lookups and reports. Add writes one at a time.
- Decide what needs human approval. Reversible, low-value changes can run on confirmation in chat. Money movements and deletions deserve a separate approval step.
- Log before you allow writes. Actor, source and before-and-after state, for humans and agents alike.
- Build undo, with conflict checks.
- Issue agent credentials of their own. Scoped, expiring, revocable, never the master key. The MCP security guidance forbids passing other tokens through, and Stripe will stop accepting full-access secret keys on its server from 31 October 2026.
- Treat every user-written field as untrusted in what you return to an agent.
For the business case behind it, see why your software should work with AI agents.
We build this kind of agent access into existing products and internal tools. If you are weighing it for yours, write to us.