Agentic AI is an operating model, not a chatbot

Most organisations met generative AI through a text box, and that first encounter has quietly become the single biggest obstacle to getting any value from it, because a board that pictures a chatbot will govern a chatbot, ask a chatbot's questions and fund a chatbot's pilots, long after the technology has moved on to something that acts rather than answers. An agent is not a better text box. It is a system you delegate a task to, one that plans, acts through tools, checks its own results and comes back when it is finished or stuck, and the right mental model for it is not "software feature" but "new member of staff with a very specific mandate and a very good audit trail". Once you see it that way, the questions a board should be asking change completely, and most of them turn out to be questions boards already know how to ask.

What you are actually delegating

When you delegate a task to a person you hand over three things whether or not you write them down, and an agent is no different: a scope, the means to act, and a budget. The discipline that separates the organisations getting value from agents from the ones running perpetual pilots is simply that they make all three explicit before the first run, rather than discovering them in the incident review afterwards.

Scope is the set of outcomes the agent may pursue and the ones it must hand back, which in software terms is a permissions model covering which records it can read, which it can change and which systems it may touch at all, and if you cannot state that scope in a paragraph a non-executive director would understand, the agent does not have one yet. The means are its tools, and a production agent should only ever act through a registry of named tools, each with a typed contract and each logged, because that registry is the job description: it says what this member of staff can do and, by omission, what it cannot, which makes adding a tool a governance decision rather than a code change. The budget is the limit on cost and consequence, the spend caps, rate limits and ceilings on how many actions a single run may take before it stops to ask, and it is the cheapest control you will ever put in place, because it is what turns an unbounded loop into a bounded one.

Map those three onto the frameworks you already run and most of the novelty drains away. You already delegate authority to people under exactly these headings; the agent simply refuses to let you be vague about it.

The three things boards are actually afraid of

Every board conversation I have had about agents comes down to one of three fears, and it is worth naming them because each has a different remedy and none of the remedies is a smarter model.

The first is that the agent does the wrong thing, confidently, and this is the one people picture when they picture failure. The answer is not intelligence but reversibility and blast radius: you start agents on actions that can be undone, you keep the scope narrow, and you put a human approval in front of anything that cannot be reversed, because confidence was never a safety property and a bounded scope always was. The second fear, which bites hardest in regulated sectors, is that the agent does the right thing and nobody can explain why, and here the remedy is evidence rather than explanation, since every run should leave behind the goal, the plan, each tool call with its inputs and outputs, and the outcome, in a form a reviewer can read without a data scientist beside them; if you can show what the agent looked at and what it did you can defend the decision, and if you can only show the answer you cannot. The third fear is the quiet one, that the agent does nothing and nobody notices, and it is worse than either of the others because the work that was delegated simply stops happening. The remedy is to measure completed tasks against the volume you expected and to alert on the gap, which is exactly how you would notice a team's throughput falling.

Notice that not one of those remedies is a choice of model. They are operating decisions, and they are precisely the decisions a board is qualified to make.

A grid for deciding where to start

Two questions place any candidate workflow on a grid: can the agent's action be undone, and how much is affected if it is wrong? Reversible and small is where you begin, with drafting, triage, classification and internal routing, anything where a mistake costs a correction and nothing more, and reversible and large comes next once the evidence trail has proven itself, covering bulk changes you can roll back and recommendations a person then executes. Irreversible and small is where an approval step enters the loop, for things like a message sent to a customer or a payment under a threshold, and irreversible and large is where you do not delegate at all yet, however good the demo looked, because anything touching money at scale, safety or a regulator's idea of a significant decision about a person is not the place to learn.

The grid also tells you what to instrument, because whatever quadrant a workflow sits in, the agent should expose the same shape of record, so that moving it up the grid later is a change of permission rather than a rebuild.

// The shape every production agent should expose, regardless of vendor.
type AgentRun = {
  goal: string;
  plan: Step[];
  toolCalls: { tool: string; args: unknown; result: unknown; ms: number }[];
  outcome: 'done' | 'blocked' | 'escalated';
  evidence: string[]; // what a human would need to check the work
};

What the UK actually expects

The UK has not regulated agents as a category and I do not expect it to, but it has held to three positions that together amount to a single test. The financial regulator expects a named senior person to be accountable for outcomes and expects a firm to be able to show how a decision was reached; the data regulator gives individuals rights around decisions made solely by automated means and expects meaningful information about the logic involved; and government policy has been to regulate uses rather than technologies and to lean on existing regulators rather than invent a new one. Read together, the common thread is explainable delegation: you may delegate to a machine, but you must be able to say who authorised it, what it was allowed to do, what it actually did and how a person can intervene. That is the operating model this essay describes, and it is also, not by coincidence, what a well-run team already does with its people.

Where to start

Pick one workflow from the reversible-and-small quadrant, something with real volume that people already find tedious and where a wrong answer costs a correction and nothing more. Write its scope, its tools and its budget on a single page, build the agent so that every run produces the record above, and then run it beside the existing process for a month while measuring one thing only: completed tasks, checked by a person, against the baseline. Not tokens, not latency, not how impressive the transcript reads, but completed tasks, because that is the only number a board can govern. If it holds, you have an operating model you can extend to the next quadrant, and if it does not you have learned so cheaply and with the evidence to say why. Either way the board has something it can govern, which is a good deal more than a chatbot ever gave it.