Before the pilot: five questions for agent readiness

What leaders need to know

A workflow is ready for an agent when five conditions are met:

• Access: the agent can observe and act on the workflow with reliable, permissioned access.
• Authority: the organisation can bound and revoke what the agent is allowed to do.
• Evidence: someone can show how the agent behaves across its scope.
• Ownership: a named team owns the agent and its failures.
• People: those whose work changes have a credible path through the change.

This rubric gives each condition explicit attention so that a strong data foundation does not conceal gaps in authority, evaluation or ownership.

Why “readiness” needs redefining for agents

Earlier automation and analytics programmes could reasonably treat readiness as a data question. If the data existed, was accessible and was clean enough, a model could be trained or a rule could be written, and the remaining risk was mostly about accuracy.

Agentic systems change the shape of the problem because they act. An agent that books a change window, files a credit note or updates a customer record does not merely produce an output for a person to read; it changes the state of the business.

Anthropic’s guidance on building agents makes the point from the engineering side: the recommendation is to start with the simplest composable pattern that meets the need and to add autonomy only where the task genuinely requires it, because autonomy raises cost and the potential for compounding errors.

That shift moves the readiness question from “can we predict well enough?” to “can we delegate safely enough, and will we know if we are wrong?” Answering it requires looking at authority, evidence and ownership alongside data.

The five dimensions

1. Data and integration

The conventional dimension, and still necessary. The agent has to observe the workflow state it needs and act on the systems involved. The questions that matter most for agents specifically:

• Is the state the agent needs available at the moment it needs it, or does it live in someone’s head, an email thread or a spreadsheet that is updated later?
• Can the agent act through an interface with permissions, logging and idempotency, or only through a user interface designed for people?
• When the agent reads content from outside the organisation, is that content treated as untrusted?

A workflow that scores well here is one where the systems of record are the systems of action.

2. Controls and identity

This is the dimension most often skipped, and the one most likely to stop a release late. The organisation needs to be able to say on whose behalf the agent acts, what it may do, how high-impact actions are confirmed, and how its authority is revoked. In practice, the questions are:

• Does the agent have its own identity, or does it borrow a person’s credentials?
• Can permissions be scoped to the workflow, or is the available scope “everything the integrating user can do”?
• Which actions are reversible, and which need a confirmation that a person can see and understand?
• Who can switch the agent off, and how quickly?

A workflow where narrow permissions are hard to arrange will usually run on broad ones. That is a readiness gap, not an engineering detail.

3. Evaluation capability

Readiness includes being able to produce evidence about behaviour before and after release. The NIST AI Risk Management Framework frames this as the “measure” function: identifying the metrics and methods that let an organisation know whether a system is performing as intended, and doing so continuously rather than once. For an agent, the practical questions are:

• Are there real cases, including exceptions and failures, that can be used to exercise the agent?
• Can someone judge what a correct outcome looks like, and record that judgement?
• Is there an environment where the agent can be run without side effects?
• What would justify a rollback, and who would decide?

Without this dimension, the release decision rests on demos.

4. Operating model

An agent in production is a service. It fails, degrades, drifts as models and tools change, and needs someone to own its improvement. Management-system standards such as ISO/IEC 42001 make the general point that AI systems require defined roles, responsibilities and review cycles; for agents, the specific question is whether that ownership fits the organisation’s existing service management or sits outside it. Questions to ask:

• Who is paged when the agent fails, and do they have the access and knowledge to respond?
• How are changes to prompts, tools and models reviewed and released?
• Who reviews the agent’s behaviour on a schedule, and what do they look at?

5. People and adoption

Finally, the people whose work changes. A workflow is not ready if the people in it do not understand what the agent will do, do not trust its outputs enough to act on them, or have no route through the change in their role. This is not a communications task to be scheduled after the build; it is a readiness condition, because adoption friction is one of the largest hidden costs in agent programmes.

Scoring and what to do with the score

Each dimension is scored on a simple scale, with the reasoning recorded. The important rule is that the dimensions do not average. A workflow with excellent data and no controls is not “moderately ready”; it is blocked until the controls exist. The output of the assessment is therefore not a ranked list of use cases by score, but a list of candidates each with the preconditions that must be met before it proceeds and the owner of each precondition.

That framing has a useful side effect. Preconditions are often shared across candidates: an agent identity model, an evaluation environment, a change process for prompts. Meeting them once unblocks several workflows, which is a better first investment than a single pilot that carries all of the gaps on its own.

Common patterns in the results

Three patterns recur when this rubric is applied:

1. Data-ready, control-poor. Mature integrations and clean data, but no way to scope an agent’s permissions below those of an administrator. The right first move is usually identity and delegation work, not a pilot.
2. Evaluation as an afterthought. A working agent with no evidence base, where the team knows it “mostly works” and cannot say more. The first move is to capture real cases and build a small harness before expanding scope.
3. Orphaned ownership. An agent built by an innovation team with no operating owner. The first move is to place it inside an existing service ownership structure or to stop.

What this does not tell you

The rubric does not predict business value; that needs a baseline and a value model of its own. It does not replace a security review of a specific deployment. And the scores are structured judgement rather than measurement. What it does provide is a shared, explicit basis for deciding what to fund next and what has to be true first, which is the decision most organisations are actually trying to make.