Agentic Feature Launch Readiness Checklist (2026)

Use this checklist for any feature that can take actions (send, post, edit, delete, deploy, purchase, schedule). If the feature only drafts text and never touches tools or data, you can skip most of this. If it can act, treat it like an operator.

1) Define the “Run” object
- Name the run: what job is it doing (e.g., “Create a weekly status report”)?
- Explicit start and end states: created → planning → executing → awaiting approval → completed/failed/cancelled.
- Identify the artifact(s) it must produce (draft email, PR, ticket, report). If no artifact exists, the UX is probably too fuzzy.

2) Auditability (non-negotiable)
- Store a structured timeline: user input, model response, tool calls, tool results, approvals, and final outputs.
- Log policy version and tool schema version used during the run.
- Attach correlation IDs so support and engineering can trace a run end-to-end.
- Provide a human-readable “What happened” view for users, not just raw JSON.

3) Permissions and scopes
- Build a tool allowlist per workspace/team.
- Implement least privilege per tool: which repos, folders, channels, projects, objects.
- Time-bound credentials and sessions where possible (don’t create indefinite autonomy by accident).
- Separate read vs write vs delete. If you can’t represent the difference, don’t ship the write.

4) Approval rules (risk-tiered)
- Categorize actions by impact (example tiers):
 - Low: read/search/list
 - Medium: create drafts, open PRs, create tickets
 - High: send/post/publish, merge PRs, change permissions, delete
- Default: approvals required for high-impact actions.
- Approvals must be enforced in the runner (server-side gate), not “requested” via prompt text.

5) Reversibility and rollback
- For each write action, define a rollback plan: undo, revert, or compensating action.
- Prefer “draft” and “propose” modes as defaults (draft email vs send; PR vs direct push).
- Store before/after snapshots for data updates where feasible.

6) Replay and debugging
- Record enough inputs to replay: system prompt version, tool schemas, tool responses (or references), model settings.
- Provide an internal “replay run” button for engineers.
- Provide an admin-visible replay/dispute flow for high-impact incidents.

7) Failure modes and safe stops
- Define cancellation: what happens if the user hits stop mid-run?
- Tool timeouts and retries: how many, and for which tools?
- If the model is uncertain, specify the behavior: ask a question, propose options, or take a conservative step.

8) User-facing controls (Settings screen test)
- Can an admin disable the agent entirely?
- Can they restrict tools and data sources?
- Can they require approvals by action type?
- Can they export audit logs for a specific run?
- Can they set data retention for run records?

9) Ship criteria
- If you can’t answer “What did it do?” and “Can I undo it?” from the UI, you’re not ready.
- If support can’t investigate an incident using logs alone, you’re not ready.
- If the agent can access more data than it needs, you’re not ready.

Paste this checklist into your PRD and mark every item as: Implemented / Not needed / Blocked. Anything “blocked” is a launch risk; treat it as such.