Agent Readiness Guide

Use this guide before adding agent loops to a workflow. It is meant for builders and technical leaders who need a quick but serious readiness check before turning a helpful AI draft into an operational system.

Readiness Questions

Do not start with tools. Start with the work.

1. Is The Goal Verifiable?

The workflow should have a clear definition of done.

Good signs:

• success can be checked against a file, record, test, page, queue, or review decision
• partial completion can be reported honestly
• the workflow can show what source material it used

Risk signs:

• success depends on vague judgment such as “make this better”
• the agent would need to infer missing requirements
• no one can explain how to know whether the output is correct

2. Is The Task Repetitive Enough?

Agent workflows are worth the overhead when the pattern repeats.

Good candidates:

• recurring triage
• draft generation with consistent review rules
• source summarization with known input types
• batch enrichment where each item can be tracked

Poor candidates:

• one-off tasks shorter than the setup and review time
• highly sensitive decisions with unclear criteria
• work that is mostly deterministic and should be regular software

3. Are The Tools Narrow?

Each agent should have only the tools it needs.

Before adding a tool, ask:

• What exact step needs this tool?
• Is the tool read-only or write-capable?
• What is the worst thing that can happen if it is called incorrectly?
• Can the same result be achieved by producing a draft for human review?

If the workflow needs many unrelated tools, split the workflow into smaller agents or stages.

4. Is State Durable?

The workflow needs to know what has happened.

Minimum state to track:

• input item or request id
• status: pending, in progress, done, failed, skipped
• source artifacts used
• output artifacts produced
• errors and retry count
• reviewer decision when applicable

If the connection drops, the workflow should be able to resume from the last verified checkpoint.

5. Are Review Gates Explicit?

Human review should appear before high-impact actions, not after damage is done.

Require review before:

• sending external messages
• publishing content
• changing production systems
• creating or updating customer-facing records
• acting on low-confidence or incomplete output
• handling sensitive, regulated, or private data

Workflow Boundaries

Write the boundary before designing the agent. If the boundary takes more than a few sentences to explain, the workflow is probably too large for one agent loop.

Boundary statement:

The agent is responsible for:
- [Input it may accept]
- [Work it may perform]
- [Output it may produce]
- [Evidence it must save]

The agent is not responsible for:
- [Decisions it may not make]
- [Systems it may not change]
- [Messages it may not send]
- [Missing information it may not infer]

Start Conditions

The workflow may start only when:

• the request or input item is in the expected format
• required source material is available
• the current status is not already done, blocked, or under review
• the agent has the minimum tool permissions needed for this run
• the reviewer, owner, or escalation path is known

Stop Conditions

The workflow must stop when:

• required source material is missing or contradictory
• the requested action falls outside the boundary
• the tool needed for verification is unavailable
• the workflow reaches its retry, runtime, or step limit
• the output would require a decision the agent is not allowed to make
• the agent cannot produce evidence that a claimed action actually happened

Escalation Triggers

Escalate instead of improvising when:

• a source says one thing and a tool result says another
• the workflow asks for external action without approval
• the output affects policy, access, money, legal meaning, safety, or reputation
• the next step would require broader permissions than the agent was granted
• the agent is about to overwrite, delete, publish, send, or mark work complete

Example boundary:

The LIW Training Ops agent may inspect a fictional course backlog, identify lessons missing a review note, and draft a reviewer packet. It may not mark a lesson approved, publish the course, contact learners, or change source records.

Tool Permission Mapping

Map every tool to the narrowest permission that still lets the workflow work. Start read-only, then add write or external-effect permissions only when the step and review gate are clear.

Use these defaults:

• Prefer read-only for discovery and diagnosis.
• Prefer draft-only when the work affects people outside the workflow.
• Require approval before write actions that change a system of record.
• Require approval before any external-effect tool.
• Split the workflow when one agent would need unrelated tool families.

Permission prompt:

For each tool, document:
- exact step that needs it:
- read, write, or external-effect:
- allowed target:
- forbidden target:
- approval required before use:
- evidence saved after use:

Automation Tier Decision

Choose the lowest tier that still creates value.

Read-Only

The agent may inspect, summarize, classify, and recommend. It writes no system-of-record changes.

Use this for new workflows and sensitive contexts.

Draft-Only

The agent creates draft artifacts. A person decides whether to use them.

Use this for messages, reports, summaries, plans, and code changes that need review.

Approval-Gated

The agent prepares an action and queues it for approval.

Use this when the action is structured, reviewable, and reversible.

Bounded Autonomous

The agent acts without approval only inside a narrow, low-risk, monitored envelope.

Use this sparingly. The action should be reversible, observable, and well understood.

Tier test:

Do not move up a tier to save reviewer time until the lower tier has produced enough failure data to show where the review burden really is.

Failure-Handling Checklist

1. Confirm the task is repetitive enough to benefit from automation.
2. Identify the exact tools the workflow needs.
3. Define where human review must remain mandatory.
4. Decide how errors will be detected, logged, and corrected.

Then add these recovery rules:

• Set a maximum retry count.
• Set a maximum runtime or step count.
• Record every completed unit of work in durable state.
• Treat missing source material as a stop condition, not an invitation to guess.
• Mark partial completion honestly.
• Escalate after repeated validation failures.
• Verify completion against evidence, not the agent’s own claim.

Recovery Paths

Every failure path should have a named recovery behavior. “Try again” is not a recovery plan by itself.

Use retry only for failures that are likely temporary and safe to repeat.

Use fail closed when a wrong action would be worse than no action. Missing source material, unclear authority, and external-effect uncertainty should fail closed.

Use park and notify when the agent can save useful partial work but cannot decide the next step. The parked item should include the current status, what is needed, and who should review it.

When success cannot be verified:

• do not mark the item done
• save the output as partial or unverified
• record what evidence is missing
• notify the reviewer or owner with the shortest useful packet
• retry verification only if the verification tool or source is expected to become available

State And Evidence

Agent workflows need durable state because the conversation is not the system of record.

Minimum durable state:

• workflow id or item id
• current status
• assigned owner or reviewer
• input source ids
• tool permissions granted for the run
• checkpoint reached
• retry count and last error
• output artifact path or link
• review decision and timestamp when applicable

Minimum run evidence:

• source packet used
• prompt or instruction version
• model or automation version when relevant
• tools called and targets touched
• validation checks performed
• before/after record for any write action
• reason for any escalation, refusal, or partial completion

Reviewer packet:

Workflow:
Item:
Requested outcome:
Boundary:
Sources used:
Tools used:
Output produced:
Validation evidence:
Known gaps:
Decision requested:

If the reviewer packet cannot be filled in, the workflow is not ready for autonomous completion.

Human Review Gates

Place gates where a person can still prevent harm or avoid false confidence.

Recommended gate placement:

• before first use of a new tool permission
• before changing a system of record
• before publishing, sending, deploying, or notifying externally
• before escalating from draft-only to approval-gated behavior
• after repeated validation failure
• after source-boundary changes
• before marking high-impact work complete

Approval should mean a specific thing. Avoid vague approvals such as “looks good” unless the process defines what that permits.

Approval meanings:

Human review is not a decoration at the end. It is part of the control design.

Reference Links

These public references are useful starting points for deeper study. They are linked for attribution and further reading; the worksheet above is synthesized as original LIW training guidance.

• Anthropic: Building Effective Agents - practical production guidance on when agent patterns help and when workflow simplicity is better.
• LangGraph documentation - useful for understanding state machines, conditional edges, and human-in-the-loop patterns.
• Microsoft AutoGen documentation - useful for comparing multi-agent conversation and handoff patterns.
• NIST AI Risk Management Framework - governance reference for AI risk, measurement, and oversight.
• Microsoft AI Red Team resources - useful for learning how AI systems fail under adversarial pressure.

Compact Readiness Score

Score each area from 0 to 2.

• Goal is verifiable.
• Source boundaries are clear.
• Tool permissions are narrow.
• State and checkpoints are durable.
• Review gates are explicit.
• Failure handling is defined.
• Cost or runtime is bounded.
• Sensitive data rules are understood.

Suggested interpretation:

• 0-5: not ready. Keep the workflow manual or redesign the scope.
• 6-8: read-only candidate. Use the agent for inspection, summaries, and risk flags only.
• 9-11: draft-only candidate. The agent may produce artifacts, but people still decide and act.
• 12-14: approval-gated candidate. The agent may prepare structured actions for review.
• 15-16: bounded-autonomous candidate only if actions are reversible, monitored, and low risk.

Score interpretation prompt:

Lowest-scoring area:
Automation tier allowed by score:
Automation tier requested:
Gap before moving up a tier:
Reviewer or owner:
Next test run:

Do not use the score as a shortcut. Use it to expose gaps before they become production incidents.