The executive sponsor wants an agent that can resolve a customer problem across CRM, billing, identity and email. The operations lead wants a first deployment that will not create a customer commitment, alter an account or disclose sensitive information before anyone can intervene. Both are reasonable. Only one is suitable for production.
The impressive demonstration usually wins the room. It shows a model moving between systems, interpreting a complaint, making a decision and completing work that used to involve several people. It also bundles together ambiguous inputs, external communication, broad permissions and a chain of decisions that becomes difficult to reconstruct once something goes wrong. An incorrect promise to a customer or a badly handled account change is an operational event, not a disappointing demo.
I would start elsewhere: with a workflow whose effects are visible, stoppable and repairable. The first deployment is an operating test. It should establish whether the organisation can assign authority, constrain action, inspect behaviour and recover from error. Those capabilities matter long after the novelty of the agent has worn off.
The UK Government’s 2025 overview defines agentic systems as software that can choose and combine actions to achieve an objective, rather than follow only fixed, pre-programmed paths. That flexibility is valuable where work varies. It also forces management to settle questions that conventional automation often avoided: what may the system change, which decisions remain with people, who can stop a run, and how is a bad outcome repaired? UK Government
Begin with the failure you can afford
Most first-agent conversations begin with opportunity. Where is the largest queue? Which process annoys customers? What would look ambitious at the next steering committee? These are sensible portfolio questions. They are poor first filters for autonomous work.
Start with the failure case. If the agent selects the wrong record, misunderstands a policy, follows hostile instructions inside a document or calls the wrong tool, what changes? How quickly would somebody know? Can they halt the run? Can the affected state be restored without a cross-functional incident? Is there a record of the source material, tool calls, policy checks and final outcome?
Reversibility has degrees. A drafted response can be discarded. A service ticket sent to the wrong queue can be rerouted. A duplicate knowledge article can be withdrawn. A payment, an access-rights amendment, a production configuration change or a customer notification can travel much further, even where a technical rollback exists. The relevant test is business recovery: can the organisation contain the effect before it reaches a customer, a ledger, a supplier, a regulator or another production system?
That points to an obvious early pattern. Let the agent prepare, classify, route or recommend. Let a person or deterministic rule commit the consequential decision. An agent can assemble evidence for a caseworker, identify incomplete submissions, create a draft response from approved material or prepare a change record against a template. This is how teams build operating discipline without first betting trust, money or availability on a model’s judgement.
NIST’s January 2025 work on agent hijacking explains why the boundary matters. It describes indirect prompt injection, where malicious instructions sit inside an email, file or website an agent reads as part of its task. NIST’s experiments point to the need for task-specific, adaptive evaluation rather than confidence in a general security score. A workflow with limited tools, a narrow data boundary and recoverable outcomes gives a team a safer place to test those defences. NIST
Put every candidate through a selection test
A harmless workflow is not automatically a good candidate. It must produce enough business value and feedback to justify the engineering, control and change work. I would put every proposed workflow through six tests before funding a production pilot.
The trigger must be stable. The agent needs a clear start event, such as a submitted form, a new support case, a failed control or a defined request type. Work that begins with a loosely worded executive email or an evolving conversation is hard to evaluate because the desired outcome changes from one run to the next.
The action envelope must be narrow. Write down what the agent may read, write, create, recommend and never do. Give it the smallest number of well-described tools and the minimum data required. “Help with procurement” is an aspiration. “Classify purchase requests below a defined threshold and prepare a request for missing information” is an operable scope.
A meaningful control must sit before commitment. A reviewer should see the evidence at the point where a decision becomes consequential, rather than receive a ceremonial approval button at the end. A policy-answer agent may need approval before external publication. An incident triage agent may work inside a pre-approved runbook, with deterministic rules blocking every action outside it.
Feedback must arrive quickly. Teams need to know whether the agent improved the work. Measure completion quality, correction rate, elapsed time, exception rate and effort required of the user or reviewer. A result visible only in an annual audit or at contract renewal leaves the team flying blind for too long.
The state must be repairable. Describe rollback in business terms. Delete the draft. Reopen and reassign the ticket. Restore the earlier record version. Notify the reviewer. Preserve the evidence. If reversal requires legal judgement, reconciliation across several systems or an emergency change board, reduce the scope.
An owner must be named. One business leader owns the outcome, quality threshold, permissions, exception route and retirement decision. The platform team can supply identity controls, runtime services and logging. It cannot become the unspoken owner of every business decision that an agent influences.
This test changes the nature of the debate. Product, operations, security and architecture leaders can compare candidates using the same evidence. A workflow can be exciting and still be a poor first deployment.
Pick work that exposes the operating model
The strongest initial workflows are small enough to contain and rich enough to reveal weaknesses in the organisation’s way of working. They show whether the source data is usable, whether policies are precise, whether a tool interface blocks unsafe behaviour, whether reviewers can act in time and whether the team can explain a decision after the fact.
Take three common proposals. An agent that settles customer billing disputes has an attractive business case, but it combines money, customer trust, policy exceptions and communication. The blast radius is substantial. An agent that changes cloud configuration may touch fewer people, yet a wrong action can affect availability or security. It should not be an opening act unless its authority is confined to a tested, reversible runbook.
An internal access-review assistant is a better first case. It can find approved records, flag missing evidence and assemble a structured pack for the entitlement owner. The owner still makes the decision. The team can compare the pack with the existing process, sample accuracy, measure preparation time and switch the workflow off without corrupting a system of record. The exercise teaches the organisation about source authority, retrieval quality, reviewer capacity and audit evidence at once.
Other candidates include drafting an internal knowledge response from a curated source, categorising a defined class of service request, or preparing a standard change record. The domain is secondary. Bounded authority, visible evidence and a repairable outcome are what make the work useful as a first production lesson.
Anthropic draws a helpful distinction between workflows, where code orchestrates a known path, and agents, where a model directs its own tool use and process. Its guidance recommends the simplest solution that meets the need, recognising that agentic systems trade latency and cost for performance. Take that advice literally. Use deterministic automation or a constrained workflow where it is enough. Introduce model-directed autonomy only for the part of the task where variation creates a clear advantage. Anthropic
Design containment before capability
Teams often spend the first weeks debating prompts, models and orchestration frameworks. Those choices matter. They should follow the containment design.
Set an action budget before allowing the agent to run. Define the maximum tool calls, records touched, external messages created, retries permitted and elapsed time before escalation. Give the agent least-privilege credentials rather than borrowing a user’s broad access. Separate read and write access where possible. Keep destructive operations, high-value commitments and sensitive data exports outside the first release.
Then make every run inspectable. Retain the initiating event, sources consulted, tools called, policy checks, proposed action, approver, final result and overrides. Operators do not need a chain-of-thought transcript. They need evidence that shows what happened, which control applied and why the system was allowed to continue.
The NIST AI Risk Management Framework provides a durable way to organise this work through Govern, Map, Measure and Manage. In a first deployment, that translates into assigned accountability, a mapped context and impact, task-specific testing and controls for residual risk. The framework is voluntary. Its lifecycle view is still a useful corrective to the habit of treating production readiness as a final compliance sign-off. NIST AI RMF
Rehearse failure as part of the build. Feed the workflow missing information, conflicting instructions, malformed records and content intended to redirect the agent. Disable a connector mid-run. Force an escalation. Ask an operator to stop the system without hunting through several consoles. A team that discovers its recovery path during a customer incident has left the essential work undone.
Earn the next level of authority
Authority should grow in stages: draft, recommend, execute within a narrow policy, then expand only when the evidence supports it. Each stage needs a success measure and a decision point. If correction rates rise, reviewers become the bottleneck or containment fails in rehearsal, redesign the workflow or stop it. More freedom is rarely the remedy for weak operating controls.
Measure the workflow rather than admiring the agent. Plausible output can still create review work, delay a hand-off or blur accountability. Track end-to-end cycle time, quality, exceptions, reversals, work shifted to people and the business outcome. A local gain that leaves another team with reconciliation and correction work is a cost transfer.
For a CIO, the leadership test is straightforward. If this agent took the wrong action at 4:45 on a Friday afternoon, could the accountable owner explain its authority, stop it, repair the state and show the evidence before Monday morning? If the answer is no, the workflow is still a demonstration. Choose the smaller, reversible case and earn the right to make it more autonomous.
Sources
- UK Government, AI Insights: Agentic AI, 22 April 2025.
- National Institute of Standards and Technology, Strengthening AI Agent Hijacking Evaluations, 17 January 2025.
- Anthropic, Building effective agents, 19 December 2024.
- National Institute of Standards and Technology, AI Risk Management Framework, framework released 26 January 2023; Generative AI Profile released 26 July 2024.