A model cannot do anything. It reads text and produces text. Every action an agent appears to take — booking the meeting, raising the invoice, updating the record — happens because something turned that text into an API call.
Which means the interesting engineering question has quietly moved. Not which model, but what it can reach and how well.
The capability ceiling is your endpoints
Swap a good model for a better one and an agent gets somewhat smarter. Give it access to a system it could not previously touch and it can do something it fundamentally could not do before.
Those are different magnitudes of change, and teams consistently over-invest in the first.
The practical consequence is that agent capability is bounded by API surface. If your billing system has no API, no model will ever update a subscription, regardless of how clever it becomes. The ceiling is architectural, not cognitive.
This is why organisations with mature internal APIs are getting results from agents while organisations with the same models and better engineers are not. The difference was decided years earlier, by whether anyone insisted that internal systems expose interfaces.
APIs designed for humans fail agents specifically
Most APIs were built for a developer who reads documentation, understands the domain, and writes deliberate code. Agents violate all three assumptions, and the failures are consistent.
Chatty endpoints. A workflow needing six sequential calls is fine in code and poor for an agent — each round trip is context consumed and another opportunity to lose the plot. Endpoints that complete a whole job in one call perform dramatically better.
Ambiguous naming. A developer reading docs works out what /v2/entities returns. An agent choosing between getEntity, fetchRecord, and lookupItem with terse descriptions picks somewhat randomly.
Unhelpful errors. 400 Bad Request tells an agent nothing actionable, so it retries the same call. An error naming the offending field and the expected format gets fixed on the second attempt.
Enormous responses. Returning ninety fields when the agent wanted three burns context and buries the answer. Sparse responses with explicit field selection matter far more than they used to.
Fig. — The model is the reasoning. The API is everything that actually happens.
What changes in how you design them
Write descriptions as instructions, not documentation. "Returns order data" is a docstring. "Look up a customer's orders when they ask about delivery status or a refund. Requires an email or order ID." tells a model when to reach for it. That sentence does more for reliability than most code changes.
Design endpoints around intent. Humans compose primitives; agents do better with endpoints shaped like the job — rescheduleAppointment rather than a fetch, a delete, and a create that must happen in order and cannot be half-done.
Make idempotency explicit. Agents retry. They retry after ambiguous failures, after timeouts, and sometimes because they lost track. An endpoint that creates a duplicate order on retry will create duplicate orders. Idempotency keys stop being a nicety.
Return machine-readable errors. A code, a field, and a corrective hint. This single change measurably improves agent success rates, because most agent failures are recoverable errors that were described uselessly.
Think about permission granularity. An agent should hold credentials scoped to its job, which is only possible if your API supports scopes narrower than "full access." Many do not, and that gap is why so many deployments run over-privileged.
The integration you cannot buy your way out of
There is a tempting shortcut: skip the API work and let an agent drive the user interface instead. Computer-use models can click through screens, and for systems with genuinely no programmatic access that is sometimes the only option.
It is worth knowing what you are accepting. UI automation is slower by an order of magnitude, breaks whenever the vendor moves a button, and produces no clean audit trail — you get screenshots, not structured records of what changed. It also inherits whatever session the automation runs under, so permission scoping largely disappears.
Use it as a bridge for the one legacy system nobody will ever modernise. Do not build a strategy on it. Teams that treat UI automation as equivalent to an API discover the difference during the first vendor update, usually at the worst moment.
The more durable move is unglamorous: work out which systems genuinely lack an API, and treat closing that gap as the project rather than a prerequisite to the project.
The operational shift nobody planned for
Traffic patterns change in ways that break assumptions built around human usage.
Agents are bursty. A human browses at human pace; an agent fires twenty calls in two seconds, then nothing for an hour. Rate limits tuned for interactive use throttle legitimate agent work while doing nothing about the actual abuse case.
Usage-based pricing gets stranger. If your API is priced per call and the caller is a loop, a customer can generate a bill nobody intended. Spend caps and clear per-key limits move from nice-to-have to necessary, for their protection and yours.
And observability needs to answer a new question. Not just what was called, but on whose behalf and as part of which task — because when something goes wrong, "the agent did it" is not an answer anyone accepts.
Internal APIs get judged by a new standard
Most of this discussion assumes a public API, but the sharper impact lands internally, and it exposes something uncomfortable.
Internal APIs are usually built with the knowledge that the only consumers sit two desks away. Documentation is thin because you can ask. Naming is inconsistent because each team named things their way. Error handling is casual because the caller will read the logs. None of that mattered when every consumer was a colleague.
An agent has no colleague to ask. It reads the description, makes a choice, and lives with the consequence. The internal API that has quietly worked for five years because everyone knew its quirks becomes the one an agent uses incorrectly, repeatedly.
The teams moving fastest with agents are, almost without exception, the ones who had already been forced into disciplined internal interfaces for some other reason — a platform team, a microservice migration, an acquisition that demanded integration. They did not build for agents. They happened to have built the thing agents need.
If you are starting from a tangle of internal systems with partial interfaces, that is the work. It is unglamorous, it does not demo, and it is the actual prerequisite.
Where to start
Pick the workflow you would most like an agent to handle and trace it end to end. Every step must be reachable through an API, and it usually is not — there is a step someone does in a UI, or a system with no interface at all. That gap is your actual blocker, and no model choice addresses it.
Version deliberately from here on. An API with agent consumers has callers who cannot read a migration guide, cannot be emailed about a breaking change, and will confidently keep calling the old shape until it fails. Additive changes are safe; renaming a field is not. Teams used to shipping breaking changes behind a well-communicated deprecation window need a different habit, because the communication channel does not exist.
Then improve descriptions before anything else. It is the cheapest change with the largest effect, and most teams skip straight to building tools on top of endpoints nobody described properly.
The uncomfortable version of this: your agent strategy is mostly an API strategy wearing different vocabulary. Teams that recognise that early spend their effort on integration surface. Teams that do not spend it comparing models, and stay stuck at the same ceiling with better benchmarks.
