Agents, digital workers, copilots: they are said to be alive, ungoverned, autonomous and coming for the humans on the payroll. Most of that comes from not knowing what one is. Here is what sits inside one, where the judgement moved to, and where the control point still is.
"It's alive." The doctor could at least say what. Ask ten executives what an AI agent is, or a digital worker, which is the same thing wearing a vendor's badge, and you will get ten answers, most borrowed from a deck or a headline. Agents are autonomous. Agents are ungoverned. Agents will replace every team. The monster talk does what it has always done: it stops people looking at how the thing was put together. A board that cannot describe the thing it is approving will do one of two things: freeze, or wave it through. Neither is a control. Last week I wrote that you cannot see inside your vendor's AI. This week explains the plumbing, because once you can see what an agent is made of, you can see where the firm gets to decide.
Strip the language away and an agent is a program. It is written in Python, Java or C#, the same languages the firm's existing systems are written in, and it runs where the firm's other software runs: on a server in its own data centre, in its private area of a cloud such as Microsoft Azure or Amazon Web Services, or inside a vendor's platform. It is triggered the way software has always been triggered: an invoice arrives, a client changes address, a clock strikes nine.
When it runs, it does what programs do. It reads data from your systems, it calls other systems through their APIs, the published way one system asks another to do something, and it writes results back. Every action an agent takes in the real world, every payment, every notice, every record changed, goes out through one of those calls. That sentence matters more than anything else in this article, and I will come back to it.
For most of my career the judgement inside business software was written down. If the amount is over ten thousand, require a second approver. If the bank details changed in the last thirty days, hold the payment. A developer wrote the rule, the code was compiled, and the same input produced the same output every time. The word for that is deterministic. You tested it once and it behaved. When it failed, it failed the same way each time, which meant a test could catch it. Its weakness was the case nobody had written a rule for: a new invoice format, a counterparty that fitted no category, a slow drift in client behaviour. For a payment run that rigidity is a virtue. For client correspondence, research or anything that arrives in a hundred shapes, it is the reason the work never got automated at all.
What an agent adds is a single new step. At the point where judgement is needed, the program stops and asks a model. It packages up the situation, the invoice, the client history, the instructions it was given, sends it to a model, a large language model such as Claude or GPT, a model the firm hosts itself on a platform such as Databricks, or an open-source model on its own hardware, and gets back a proposal: pay this, hold that, draft this notice, escalate this case. The model does not act. It returns text. The agent's own code reads the proposal and makes the call that moves money or changes a record.
That is the whole mechanism. The model proposes, with a confidence score where it gives one, and the code executes only if the proposal sits inside the parameters the firm has set. Once you see it that way the fear and the hype both shrink. An agent is the business layer of an application with one of its decisions handed to a probabilistic service instead of a rule, because the probabilistic service can handle the hundred shapes the rulebook could not.
Probabilistic is the word that should concern a Chief Risk Officer, for a precise reason. The same invoice shown to the model twice may get a different answer the second time. The model is usually right. It cannot be proven right in advance, and its behaviour can shift when the provider updates it, with nobody at the firm changing a line. A rule can be tested once. A model has to be tested continuously, on your cases, against the version that ran last month, which is the champion and challenger discipline from last week.
Not every agent hands over the same amount of judgement. At one end is a fixed workflow with a single model step; at the other the model decides what to do next at every step and the code carries out its choices. Regulated firms live in production sit near the first end, and the further an agent moves towards the second, the more the firm needs something deterministic between the model's proposal and the action. "Human in the loop" is the phrase boards reach for here, and applied to everything it is the wrong answer: a person approving every step turns the agent back into a form, and Sarah Breeden of the Bank of England said in June that relying on one "for all agent actions is unlikely to be realistic". The useful question is which decisions get a person.
"We have agents" can mean three different things, and each one puts control in a different place. The table is the shortest way I know to show it.
| Form | Where it runs | What the firm controls | Where control can be applied |
|---|---|---|---|
| Configured by your own staff on a platform, without code An analyst connects Claude, ChatGPT or Copilot to company data and builds an agent inside it; Copilot Studio, Agentforce and the like |
The platform or model provider's cloud | Instructions, permissions, which tools and data it may reach | Only the hooks the platform exposes, plus the front door of any firm system it calls into |
| Built by your own developers and data scientists In code, with an agent framework |
The firm's own cloud or data centre | Everything: code, model version, tools, credentials, logs | Inside the agent, or at the front door of the systems it acts on |
| Built by a software vendor and shipped inside its product You did not configure it, you switched it on; often dozens at a time |
The vendor's estate | What it is allowed to do, what the vendor logs and shares | Contract and configuration; oversight rather than a technical gate |
Three things "we have agents" can mean, and where the firm's control point sits in each.
The line between an agent your staff configured on a platform and one a vendor shipped inside its product is blurrier than it looks, and the test is who built it and who can change it. If your analyst built it inside Copilot, it is yours, even if IT does not know it exists. If the vendor built it and you switched it on, it is theirs, and control is the vendor oversight question I set out last week. In every form the agent asks a model and gets a probabilistic answer back. Whose model it asks, a provider's over an API, one your own team trained, one a vendor runs for you as data science as a service, or an open-weight model on your own hardware, decides what you can inspect and who you depend on. It does not change the mechanism, and the model on its own is not an agent.
Back to the sentence I promised to return to. Every action an agent takes reaches the world through an API call. That is where it can be stopped. A checkpoint in front of the payments system, the order management system or the investor notice service can require any request, from any agent, to be checked before it passes. The agent need not know it exists and cannot route around it, provided the front door is the only way in. This is the same pattern as pre-trade compliance in an order management system: the trader does not decide whether limits are checked, because the order cannot reach the broker until compliance says yes.
What the checkpoint does is deterministic again. It takes the agent's proposal, reads the facts from the systems that own them rather than trusting the agent's version, applies the firm's rules, and returns allow, hold for a named person, or never. Each decision is signed and kept so an auditor can replay it. "Hold for a named person" is where the human in the loop lives, chosen decision by decision rather than imposed on everything. Most firms already own the building block, an API gateway in front of their core systems, so the checkpoint can be built as a policy layer on it; it can also be bought, from a new category of vendors whose whole product is independent code between the model and the action.
One consequence is uncomfortable. If an agent's judgement lives in a model call, the agent stops when the model does, and most models in use are run by a handful of American companies on their terms. Switching provider is a configuration change; trusting the new model with a live payment is a re-test.
Regulators have started on this. The UK's first critical third parties, named in July, and the EU's under DORA are cloud providers; I covered them last week. The Treasury Committee has already told the Treasury to designate the major AI providers as well, by the end of this year. A firm does not need to wait. The model provider behind its agents is a critical supplier today, and the exit plan, the tested fallback model and the mapping of which services stop when the API does belong in the operational resilience file now.
None of this requires a C-suite to read code, only five answers from whoever runs the agents. Which actions can each one take without a person, and through which systems? Where does the model call happen, and whose model is it? What stands between the model's proposal and the action, and can the agent go around it? How is a change to an agent tested against the version it replaces? And who is named as accountable for each one?
Agents are not ungoverned by nature. I wrote last month that an agent is a new hire nobody manages, which is the only part of Frankenstein that transfers: the creature did not turn on its maker because it was alive, but because its maker walked away from it. They are ungoverned where a firm has not asked those questions, usually because nobody explained that an agent is a program that pauses to ask a model, and that the pause is exactly where the firm gets to decide.
If your agents arrive inside the software you license, which is where most firms will meet them first, the Vendor AI Oversight Review is where I start.
Sources: Bank of England (Sarah Breeden, Sintra, June 2026); House of Commons Treasury Committee report on AI in financial services, 20 January 2026. All linked inline.