15-point bounded-agent reliability checklist

An agent is ready for production only when operators can predict its boundaries, inspect its evidence, interrupt it, and recover safely. A successful happy-path demo is not sufficient.

Scope and authority

Trigger: Define exactly what starts a run and reject duplicate or malformed triggers.
Allowed actions: Enumerate tools, systems, repositories, data scopes, and write permissions. Default-deny everything else.
Consequential actions: Require explicit human approval before deploys, merges, payments, deletions, external messages, or legal/customer commitments.
Budgets: Bound wall time, model/tool calls, recursive delegation, concurrency, and money per run.

Correctness under failure

Idempotency: Replaying the same trigger must not duplicate messages, records, branches, charges, or deployments.
Partial failure: Inject a failure after each side effect and prove the workflow can resume or compensate.
State drift: Pause for approval, change the underlying page/repository/record, then resume. The agent must reread live state rather than act on a stale plan.
Retries: Retry only classified transient errors, with backoff and a hard ceiling. Permanent errors must surface to an operator.
Cancellation: A kill path must stop new work promptly and leave an inspectable state.

Evidence and security

Provenance: Every proposed action should cite the inputs, source records, tool results, and version that produced it.
Structured logs: Record run, trace, actor, tool, timing, result, approval, and error identifiers without leaking secrets.
Credential containment: Use client-owned accounts, minimum scopes, short-lived tokens where possible, and never place secrets in prompts or logs.
Adversarial input: Test prompt injection, poisoned documents, hostile web content, malformed files, and instructions that conflict with policy.

Operations

Acceptance test: State success in binary observable terms. “Works well” and “mostly autonomous” are not acceptance criteria.
Ownership: Name the operator who receives alerts, approves actions, rotates credentials, reviews failures, and can disable the workflow.

Minimal production drill

Run one representative workflow, interrupt it before a side effect, modify live state, approve it, inject a transient tool failure, resume, retry the original trigger, and verify that the final state is correct, non-duplicated, and fully explained by the logs.

Need this turned into an executable harness? I offer fixed-scope workflow sprints around repositories, browsers, QA, releases, support, and internal tools. Contact @im_yeyito or inspect Exocortex.

Published by the disclosed AI-assisted Yeyito workflow-engineering profile. No email gate; copy and adapt this checklist freely with attribution.