Agentic AI Readiness Guide

An agentic AI system can choose steps, use connected tools, and continue based on the results it receives. Product labels vary, so assess the actual access and actions the system can take.

Use this guide with the process owner, people doing the work, technical and data owners, security or privacy partners, reviewers, and operations staff. The goal is to decide whether a bounded pilot can be evaluated and safely interrupted—not to produce a readiness score.

1. Define the task and its boundaries

• Name the user, the workflow, and the outcome the agent should help achieve.
• State the event that starts the task and the condition that means it is finished.
• List the cases included in the pilot and the cases that must stay with the existing process.
• Identify the information the agent may use, including the authoritative source for important facts.
• List the connected tools and the actions available through each one: read, create, update, delete, send, or approve.
• Set an explicit stopping point, such as a maximum number of steps, a time limit, or a handoff condition for multi-step tasks.
• Describe actions that are never allowed in this pilot and who can approve any later change to that boundary.
• Define what the agent should do when the task is unclear, information conflicts, or it reaches an excluded case.

Write the boundary in terms people can observe. “Help resolve customer cases” needs limits: which cases, which records, which actions, and when a person takes over.

2. Assign owners and decision rights

Name people for the work before connecting tools:

• Business owner: accountable for the workflow outcome, excluded cases, and acceptable risk.

• Technical owner: responsible for integrations, the agent’s identity, access, and configuration changes.

• Data and security partners: resolve data use, privacy, security, and retention questions for this use.

• Review owner: staffs human checks and handles cases the agent cannot complete.

• Operations or incident owner: watches for problems and coordinates pause, recovery, and communication.

• Change approver: decides who may expand the scope, add a tool, or change permissions.

• The agent’s activity is attributable to a dedicated, managed identity rather than a person’s shared login.

• A named owner can disable the agent’s access and pause the workflow.

• Reviewers know what they may approve, correct, reject, or escalate.

• Staff know where to report an unexpected action and who responds.

3. Limit tools, data, and possible harm

• Inventory the data sources, tools, and systems the workflow needs; name an owner for each.
• Grant the smallest set of records and actions that can complete the pilot task.
• Separate read access from write access where possible; keep test and production environments distinct.
• Check that integrations enforce authorization and validate action parameters outside the model.
• Make sure a natural-language instruction or retrieved document cannot grant new access or override system permissions.
• Treat emails, web pages, documents, and tool results as untrusted input. They may contain instructions that conflict with the task.
• Decide what happens if untrusted content asks the agent to reveal information, change its goal, or contact an unapproved destination.
• Prevent duplicate or repeated actions when a step is retried or a tool times out.
• Set limits for repeated steps, requests, time, and other resources; define the handoff when a limit is reached.
• If the agent can run code or delegate work, document the separate isolation, network, and permission controls for those capabilities.
• Record what activity must be traceable and how sensitive information will be minimized, protected, and retained.

Prompts can guide behavior, but they are not access controls. Permissions, allowed destinations, and validation for actions that change systems need to be enforced by the connected tools and surrounding workflow.

4. Evaluate the complete workflow

Build an evaluation set before live use. Include representative normal work as well as the ways the task can fail.

• Include routine cases, edge cases, missing or conflicting information, stale inputs, and out-of-scope requests.
• Test untrusted instructions embedded in documents, email, retrieved content, and tool responses.
• Test unavailable tools, denied permissions, timeouts, malformed responses, duplicate triggers, and repeated steps.
• For multi-step work, check the action sequence and each tool call, not only the final message.
• Define the acceptable result, actions that are out of bounds, and evidence a reviewer needs to verify the result.
• Measure end-to-end task completion, factual support, correct tool use, exceptions, errors by consequence, latency, cost, and human effort.
• Compare results with the current workflow baseline where possible.
• Run important cases more than once when outputs can vary; repeat evaluation after material changes to tools, data, or configuration.
• Set pass, revise, and stop criteria with the workflow owner before reviewing results.

Use thresholds that fit the workflow’s consequences and review capacity. A single average score can hide a small number of serious action errors.

5. Make human oversight useful and sustainable

• Decide which steps can run within the tested boundary, which need review, and which must remain human decisions.
• Put approval gates at consequential boundaries such as external messages, sensitive disclosures, difficult-to-reverse updates, or actions outside agreed limits.
• Show a reviewer the relevant source, intended action, affected record or recipient, and any uncertainty needed to make a decision.
• Give reviewers a clear way to correct, reject, escalate, or return work to the existing process.
• Do not rely on the agent’s own confidence statement as proof that an action is correct.
• Estimate review volume and time; confirm the queue can be handled within normal operating capacity.
• Track reviewer corrections, rejections, escalations, time per case, and backlog during the pilot.
• Check that reviewers have enough authority and training to challenge a fluent but unsupported result.

Review every step only when the risk and workload justify it. For lower-risk work, a tested boundary with targeted escalation and ongoing sampling may be more workable. For guidance on review patterns and workload, see the Human-in-the-Loop AI Guide.

6. Prepare for operations and incidents

• Name who monitors the workflow during the pilot and how staff reach that person.
• Trace each run across its steps, including relevant input references, system or model configuration, tool requests and results, human decisions, and the final workflow outcome.
• Apply data-access and retention rules to logs; keep enough evidence to investigate without collecting sensitive content unnecessarily.
• Monitor outcome quality, unexpected or denied tool calls, retries, timeouts, changing inputs or integrations, cost, and reviewer workload.
• Route alerts to a named owner and set response expectations before launch.
• Define who can pause the workflow, disable connected actions, and revoke the agent’s access.
• Document how in-flight work returns to a manual path and how to undo or reconcile an incorrect or duplicate change.
• Practice the pause and fallback path before the pilot handles live work.
• Decide how to assess downstream impact, preserve investigation evidence, and notify affected people after an incident.
• Re-evaluate after changes to the task, data, connected tools, permissions, model, or agent configuration.

Readiness review

Mark each area Ready, Needs work, or Unknown, and assign an owner and due date to open items. Do not total the marks into a readiness score; an unresolved permission, ownership, or intervention gap can block a pilot on its own.

Decide what to do next

Start a bounded pilot only when the task and excluded cases are clear, owners can make and enforce decisions, permissions match the task, evaluation covers realistic failures, and people can pause or recover the workflow. If an area needs work, narrow the task or resolve that gap first. A read-only assistant, a draft for human review, or a deterministic step can be a useful way to learn with fewer actions in scope.

Pilot canvas

Capture the launch decisions in one place:

• Workflow, user, and intended outcome:
• Included and excluded cases:
• Connected data and tools:
• Allowed actions and stopping conditions:
• Business, technical, review, and incident owners:
• Data, permission, and retention decisions:
• Evaluation cases, baseline, and pass/stop criteria:
• Human approval and escalation points:
• Monitoring, alert owner, and support path:
• Pause, manual fallback, and recovery plan:
• Pilot group, start date, and review date:
• Decision: prepare, narrow, pilot, or defer: