Your Website Was Built for People. Your APIs Were Not

Most agent-readiness advice a mid-market business receives is about text. Add structured data. Publish an llms.txt. Write cleaner headings so a model can summarise you. All of it is cheap, some of it helps, none of it is the hard part.

The hard part arrives with the next question. What happens when the assistant stops reading and tries to do something — check stock, move the service appointment, pull last quarter’s invoices. At that moment your API becomes the product. And almost no API in a mid-market platform was built to be called by a stranger carrying a language model and somebody else’s credentials.

That is an architecture problem, and it belongs to the same discipline as the rest of your digital product and web engineering work.

Separate what has shipped from what has been announced

The agentic-web conversation mixes working plumbing with browser experiments. They deserve very different budgets.

Settled. The Model Context Protocol — the emerging standard for how assistants connect to outside systems — now specifies how permission works. A server must check that a credential was issued for it specifically, refuse one meant for somebody else, and never pass a borrowed credential further up the chain. Those rules exist because a trusted middleman holding somebody else’s key is one of the oldest failures in security.

Deployed, not yet standard. Signed agent identity. Automated callers cryptographically sign their requests, so you can verify who is calling rather than guess from a browser string that anyone can fake. Cloudflare runs it in production and other providers followed. The specification is still a draft. Deployed does not mean settled.

Moving fast. Agentic commerce. Stripe’s Agentic Commerce Protocol, built with OpenAI and Meta, defines how an assistant completes a checkout on someone’s behalf. Google’s Universal Commerce Protocol and the Agent Payments Protocol cover the same ground. Accurate as of September 2026, and this list will move.

Early. In-page actions, where a page offers an assistant a named list of things it can do. It is a draft, running as a limited browser trial, and its own authors concede it does not solve instructions smuggled into content the model reads. Watch it. Do not put a roadmap on it.

Read those four together. Three are about identity and permission. One is about content.

Discoverability is the easy half

Structured data and clean markup still earn their place — they are how a machine works out what you are, which is a different job from letting it act. But discovery only establishes that something exists.

Everything expensive sits downstream. Can this caller be trusted. What is it allowed to do. What happens when it does the same thing twice. Those are questions about your API, and they were answered years ago on the assumption that the caller was your own website.

Your API already trusts the wrong thing

Most internal APIs carry an unwritten assumption: the caller is our own code, in our own session, on our own domain. Everything downstream inherits that trust. Agent traffic destroys it. The caller is now a third party acting for a customer, holding a credential it obtained somewhere else.

In practice this is a permissions problem, and most platforms have exactly one permission: logged in. “Show me my orders” and “cancel my order” are the same permission because nothing ever needed to tell them apart. Splitting them is not an AI project. It is ordinary authorisation work you could do this quarter, and it improves the platform whether or not an assistant ever calls it.

Reliability decides whether any of this works

The failures that matter here are not the ones a test suite catches. They are partial: a call times out, a credential expires halfway through, a response quietly changes shape under load. A person hits a blank panel, sighs, and clicks again. That is a bad experience with a built-in recovery mechanism.

An agent has no such instinct. It retries, and often retries differently.

We built precisely this shape of integration for AEGEX Technologies. The website was allowed to call the CRM directly and create a lead the moment somebody submitted the contact form. That lead was routed to a named team member based on the options the visitor selected, and an automated sequence fired behind it — an acknowledgement, then follow-ups in a drip.

Every decision in that chain is sound, and every one assumes the caller is a person who meant it. Hand the same endpoint to an assistant that retries a slow request and you do not get a duplicate row in a database. You get a second lead, assigned to a second person, and a real human opening two acknowledgements and two overlapping email sequences. The retry does not stay inside the system. It arrives in somebody’s inbox, where no rollback reaches it.

Three things follow, and none is optional once an action is exposed. Every write carries a marker that lets the same request arrive twice without the thing happening twice. Every partial failure says what actually failed instead of returning a generic error. And every error message is written for a caller that has to decide what to do next — Anthropic’s guidance to tool authors is that errors should describe the specific fix, not the stack trace. A blank “invalid request” is not an error message. It is a retry loop with a bill attached.

The same guidance argues for combining several small calls into one well-named action, which inverts a decade of API design habit. The granularity a developer with documentation finds elegant is, to a machine caller, four chances to get the sequence wrong.

Most businesses should expose no actions at all

Here is the objection we think is right more often than not. A great many websites have nothing an assistant should be allowed to do. An accountancy practice, a manufacturer’s catalogue, a restaurant — no per-customer state, no perishable stock, no consequential action anyone would delegate. For them the whole job is good structured content, honest information, and telling AI crawlers what they may take.

A short test. Does your platform hold information about a customer that changes without them touching it? Is there an action with a real consequence someone would hand to software? Is your information perishable enough that a stale answer is a wrong answer? Two of three and you have a case worth designing. Zero and an agent layer is a liability you are volunteering for.

And there is a route people skip. For many businesses the right agent surface is one somebody else already runs — a commerce protocol, a marketplace feed, a booking platform’s integration. Cheaper, safer, and reviewed by more people than you employ.

Nobody has answered the consent question

We have built the measurement layer on platforms of this kind — error monitoring, event tracking, consent management wired through. Agent traffic quietly breaks all of it.

Analytics assumes a browser and a person. Error monitoring built into your own pages catches nothing when the caller never loads them. And consent tooling assumes informed agreement from a human being. An agent clicking a cookie banner on someone’s behalf is not, in our reading, consent in any meaningful sense. That is our reading rather than a settled question, and it will be settled by regulators, not engineers.

So an agent surface needs its own monitoring from the first day: logs tied to the calling credential, a record of every action taken, limits per caller, and alerting that can tell a looping machine from a struggling customer. That is platform care work rather than launch work, and it is the line most likely to be cut.

The order of operations

If you are weighing an agent layer, this is the sequence we would hold to.

1. Decide who may ask. Verified caller identity before any action exists. If you cannot tell one automated client from another, you cannot revoke one either.
2. Publish the read side first. Structured, stable information. Most of the value, almost none of the risk.
3. Give every action its own permission. If reading and cancelling share one today, that is the first thing to fix.
4. Make writes safe to repeat, and errors worth reading. Assume the caller will retry and re-sequence, because it will.
5. Instrument before you expose. Anything you cannot observe, you cannot withdraw safely.
6. Leave alone whatever fails the test above. Not building is a legitimate outcome, and we will say so when that is where the evidence lands.

Steps two through five are not AI projects. They are ordinary platform quality — the work that makes a system supportable and safe to hand over. That is why we would rather scope this as engineering than as applied AI. The agentic web will not reward the businesses with the most AI-readable copy, but the ones whose platforms could already be trusted to do what they say.