A pattern that appeared in large enterprises very quickly: a central place where a business user describes a process they want automated, and gets a working agent — without going through a twelve-month project.

This chapter is about the platform underneath that promise. Building an agent covers one agent; this is what changes when there are three hundred of them and a regulator.

The reassuring part, and it is worth saying to a nervous architecture board: a catalogue, a workload identity and a gateway are the machinery you already run for APIs. This is not a new discipline — it is an existing one pointed at a new consumer. What is genuinely new is session awareness (one call is a step inside a longer task, so per-call authorisation is not the whole story) and agent-to-agent routing.

The interface that makes the promise real is usually a low-code builder — describe the process, pick the systems, set the guardrails — with a pro-code path underneath for anything it cannot express. Microsoft's version of this is Copilot Studio; Google, ServiceNow, Salesforce, Automation Anywhere and a set of specialists all sell the same shape.

Question 3 does most of the work. A large share of requests that arrive as ‘we want an agent’ are deterministic processes with known steps, and those are cheaper, faster and more reliable as ordinary workflow automation. A platform team that routes those away from agents is doing its job; one that builds an agent for every request is manufacturing future maintenance.

The same coverage reports that only a small minority of organisations can produce a current inventory of their agents at all. Whatever the exact figure, the direction is the registry argument above: the plane that produces nothing on its own is the one whose absence you discover at the worst possible moment.

The economics are different from anything before it. A new internal application takes a team and a quarter. An agent takes an afternoon and a business user — which is the entire value proposition, and also the reason the population grows faster than any governance process designed for applications.

• Default-deny agent creation, then delegate deliberately. Most platforms default to letting everyone build. Deciding that consciously is different from inheriting it.
• An owner is a required field, and it is a person. Ownerless agents are the single most common artefact in a two-year-old platform, and nobody will volunteer to adopt one.
• An expiry date, with renewal. An agent nobody has renewed in a year is almost certainly not being used and is certainly not being watched.
• Cost attributed to a team from day one, not to a line item called ‘AI’. You cannot make a decision about a bill you cannot decompose — the same point as the cost chapter.
• One audit log, holding the prompt, the retrieved context, the tools called and the outcome. This is what makes an incident investigable and an auditor answerable, and it is a schema decision made at the start or not at all.

• The agent acts with its own permissions, not the asker's — so an agent with a broad service account hands its authority to anyone who can influence it, including a document it reads. On-behalf-of identity is the correct default and it is more work. See where agent risk concentrates.
• Separation of duties survives automation. An agent that can both raise and approve a change is a control failure regardless of how good it is. The same check that runs on a human access request should run on an agent's.
• Reversibility decides the gate, not importance. Reads free, reversible writes automatic, anything that moves money or touches a customer record gated with the arguments shown — not the intent.
• Model risk management already applies. Most regulated institutions have a model governance function that predates all of this, and the fastest route through is usually to bring agents under it rather than to argue for an exemption.
• Retrieved content is untrusted input. A document containing instructions is an attack, and in a bank the corpus contains things customers wrote. See prompt injection.

• Pick one process, end to end, with a named business owner and a machine-checkable outcome. Not a platform. One process. The platform is what you extract from the second and third.
• Build the registry before the second agent, while it is a small file rather than an archaeology project.
• Put the gateway in the path from the start. Retrofitting it means changing every agent that already works, and that project never gets scheduled.
• Instrument the thing you will be asked about: how many agents, owned by whom, called how often, costing what, failing how. You will be asked in month four, and the answer ‘we don't have that’ is the one that ends the funding.
• And write down what the platform will refuse to build. A platform with no refusal criteria becomes a ticket queue with a chatbot on the front.

The one-sentence version: an enterprise agent platform is a registry, an identity model and a gateway — the machinery you already run for APIs, plus session awareness — and the pilots that fail overwhelmingly fail on governance, ownership and the absence of a definition of done rather than on the models; so build the registry early, put the gateway in the path from the first agent, and let the platform say no to the requests that are really workflow automation.