A team wants an AI agent that can read internal documents, search the knowledge base, summarise a policy, raise a ServiceNow ticket, check an inventory system, query the ERP, and draft an email. Someone builds a prototype. It works well enough that the room gets excited, and within a week someone is already asking whether it can also close the ticket, update the record, or send the email on its own.
Then an architect asks a few ordinary questions.
Which identity is the agent using? What information can it actually see? Is that information the authoritative version, or one of several drifting copies? What actions can it take without a person watching? Who approves those actions? Where do we find the record of what it decided and why? What happens the day it is wrong?
The prototype has not changed in that conversation. It is exactly as capable as it was ten minutes earlier. What has changed is the question. It stopped being "can the AI do this?" and became "is the organisation prepared to let it?"
That second question is architecture. It always was.
An agent is a new kind of enterprise actor
Most applications wait to be told what to do. An AI agent increasingly does the opposite — it interprets a goal, decides a path, calls tools, reads and writes to systems, and sometimes triggers actions that reach other people. That is a meaningful shift in kind, not just in degree.
Once something inside the enterprise can read, decide, and act, it stops being merely a piece of software and starts behaving like an actor — closer to an employee with a login than to a report-generating script. Enterprises have decades of practice governing what employees, contractors, and service accounts are allowed to do. Very few have yet applied that same discipline to agents.
The temptation is to treat the choice of AI platform as the main decision. It rarely is. The platform is replaceable. The decision that is hard to unwind later is how much autonomy was granted before the organisation had the boundaries in place to contain it.
Identity comes before intelligence
An agent with excellent judgement and no identity boundary is not more useful. It is more dangerous, because its mistakes travel through every door its identity can open.
The practical questions are unglamorous and familiar to anyone who has worked in identity and access management: Does the agent have its own enterprise identity, or does it borrow one? If it acts on a person's behalf, does it inherit their full permission set, or a narrower one built for the task? Is it running under a service account nobody has reviewed since it was created? Who owns the identity when the project that created it moves on?
None of this requires new theory. It requires the same principles that already govern IAM, OAuth scopes, and privileged access — least privilege, clear entitlements, an owner, a review cycle, and a way to revoke access quickly. What changes is urgency. A dormant over-permissioned account is a latent risk. An agent with the same over-permissioned account is an active one, because agents are built to use whatever access they have.
Information architecture becomes AI architecture
Agents inherit the organisation's information problems and act on them at speed.
If nobody can say which document is current, which owner is accountable for a dataset, what is confidential, or which of three near-identical files is the one people should actually trust, an agent does not resolve that ambiguity. It picks one, states it with total confidence, and moves on to the next task. AI does not fix information chaos. It simply lets the chaos move faster and reach more places.
This is why information architecture — ownership, classification, lifecycle, source-of-truth — has quietly become one of the more important foundations for enterprise AI. It was always good practice. Agents make it a precondition.
Being able to connect is not the same as being allowed to act
Modern platforms make API access easy. An agent can be connected to a CRM, an ERP, a ticketing system, or a cloud console in an afternoon. That connectivity says nothing about whether the agent should be allowed to act inside those systems unsupervised.
Technical reach and organisational authority are different things, and it is worth treating them as separate design decisions rather than assuming one implies the other. A useful architecture habit is to ask, for every system an agent touches: what can it technically do here, and separately, what is it actually authorised to do here? Where those two answers differ, that gap is exactly where governance needs to sit.
An autonomy ladder, climbed deliberately
It helps to think of agent autonomy as a ladder rather than a switch, and the distinctions between rungs matter more than the ladder itself.
Read. The agent retrieves and summarises information. No action leaves the agent.
Recommend. The agent analyses information and suggests an action, but takes none. A human decides what, if anything, happens next.
Prepare. The agent drafts an action for a human to approve — a draft email, a draft change request, a draft configuration. The action exists, but it cannot execute itself.
Execute. The agent carries out a predefined, bounded action within known limits, after the appropriate approval has already been designed into the process.
Decide. The agent makes a consequential decision independently, with no human step in between.
The gap between "prepare" and "execute" is where most of the real engineering and governance work sits, and the gap between "execute" and "decide" is larger still — it is the difference between a bounded action a human has already agreed to, and a judgement call made without one. Most organisations should expect to spend real time on the first three rungs before seriously considering the last two, and there is no rule that every agent needs to climb toward full autonomy. Many agents will do their most useful work permanently at "recommend" or "prepare." That is not a limitation to engineer away — for a great many tasks, it is the correct, permanent design.
How far up the ladder any given agent should sit depends on consequence, reversibility, confidence, and the strength of the controls around it. A low-consequence, easily reversible task can reasonably run with more autonomy. A high-consequence, hard-to-reverse one — changing production infrastructure, moving money, altering a customer record — deserves a human in the loop for longer than the technology strictly requires.
Delegation does not create authority. In multi-agent architectures, one agent will often hand a task to another — a knowledge agent passing a summary to a service-management agent, for instance. Authority should not silently expand when that happens. An agent that delegates work should not be able to pass along more permission than it holds itself, and the receiving agent's actions should be traceable back to the same identity, boundary, and approval rules as if a human had made the handoff. Without that discipline, a chain of agents can quietly assemble more authority than any single one was ever granted.
Five questions worth asking about any agent
A short framework tends to do more work than a long policy document. Before an agent goes anywhere near production, five questions are usually enough to expose where the risk sits.
- IdentityWho is acting? Not "which system," but which specific, accountable identity is performing the action, and who owns that identity.
- BoundaryWhat is it allowed to touch? The explicit list of systems, data, and tools in scope — and, just as importantly, everything left out of that list.
- EvidenceWhat caused the decision? The information the agent actually used to reach its conclusion, retrievable later, not reconstructed from memory.
- AuthorityWhat can it do without a human? The line between recommend, prepare, and execute, stated plainly enough that a non-technical reviewer can repeat it back correctly.
- RecoveryHow do we stop, reverse, or undo it? The mechanism for revoking access, rolling back a change, and investigating what happened, decided before the agent is live, not while it is misbehaving.
If a project cannot answer these five questions with confidence, it is not ready for more autonomy than "read" and "recommend," regardless of how capable the underlying model is.
Capability does not automatically equal authority
The message worth sitting with is simple: capability does not automatically equal authority. An agent can be technically able to do something and still not be the right party to decide whether it should.
Observability has to reach further
Traditional infrastructure monitoring tells an organisation whether a system is up. It says very little about why an agent reached a particular conclusion. That is a different, and newer, kind of visibility: the request it received, the information it retrieved, the tools it called, the decision it reached, the action it attempted, whether a human approved it, and what happened if it failed.
The test worth applying is simple. If a regulator, an auditor, or an unhappy customer asks six months from now why an agent did what it did, can anyone actually reconstruct the answer — or does the trail run cold somewhere in the middle? If the honest answer is "we'd have to guess," that is an architecture gap, not an AI limitation.
Human accountability, stated plainly
"Human in the loop" is a comforting phrase that can become an empty one if nobody defines it precisely. Which decisions genuinely require approval, and which have quietly been rubber-stamped because the reviewer has no real basis to disagree? Who owns the risk when the agent gets it wrong? Who is accountable when two or three agents interact and no single person designed the interaction? Can the human reviewing an agent's recommendation actually see the evidence behind it, or only the conclusion?
Getting this right does not require a new governance committee. It requires the organisation to write down, in plain language, who is accountable for what — and to test that the answer holds up when something actually goes wrong.
Every agent needs an off switch
However well an agent is designed, the organisation should be able to stop it quickly and cleanly. That means being able to revoke its identity and tokens, disable the tools it can call, restrict its network and API access, halt any workflow it has started, roll back changes it has made, and quarantine it for investigation without disrupting everything around it.
This is not about distrust of the technology. It is ordinary operational discipline — the same discipline applied to any powerful system granted access to production. An agent that cannot be quickly and cleanly stopped was never really under control, no matter how well it performed on the way there.
Three scenarios, three different postures
A knowledge agent that searches and summarises approved internal documents is low-risk. Read-only, well-scoped identity, clear sourcing. Autonomy can sit comfortably at "read" and "recommend."
A service-management agent that identifies an incident and prepares a remediation or change request is medium-risk. It should be allowed to prepare, but a human should approve before anything executes, particularly early on.
An infrastructure agent with the ability to modify cloud, network, or system configuration is higher-risk by nature. Here the ladder should be climbed slowly, with tight boundaries, strong evidence trails, and a genuinely fast off switch, because the cost of a wrong action is high and not always easy to undo.
The point is not that one of these is good and another bad. It is that the same architecture questions produce different, appropriate answers depending on consequence and reversibility.
Where enterprise architecture fits
None of this positions architecture as the function that says no to AI. Its role is closer to the opposite: establishing the capability boundaries, identity patterns, information ownership, autonomy levels, observability requirements, and recovery mechanisms that make broader autonomy safe to grant later. Done well, this work speeds adoption up, because it replaces case-by-case anxiety with a pattern that can be reused for the next agent, and the one after that.
A short checklist before approval
Ten questions worth asking at any architecture review before an agent moves toward production.
- What business capability is the agent actually supporting?
- What identity does it use, and who owns that identity?
- What information can it access, and who owns that information?
- Which of its sources are considered authoritative?
- Which tools or APIs can it invoke?
- What actions can it execute without a human?
- Which actions always require human approval?
- How are its decisions and actions logged, and for how long?
- What happens, procedurally, when it is wrong?
- How quickly can its access and authority be revoked?
Where autonomy should stop
AI agents have real potential to remove friction from enterprise work. That potential is not in question. What is in question is the sequencing: organisations are choosing platforms before they have decided what an agent should be allowed to do, and discovering the gap only after something goes wrong.
The organisations that get agentic AI right are unlikely to be the ones that deployed the most agents fastest. They will more likely be the ones that knew, precisely, where autonomy began — and exactly where it was meant to stop.