An agent can act now. Six decisions that make it safe to let it

Every conversation I have had with a board this year eventually arrives at the same place. Someone has seen an agent do in four minutes what a team used to do in two days, and the question stops being whether to use one. It becomes: what are we willing to let it do on its own, and how would we know if it went wrong. This is the answer I give, written so that a board member and the engineer who will build it can read the same page.

Key takeaways

• AI has crossed from answering to acting. An agent given a goal will plan steps, call tools and APIs, produce work, and adapt as it goes. That is a different class of system from a chatbot, and it carries a different class of risk.
• The value does not come from adopting the most capable model. It comes from designing a reliable system around it: permissions, evidence, accountability, monitoring, containment, recovery.
• Six questions decide whether an agent programme is investable. What may it do alone, what must it show before acting, who owns the outcome, how is it watched, how are cascading errors stopped, and how is a bad run undone.
• Autonomy is not one switch. It is a level set per action, from suggest, to act with confirmation, to act and report, to act silently. Most estates need all four, assigned deliberately.
• An agent's error rate compounds across steps. A ninety-five percent step is a fifty-four percent outcome after twelve steps, which is why short, verified chains beat long clever ones.
• The regulatory clock has already started. The EU AI Act became applicable on 2 August 2026, including the Article 50 transparency duties; the heaviest high-risk obligations were deferred to 2 December 2027 and 2 August 2028. That is planning time, not a reprieve.

Published 13 September 2026. Written for management boards and technical founders.

What actually changed

A chatbot produces text and a person decides what to do with it. The person is the control. An agent given a goal plans a sequence, calls tools, reads and writes to systems, evaluates its own output and adapts. The control has moved inside the loop, which means it has to be designed rather than assumed.

This is why the workflow question is more interesting than the model question. Once an agent can act, an organisation can redesign work around collaboration between people and agents rather than bolting assistance onto the existing process. That is the prize. The risk arrives in the same motion: an agent with more autonomy can be wrong faster, at greater scale, and in places nobody is watching.

Both things follow from the same property. Any serious programme therefore spends most of its effort on the system around the model rather than on the model itself.

What should an agent be permitted to do?

Treat autonomy as a level assigned per action, not a property of the agent. Four levels cover almost everything:

1. Suggest. The agent proposes, a person executes. Right for anything irreversible or externally visible on day one.
2. Act with confirmation. The agent prepares the action in full and pauses for a human to approve it. Right for destructive and financial actions permanently.
3. Act and report. The agent acts and the action lands in a log a person reviews. Right for reversible work with a bounded blast radius.
4. Act silently. No notification, only aggregate metrics. Right for high-volume, low-consequence steps such as classification or enrichment.

The classification that drives this is blast radius, not usefulness: read, write, destructive, financial. Anything that spends money, deletes data, contacts a customer, or changes a price or a permission starts at level two and stays there until the evidence says otherwise. Write the list, put a name against each line, and have it approved at the same table that sets delegation limits for people. The technical team can encode these limits; it should not be the team that invents them.

The mechanism for level two is now cheap. The July 2026 revision of the Model Context Protocol made a human confirmation step a plain request-and-response pattern, so a pause for approval no longer needs bespoke infrastructure. What used to be a paragraph in a policy document is now an enforced control in the server.

What evidence should an agent provide before it acts?

A recommendation without its basis cannot be reviewed, only believed. Require every consequential action to carry four things: the inputs it relied on, the source of each one, the rule or reasoning applied, and a confidence statement with the conditions that would change the answer.

Two design choices follow. Prefer tools that return citable records over tools that return prose, because a claim tied to a row in a system of record can be checked and a summary cannot. And make the evidence a field in the output, not a paragraph inside it. Structured evidence can be sampled, audited, and measured for quality; narrative evidence gets skimmed.

The test to apply: if this action were challenged six months from now by a regulator, an auditor or a customer, does the record explain why it was taken. If the answer is no, the action is not ready for autonomy.

Who is accountable when an agent fails?

Accountability cannot be distributed across a vendor, a model and a workflow. Name a single owner for each agent, a person whose objectives include its outcomes, not its uptime. That person owns the tool catalogue, the autonomy levels, the evidence standard and the incident review.

Three failure modes make this concrete. The agent does exactly what it was told and the instruction was wrong: that belongs to the owner who set the goal. The agent misread a system of record: that belongs with data ownership, and the fix is upstream. The model behaved unexpectedly within a correctly specified task: that belongs to the owner too, because the control that should have caught it, a confirmation step or a validation, was missing or set too loose.

None of those is a vendor problem. Vendor selection affects frequency, not accountability.

How do you monitor an agent that works continuously?

Traditional monitoring answers whether the system ran. Agent monitoring has to answer whether it was right, and that requires different instrumentation from day one.

• Trace every run end to end: goal, plan, each tool call with its arguments, each result, the final action. A run you cannot replay is a run you cannot investigate.
• Sample and grade outputs continuously, by a person early on and by an evaluation set once the failure patterns are known. Ten graded runs a week beats a quarterly review.
• Watch the shape of behaviour, not just failures: steps per task, retries, tool mix, escalation rate, time to completion. A drift in these is usually visible before quality drops.
• Track the human override rate. If approvers approve everything, the checkpoint has become theatre and the real control is gone.

Put the metering at the gateway rather than inside the agent, so the record exists whether or not the agent is behaving. That is the practical reason infrastructure teams care about protocol-level routing: the audit trail is produced by the road, not by the vehicle.

How do you prevent cascading errors?

Compounding is the failure mode people underestimate. A step that is right ninety-five percent of the time gives roughly a fifty-four percent chance of a clean twelve-step run. Nothing in the model fixes that; the architecture has to.

Four controls carry most of the weight:

• Short chains. Decompose long autonomous sequences into shorter runs with a verified artefact between them. The artefact is the checkpoint.
• Validation at the boundary. Check outputs against a schema, a range or a rule before they enter the next step or a system of record. Most cascades begin with one plausible but wrong value that nothing rejected.
• Budgets. Cap steps, tool calls, spend and wall-clock time per run. An agent that hits a budget should stop and escalate, not improvise.
• Idempotency. Design write actions so that a retry cannot double-charge, double-send or double-create. Agents retry more than people do.

How do you recover when it goes wrong?

Recovery is the part that turns an incident into an inconvenience, and it is the part most pilots skip. Three requirements, in order.

Reversibility by design. Prefer actions that can be undone: drafts over sends, staged changes over live ones, soft deletes over hard ones. Where reversal is impossible, autonomy level two is the only correct setting.

A kill switch that someone has actually used. One control that suspends an agent's write access without a deploy, tested in a drill, with a named person who may pull it and no requirement to ask permission first.

A blast-radius query. After an incident the first question is always what else did it touch. If your logs cannot answer that within an hour, the answer will be found by customers instead.

Where the regulation sits

The EU AI Act entered into force on 1 August 2024 and became applicable on 2 August 2026, which brought the Article 50 transparency duties into effect: people are to be told when they are interacting with an AI system, and synthetic content is to be labelled. The heavier high-risk obligations moved under the AI Omnibus, which entered into force on 27 July 2026: Annex III standalone systems now apply from 2 December 2027, and AI embedded in regulated products from 2 August 2028.

Read the deferral correctly. The substance of the high-risk regime, risk management, data governance, technical documentation, record-keeping, human oversight, accuracy and robustness, is exactly the list above. An organisation that builds permissions, evidence, traces and recovery because they make agents reliable will arrive at conformity as a by-product. One that waits for the deadline will be building governance and capability at the same time, under time pressure, which is the expensive way.

What I see from the operator's chair

The pilots that stall are the ones with no owner. The technology rarely fails first. What fails is that nobody can say who decides the agent may send the email. When I audit a stalled programme, the missing artefact is almost never a model evaluation. It is a one-page list of actions with an autonomy level and a name against each.

Approval fatigue is the quiet killer. Teams start with everything at confirmation, approvers rubber-stamp within two weeks, and the organisation now has the cost of a control and none of its protection. Confirmations must be rationed to the actions that deserve them, and the override rate measured, or the checkpoint decays into a click.

The competence being built is not prompting. It is specification: naming the task boundary, the evidence, the failure behaviour and the recovery path. That skill sits between product management and operations, it is scarce, and the companies developing it deliberately are pulling ahead of the ones buying more licences.

What to do in the next two quarters

1. Inventory the agents already running, including the ones a single team started without telling anyone. Record what each can write to and with whose credentials.
2. Classify every action by blast radius and assign one of the four autonomy levels. Get it approved where delegation limits are approved.
3. Set the evidence standard: inputs, sources, reasoning, confidence, as structured fields. Reject tools that cannot supply it for consequential actions.
4. Name an owner per agent, with outcomes in their objectives, and a quarterly review of traces and grades.
5. Instrument before you scale. Full run traces, graded samples, override rate, behavioural metrics. Metering at the gateway.
6. Cap and validate. Step, spend and time budgets; schema and range checks at every boundary; idempotent writes.
7. Rehearse recovery. Kill switch drill, reversal path for each destructive action, a blast-radius query you have run at least once in anger.

The strategic reading

Capability is becoming common. Every serious vendor will sell agents that plan, call tools and adapt, and the gap between the best and second-best model will keep narrowing in the places most businesses operate. What will not become common is the discipline to say precisely what an agent may do, what it must show, who answers for it, and how the organisation recovers when it is wrong.

That is an operating model question, not a technology question, and it is decided at the top of the house. The companies that lead the next wave will not be the ones that adopted the most powerful models. They will be the ones that learned to design reliable systems around them, and that work starts with a list of actions, four autonomy levels and a name against every line.

Sources

• European Commission, AI Act regulatory framework page: entry into force 1 August 2024, applicability 2 August 2026, Annex III high-risk extended to 2 December 2027 and Annex I to 2 August 2028 following the AI Omnibus. digital-strategy.ec.europa.eu
• Gibson Dunn, analysis of the Digital Omnibus on AI agreement and the revised high-risk deadlines, May 2026.
• Pearl Cohen, summary of the obligations taking effect on 2 August 2026, including Article 50 transparency duties.
• Model Context Protocol, 2026-07-28 specification, for the confirmation pattern referenced above. modelcontextprotocol.io

Talk to us about what your agents are already allowed to do.