AI Agent Readiness Checklist
Evaluate the workflow before selecting the AI architecture
Use this worksheet Complete, copy or print
AI Agent Readiness Worksheet
Record your answers below. Draft recovery uses this browser on this device. Clear it when you finish, especially on a shared device.
A strong agent opportunity starts with a defined operating problem, usable inputs, clear actions, known exception paths, and ownership. Use this checklist to identify what is ready and what still needs discovery.
AI Agent Readiness Checklist
Assess the workflow, data, integrations, controls, and operating model before building.
- Workflow
- Data
- Integrations
- Controls
- Readiness Decision
Readiness Questions
1. Is the workflow clearly defined?
Write down the trigger, inputs, major steps, systems involved, outputs, owners, and what counts as successful completion. If different teams describe the process differently, discovery should resolve that before automation design begins.
2. Are the inputs accessible and understandable?
Identify the documents, messages, records, events, and reference data the workflow uses. Note where information is unstructured, incomplete, duplicated, sensitive, or inconsistent.
3. Can the allowed actions be bounded?
List what the workflow may read, create, update, send, approve, or escalate. Separate recommendations from actions that change systems or create commitments.
4. Are exceptions known?
Document common failure conditions, ambiguity, missing information, policy exceptions, and cases that must stop for human review.
5. Are integration paths available?
Record the applications involved and whether they expose APIs, webhooks, queues, databases, files, or other approved integration methods. Avoid assuming that every legacy interface is safely automatable.
6. Can quality be measured?
Define observable acceptance criteria such as correct classification, valid extraction, successful routing, complete audit records, or appropriate escalation. A production system needs measurable behavior, not just compelling demos.
7. Is there an accountable owner?
Assign ownership for process rules, source knowledge, exception policy, access decisions, monitoring, and change management. An agent without operational ownership will degrade as the business changes.
Use readiness gaps to sequence the work needed for readiness before expanding the initiative.
Turn readiness questions into an evidence record
Use this worksheet with the process owner and someone who performs the work. For each question, mark ready, needs evidence, or blocked. Record the supporting artifact, an owner, and the next action. Do not average the answers into a readiness score: an unresolved permission boundary can block a release even when the rest of the workflow looks promising.
The checklist is most useful when it describes one bounded workflow. “Automate operations” is too broad to evaluate. “Prepare a draft response for this category of internal service request using these approved sources” identifies a trigger, an output, and a practical first release. Use the Workflow Discovery Template if the team cannot yet agree on that boundary.
Scroll horizontally to see all columns.
| Readiness area | Evidence to bring | Decision to record |
|---|---|---|
| Workflow | One normal case and one exception, traced from arrival to completion | First-release start and end points |
| Value | Current queue time, manual effort, rework, and output quality | Which outcome should improve and how it will be measured |
| Data | Representative permitted inputs with source owners | What is available, missing, restricted, or unreliable |
| Actions | Read/write inventory for each connected system | What can execute automatically and what requires review |
| Integration | Confirmed interface and a named system owner | How access, retries, and failures will be handled |
| Evaluation | Examples of acceptable and unacceptable results | Release criteria and cases that must escalate |
| Operations | Monitoring, review coverage, and an incident owner | Who keeps the workflow working after launch |
Check the business opportunity
Describe the current cost of incomplete work as well as the time spent doing it. A workflow may matter because delayed responses lose opportunities, inconsistent answers create rework, or staff cannot serve additional demand. Capture a measurable connection between the proposed change and that business outcome. Avoid assigning all downstream improvement to the AI system when staffing, policy, or product changes also influence the result.
Separate expected capacity from realized savings. Minutes removed from a task may create capacity without removing a cost. Decide whether the organization intends to use that capacity for more throughput, better service, additional review, or a reduced operating expense. That choice affects how the pilot should be measured.
Record a baseline window and the conditions it represents. Include volume and case mix so the team can tell whether a later comparison is fair. If no baseline exists, assign a short measurement exercise as a discovery action rather than filling the gap with a vendor benchmark.
Inspect the difficult cases
Bring examples with missing fields, contradictory documents, duplicate requests, expired permissions, and unavailable systems. Ask the process owner to describe the correct outcome for each. Sometimes the correct outcome is to request more information or stop. Those cases should appear in the evaluation set alongside successful completions.
Review access separately from data availability. A document being easy to retrieve does not mean every user may see it. A connector being technically possible does not mean the application has authority to update the record. Confirm those decisions with the relevant owners before treating integration as ready.
For actions that change a system, record how a reviewer sees the proposed change and how the application prevents execution before approval. Identify whether the same request can arrive twice and what would happen if an acknowledgment is lost. These questions make the first implementation boundary more useful than a general statement that a human will remain involved.
Complete a first-release decision
Scroll horizontally to see all columns.
| Field | Fill in for your workflow |
|---|---|
| Workflow and accountable owner | Name the process and the person responsible for its outcome |
| Included cases | Describe the input types and users covered by the first release |
| Excluded cases | Specify what stays with the current process and how it is routed |
| Desired outcome | State the business result and its measurement window |
| Allowed authority | List reads, drafts, updates, sends, and approvals separately |
| Release evidence | Name the accepted examples, exception tests, and operational rehearsal |
| Open dependency | Record the missing evidence, owner, and date for resolution |
| Next decision | Discovery, bounded pilot, direct implementation, or defer |
Worked example: internal request preparation
Consider a hypothetical team that manually reads incoming requests, finds the relevant policy, and prepares a proposed resolution. The sources exist and the team has useful examples, but authority to update the service system is unresolved. That workflow may be ready for a draft-only pilot while automatic updates remain blocked.
The first release would retrieve permitted evidence and prepare a review packet. Success would include source correctness, reviewer acceptance, handling of missing evidence, and total reviewer effort. The team would also check that no external update can occur. Readiness is therefore specific to the proposed authority, not a permanent label attached to the whole opportunity.
If the team later wants automatic updates, revisit permissions, action validation, duplication, recovery, and operating coverage. Reuse the accepted draft workflow as a baseline, but add the evidence required by the new capability. The earlier pilot does not automatically authorize a broader system.
Use the result to choose the next step
An AI Workflow Blueprint can turn unresolved workflow, integration, or architecture questions into an implementation scope. If the operating boundary is already clear, use the AI Architecture Decision Guide to compare the simplest viable pattern. The workflow readiness article provides a deeper explanation of candidate selection.
Bring the completed evidence record to the working session. A useful conclusion names the next decision, the evidence needed to make it, and the owner who will provide that evidence. That is enough to move the work forward without pretending that every unknown has been eliminated.
Have a defined initiative? Discuss an AI project with the completed evidence record.
Good Signs
High Manual Coordination
People spend significant time reading, copying, checking, routing, or assembling information.
Repeatable Decision Boundaries
The workflow has recognizable rules, reference sources, and escalation criteria even when inputs vary.
Accessible Systems
The required data and actions can be reached through approved integration patterns.
Known Exceptions
Teams can describe what should happen when confidence is low or policy conditions are not met.
Measurable Outputs
Quality, completion, exceptions, and downstream results can be observed and tested.
Clear Ownership
A business owner can maintain the rules, sources, and operating expectations after launch.
Want a Second Pair of Eyes on a Workflow?
Bring the checklist and a real process to a KeenSight working session. We can help separate architecture questions from process questions.
Continue with practical guidance
- AI Agents vs. Agentic Workflows vs. Automation: What Should You Build?
A research-informed guide to AI assistants, deterministic workflow automation, agentic workflows, and AI agents, including architecture, authority, controls, economics, and when hybrid systems are the better choice.
- How to Build an Enterprise AI Roadmap From Strategy to Production
Build an enterprise AI roadmap using business outcomes, comparable opportunities, shared dependencies, delivery evidence, and accountable investment decisions.
