Agent-native systems

What is an agent-native system?

An agent-native system is built so that software can read it and act in it, not only a person clicking a screen. The screen stays and people keep using it. The difference is that everything the screen can do also exists as something a machine can call, under names that survive a release, with output a program can parse and a login that belongs to the agent rather than to an employee.

It is a property of an interface, not a product category. The same accounting package can be agent-native for reading invoices, because a documented API exists for that, and completely shut for approving them, because approval only exists as a button. Where the screen came first and the API was bolted on afterwards, the two drift apart and the agent ends up with the half nobody maintains.

Five things that make a system usable by an agent

1. A way in that is not the screen. A documented API, a command line tool, a file drop in an agreed format. Operation and field names survive a release, so code written last quarter still runs.

2. Output a program can parse. A JSON object with a declared shape, not a paragraph of prose and not a PDF. MCP lets a tool publish an outputSchema and requires the server to return results that match it. An agent that has to read a sentence to find a number will eventually read the wrong number.

3. Errors that say what to do instead. The MCP specification separates a malformed request from a failed one, and says an execution error should "contain actionable feedback that language models can use to self-correct and retry with adjusted parameters". Its own example is Invalid departure date: must be in the future. An agent can act on that. It cannot act on Error 500.

4. Operations that are safe to retry. Networks time out and agents retry. Stripe's answer is an idempotency key: the client sends a unique key with the request, Stripe stores the result of the first call under it, and a repeat with the same key returns that stored result instead of creating a second object. Without something like it, one dropped connection becomes one duplicate payment.

5. Permissions that belong to the agent. Google defines a service account as "a special kind of account typically used by an application or compute workload" rather than by a person, to be granted the minimum permissions it needs. Microsoft's Entra Agent ID extends the same idea to agents: an agent gets its own identity in the directory, plus a sponsor, the human who is accountable for it. The gain is boring and large: you see what the agent did, and you can revoke it without locking a colleague out.

The same job through an API and through the screen

A supplier sends a monthly statement, and 40 invoices in your accounting package have to be marked paid with the payment reference attached.

Through an API the agent asks for that supplier's open invoices in one filtered call, then sends 40 updates, each carrying an idempotency key. Every response comes back structured, so it knows per invoice whether the update worked. One was already settled last week and the API says so by name and reason, so the agent skips it and reports it. That is seconds of work and 41 calls. The failure mode is speed: if the filter is wrong, the mistake reaches all 40 records before anyone notices. The answer is a dry run, a cap on how many records a run may touch, and a person signing off the batch.

Through the screen the agent searches the supplier, opens an invoice, clicks Mark paid, types the reference, saves, goes back, and repeats that 40 times. Every step is a screenshot and a model call, which is why computer use is counted in minutes and per-step cost rather than in API calls. It also needs a real user session, so the audit log records that a colleague did all of it. The failure mode arrives from the vendor: a release moves Mark paid into an overflow menu, and the click next to the one the agent wanted is Mark disputed.

That is the fair dimension to compare them on: what happens when the vendor ships a change. On an API the change comes with a version. Stripe ships breaking changes as named major versions, keeps the monthly ones backwards-compatible, and lets you pin what you built against with a Stripe-Version header. A screen has no version to pin and no changelog for a button.

An API change arrives with a version number and a date. A screen change arrives on a Tuesday, and the first thing that tells you is a wrong result.

What a vendor has to add beyond an API

Having an API is the entry ticket. Three more things decide whether an agent gets useful work done with it.

A machine-readable description of the operations. OpenAPI is the common form, and version 3.2.0 from September 2025 puts the goal plainly: humans and computers should be able to "discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic".

Granularity that matches a business action. Anthropic's engineering guidance on writing tools for agents is direct about this: build a schedule_event tool rather than making the agent chain list_users, list_events and create_event. Wrapping an API one endpoint to one tool is the mistake, because every extra round trip costs context the agent does not have to spare.

Paging and limits you can plan around. Cursors rather than offsets, a truncation message that says how to narrow the search, and a rate limit that is documented rather than discovered.

The standard shape for the last mile in 2026 is MCP, an open protocol on JSON-RPC 2.0 where a server offers resources for data, prompts for templated workflows, and tools a model can execute, current revision 2026-07-28. It gives you discovery, schemas, the error split and paging in one form across vendors. It does not give you a good system underneath, and the spec says outright that "MCP itself cannot enforce these security principles at the protocol level", so consent and access control stay your job. Stripe shows the assembled version: next to the REST API sit an MCP server, maintained agent skills, and a stripe agent setup command that configures the coding agents it finds.

What this means if you buy software rather than build it

Most companies never design an agent-native system. They buy one, or fail to. The question collapses into four things you ask a supplier before you sign.

• Can this be driven without a human session, and through what: an API, a CLI, a supported MCP server, or nothing?

• Is that in the licence we are quoted, or in a higher tier or a per-call price?

• Which operations can we write, not only read? Read access is common. Write access is where the automation lives.

• Can we create a separate identity with its own permissions and rate limit, or does the agent sign in as one of our staff?

Put the answers in the contract rather than the meeting notes. The systems holding your orders, your hours and your invoices set the ceiling on what you can automate. A process touching four systems where three are reachable only by a person stays a process with a person in it, whatever tooling you buy on top.

What to watch out for with agent-native systems

An API does not make a product agent-native. Undocumented endpoints, one call per field, error 500 on a bad date and no test account are an API an agent will fail on. Ask to see the reference and a sandbox before you believe the feature list.

Every door you open for an agent is a door. A wider surface for your agent is a wider surface for a hijacked one, and instructions hidden in an incoming mail or a supplier document are the usual way that happens. A tool's own account of what it does is not evidence either: MCP clients "MUST consider tool annotations to be untrusted unless they come from trusted servers", which is the ground tool poisoning stands on.

This is about systems, not about your company. Whether your suppliers' software can be driven by a machine is a different question from whether your organisation is an AI-native enterprise. A traditional company with agent-native systems automates more than an ambitious one with locked software.