An Agent System Is Four Decisions

One agent, four borders

Three questions keep coming back in planning meetings. Do we need A2A if we already speak MCP? Is AG-UI a competitor to MCP Apps? Should we just buy Gemini Enterprise, or AgentCore, and be done with it? They sound like product questions, and they are really the same question three times: nobody in the room has written down which decisions an agent system consists of.

The names themselves are easy to place. CopilotKit is an interface library. MCP is a tool-calling protocol. A2A, agent-to-agent, is a delegation protocol. Vertex was Google’s name for a cloud platform, until April 2026; the platform stayed, the name went. They sit on different layers of one system, the way Angular, HTTP and Frankfurt do, and the platforms bundle several layers at once, which is exactly what makes “buy it and be done” hard to evaluate as a single yes or no.

So the useful work is walking the layers. An agent system is four decisions: who may act, where the person stays in control, how the action is called, and where the model runs. Each decision owns a layer, each layer has its own tools, and each of those names leads with an answer to one of them. The walk is easiest with one concrete agent, so take a replenishment agent on an ordering desk. It watches stock and sales, proposes reorder points, checks suppliers, and drafts purchase orders it may not send. Carrying it through the four decisions fills one page, and the page can be written before anything is bought.

One family of names I have left out on purpose. LangGraph, Google’s ADK, OpenAI’s Agents SDK: the orchestration frameworks are the code inside the agent itself, the way its loop is written. They answer none of the four questions, which is why one can be swapped for another while the answers stand. The swap itself is a real rewrite; checkpoints, state and debugging all differ between frameworks. What survives the rewrite is the four answers, and that is the reason to write them down. The border of this family is already blurring: Vercel’s Eve defines an agent as a directory of files, and deploying it brings the vendor’s durable runtime and sandbox with it. A bundle like that is not a problem; it is several answers at once, each checked on its own layer.

Sorted this way, the landscape of August 2026 is small enough to hold:

Who may act

The first question predates language models entirely, and that is why it is the most neglected: everyone is looking at the new parts, while the machinery for governing automated actors has existed for decades.

The systems I have taken into production over the years were actors in precisely this sense: a vision system driving sorting arms, a nightly forecast feeding an ordering desk. Each ran under its own account, with write access to its own tables and nothing else, and an operations team that could switch it off. Nobody called that agent governance. It was called a service account.

What changed is the cost of creating actors. Standing one up used to be a project; now it takes a week and an API key. And because nothing in that week forces the question of who may act, the question arrives after the demo, if it arrives at all.

For the replenishment agent, the first answer is concrete before any product enters the room, and it is the same answer I have been writing for every automated actor since long before agents. It runs under its own account. The account may write reorder points and draft purchase orders, nothing else. It may read stock, sales and supplier notes. It may run nightly, spend a fixed token budget, and the head of operations can switch it off. The account, not the system prompt, defines what may be written.

When the agent acts for a person, two rights intersect: the agent may do only what its account allows, and no more than the person could have done themselves. Most stacks cannot enforce both at once; in practice there are three shapes. The agent runs as its own account. It borrows the person’s. Or a token is derived from the person for each job, which is the only true intersection. Write down which of the three your system is; the difference decides who is accountable for a bad write.

A slide that says “human in the loop” does not override any of this. If the slide promises that a person approves every order quantity, but the agent’s account may write order quantities on its own, the loop exists on the slide and not in the system.

The identity vendors productised these shapes over the last year. Microsoft’s Entra Agent ID makes an agent a first-class identity in the company directory, with delegated, on-behalf-of access as one of its two modes. Auth0 ships token exchange for agents as a product feature. AWS sells the same plumbing as AgentCore Identity. The mechanism did not change; it acquired product names, which makes the layer easier to buy and no easier to skip. Even the token budget has a home now. AI gateways from Vercel, Cloudflare or LiteLLM enforce spend caps per key, team or user, which turns the budget from a wish into a permission.

Prompt injection is the reason the boundary cannot live in the prompt. The agent’s reading list is its attack surface: a supplier’s PDF, a delivery note, a web page. To a model, an instruction hidden in any of them is just more text, competing with the system prompt on equal footing, and sometimes winning; the account is not part of that negotiation. OWASP, the open application-security community, is drafting a Top 10 for this attack class. One entry, tool poisoning, is hostile instructions planted in a tool’s own description. Every entry ends at the same defense: whatever the text talks the model into, the account decides what gets written. Reading needs the same care. An injected instruction cannot widen what the account may read, but it can try to leak what the agent has already read, through any channel that leads outside: a mail tool, a web request, a commit message. That puts reads and outbound channels in the answer too, next to the write permissions.

So the first answer is a list. Which accounts exist, what each one may change, what each may read and send, when each may run, who can revoke it, and what each may spend: a schedule and a token budget are permissions like any other. It is boring, it fits on half a page, and it matters more than every logo combined.

Where the person stays in control

The agent’s nightly run ends in proposals, and the second question is where they land: when the agent writes, where does the person see it, and how do they stop it? This is the layer CopilotKit and Vercel’s AI SDK live on, with OpenAI’s ChatKit selling the chat panel itself. Two kinds of protocol sit underneath the layer, and the split is who builds the screen. In the first kind you build it: AG-UI streams events out of the agent, which reports what it is doing, and the screens you already have listen and show it. In the second kind the agent asks for a screen: with A2UI or MCP Apps it requests a form, a choice, a comparison, and the product renders it from a catalogue of approved components. The names are unhelpfully similar; the direction is the difference. Choosing between them takes one look at the write: if it lands on a screen you already have, stream into it; if it needs a screen you never designed, request one from the catalogue.

One principle sorts this whole layer: a chat transcript can only describe a change; to stop one, the person has to see it on the row it touched, while it is still reversible. For the desk that means the proposed reorder point appears on the product row, marked as proposed, with accept and undo beside it. So the second answer is again a list: every write the agent may propose, the screen where it appears, how the person stops it, and how long they have. On this desk the list is short: reorder points are reversible and get undo; the purchase order is not, and keeps the one gate.

That list has a failure mode of its own: approval fatigue. After the tenth confirmation a person clicks yes without reading, and the control exists on the screen the way the loop existed on the slide. Two things keep it real. Reversible writes get undo after the fact instead of a gate before it, so gates stay rare enough to mean something. And an approval that someone grants every single day is a rule waiting to be written down; once it is code, it stops being an approval.

How the action is called

The third question splits in two, and the agent’s own actions show the split. “Look up the supplier’s price” returns one result: that is a tool. “Negotiate the delivery date” can wait, fail halfway, or come back with a question: that is a task. The split is what sorts MCP and A2A.

MCP is a function call: one named tool, typed arguments, one result. WebMCP carries the same shape into the web page, where the page itself declares the tools. A2A is a different shape: a job handed to another agent. The other agent is discovered through a small public description file, an agent card at /.well-known/agent-card.json. Then a task moves through states, among them submitted, working, input-required, completed and failed. Its results come back as attached files and records, called artifacts. A job can wait, fail halfway, or come back with a question. A function call cannot.

Both core protocols found their long-term homes in the meantime. MCP and A2A now live under the Linux Foundation’s Agentic AI Foundation; A2A reached v1.0 in March 2026, and IBM’s competing delegation protocol folded into it. Choosing either is no longer a bet on a single vendor’s roadmap.

I treat this as mechanical. If one call returns one result, the action is a tool, and MCP fits it. If the work runs long or has to come back with a question, the action is a task, and A2A fits it. And inside one organization, the A2A answer is often the job queue you already run; the protocol earns its place when the other agent belongs to somebody else, as the supplier’s does. The protocol argument usually dissolves here: once someone writes down whether “check the supplier’s availability” is a lookup or a negotiation, the choice makes itself.

One more flag cuts across both: some actions must stop and ask a person first, whatever their shape, and the desk’s purchase order is one. A2A even has a state for it, input-required. Payments turned that flag into a protocol family of its own. OpenAI and Stripe’s Agentic Commerce Protocol handles the checkout, Google’s AP2 carries the person’s mandate, and x402, a micropayment protocol built on the old HTTP 402 status, settles the payment. They stack rather than compete, because paying is the action that always stops first.

Where the model runs

The fourth question is physical: the model runs on somebody’s hardware, in a place you can name, and that place decides which data leaves your control. There are three: on the device, next to your data, or behind someone else’s API. On the device, the browser’s built-in APIs answer it most strictly: after the first download, nothing leaves the machine. Next to your data means your own cloud environment, under your own accounts, where the order history and the audit log already live. Behind someone else’s API is fastest to a demo, and from the first call onward the sales history has been on hardware you do not control. Enterprises answer that today with contracts, zero-retention terms and a data-processing agreement, and a contract is an answer; it is a different kind of guarantee. A promise in a contract is verified by audit; a boundary in the architecture is verified by looking. Write down, per class of data, which of the two you are relying on.

The desk uses more than one place: the nightly decision runs next to the data, a draft note to the supplier can come from the model on the buyer’s device, and the negotiation may call an external model for what neither can do. Each step toward your own control pays in capability: the strongest models live behind someone else’s API, and the on-device ones are the weakest. That price belongs on the list, next to the place. The decision that matters is which class of data may travel to which place. That is a sentence legal can read and sign; a vendor name is not one.

Next to your data now means a crowded shelf. Google’s Agent Runtime, AWS’s Bedrock AgentCore, Microsoft’s Foundry Agent Service, Vercel’s Eve, Cloudflare’s agents: every large vendor sells a managed place for the agent to run. AWS made the four questions visible in its price list: AgentCore’s thirteen services lead with Identity, Gateway, Runtime and Memory, with Observability beside them. A vendor decomposed the problem into almost exactly these layers and priced each answer separately. Only the interface layer is missing from the box, and for the right reason: that layer has to live in your product.

The same question extends to what the agent remembers. A managed agent runtime, the hosted service the agent runs on, keeps sessions and distils long-term memory from them, what this agent has learned about each supplier. That is one more place where data lives, inside a feature nobody lists as storage, and it is personal data too, because suppliers have contact people. Two things must be written down for it: who may read what the agent remembers about them, and who deletes it when one of them invokes their right to be forgotten. Write memory into the data-travel list with an owner and a deletion path, before the feature ships rather than after the first deletion request arrives.

The runtime layer is also where product names churn fastest. Google’s managed agent runtime was called Vertex AI Agent Engine. In April 2026, Vertex AI became the Gemini Enterprise Agent Platform, and Agent Engine became Agent Runtime. The services are unchanged; only the names moved. Microsoft renamed in the same season, Azure AI Foundry Agent Service into Microsoft Foundry Agent Service, the old one now labelled classic in the docs. OpenAI went further and retired a product outright: its visual Agent Builder, launched October 2025, carried a shutdown notice by June 2026. Write “Vertex” into an architecture document and the document ages. Write “a managed runtime in our own environment, under our own accounts, keeping sessions and long-term memory in a region we choose” and it stays true through every rebrand. The same sentence covers Vercel, where an Eve agent’s conversations persist as checkpointed workflows: a different vendor, the same layer, the same list to write.

The page, and why it is four

The walk is over, and the replenishment agent’s four answers fit on one page: the account that may act and what it may change; the row where a person sees and stops each write; the actions, split into tools, tasks, and the ones that must stop and ask; and the places each class of data may travel. No product name appears on that page, which is what makes it durable, and what turns it into a specification a vendor can be measured against, instead of a slide a vendor brings.

Print it, or take the PDF, and fill the empty rows for the next agent before anyone writes a purchase order. There is also a printable page.

Every block of the page carries a proof column: next to each answer, how you would check it. The account list points at an audit log, the screens at approval records, the actions at call traces, the data classes at flow logs. The same column answers the question a board asks after the first incident: when the ordering desk gets a quantity nobody meant to approve, the account list names whose agent acted, and the approval record names who said yes. Whether the agent did what was approved is a question your own logs must answer, before the vendor’s incident report does. An answer you cannot check is not an answer yet.

And the count itself can be defended now that the walk has shown it. Four is not a round number; it is the count of the agent’s borders. Who may act is the border with the permission system. Where the person stays in control is the border with the person. How the action is called is the border with other software. Where the model runs is the border with hardware and the law it sits under. What happens inside the loop changes none of these borders. And one decision comes before all four: whether the work was settled enough to hand to an agent at all, a question about your processes, not your architecture.

The count deserves the same check as any claim, and the field has its own decompositions to check it against. Ken Huang’s MAESTRO model, published through the Cloud Security Alliance, works in seven layers. OWASP’s threat navigator names six attack surfaces. Alan Chan and colleagues, in the paper I would read first on this, condense agent infrastructure to three functions. AWS sells thirteen AgentCore services. Lay them over this page and the difference turns out to be what is being counted. The frameworks count parts, the things you build, buy or attack; the questions count borders, the decisions that need a counterparty outside the agent. Every part maps: identity and policy onto the first question, oversight and rollback onto the second, protocols, registries and payments onto the third, runtimes, sandboxes and networks onto the fourth, and the model, the prompts and the orchestration into the loop, which belongs to engineering, not to this page.

One concern resists, in every framework: observability and evaluation, the watching. It is a peer layer everywhere else and a column here, for one reason: watching is not a decision about the agent, it is what makes the other four answers answers. If that argument fails for your system, give the page a fifth row, and nothing else changes.

Once the page is written, buy, if there is still something to buy. Filling a named layer with a product is a small decision once the page exists. Often the honest finding is that a layer is already filled, and was years ago, by systems too boring ever to make a slide: the service accounts, the schedulers, the audit logs.

The names will be different next quarter; Vertex already is. So take the page rather than the names. Pick the agent your company is actually arguing about, give it a page, and fill the four rows: the account and what it may change, the screen where a person sees and stops each write, the actions split into tools and tasks, and the places each class of data may travel. You will not finish it in one sitting, and the rows you cannot fill are the useful output, because each one names a decision somebody has been avoiding. Take that page into the next vendor meeting and ask them to answer it.