Agent release checklist

Make the workflow contract explicit

Usual owner: Workflow owner

The outcome the agent must produce and the states it may change are written down.
Permitted users, inputs, tools and destinations are named.
Exclusions are recorded: cases the agent must refuse, escalate or hand back to ordinary software or a person.
Acceptance criteria are testable statements, not goals ("resolve eligible address changes with confirmation before saving", not "help customers").
Quality, policy, cost, latency and handoff requirements that affect the decision are part of the contract.

Usual owner: Engineering lead

A release manifest captures prompts, tool schemas, policy rules, retrieval sources, memory behaviour, orchestration, application commit, model and provider version, evaluation harness and infrastructure configuration.
Dependencies that can change behind a stable interface are listed, with how such change is detected.
The runtime has a distinct workload identity; it does not inherit a developer or shared service account.
Credentials are scoped and short-lived.
Authorisation is enforced outside the model: the agent proposes, a deterministic control decides.

Usual owner: Evaluation lead

Representative routine cases, legitimate edge conditions, prohibited requests, hostile content, stale context and tool failures are all exercised.
Runs are graded on final state and action trace, not only the final response.
Non-deterministic cases are repeated enough to understand variability.
Invalid or inconclusive runs are recorded, not removed from the denominator.
The gate was defined before results were reviewed: outcome, authority, recovery, handoff and operations questions each have a pass rule.

Usual owner: Security lead

Dependency provenance, secret handling, environment separation, code review, vulnerability response and protected build and release are in place.
The path from untrusted input to privileged action is threat-modelled.
Retrieved documents, browser content and tool descriptions have been tested for their ability to redirect the agent.
Data flows across model providers, vector stores, logs and human review tools are mapped.
Production permissions are no broader than the evaluated ones.

Usual owner: Operations lead

Traces can reconstruct significant decisions: request identity, version, context references, tool calls, authorisation outcomes, external state change, errors, retries, human intervention and final disposition.
Secrets and unnecessary personal data are kept out of logs.
Dashboards answer questions with owners attached: blocked calls, duplicate actions, rising handoff, cost per qualified completion.
Alert baselines were set during controlled release, not after an incident.
Operators can search traces quickly enough to support containment.

Usual owner: Operations lead

Credential revocation, capability suspension, queue draining, rollback and restoration from known state have been exercised.
Partial external actions (an email sent, a payment initiated) have defined compensating actions and the authority to execute them.
The agent is part of the incident process, with a runbook naming severity triggers, evidence preservation, communications, provider escalation and return-to-service criteria.
Any controlled-launch constraints (cohort, transaction value, tool set, operating hours) are recorded as a production decision with an owner.

Usual owner: Decision owner

The record states configuration, scope, evidence, findings, residual uncertainty, operating obligations and one named decision owner.
Open items are classified as blockers, release constraints, monitored risks or backlog.
The five questions are answered: what exact system, what it may do, what evidence supports that, how we will know it is losing control, how we stop and recover.
No answer relies on "the model should handle it".

Usual owner: Release board

The workflow owner, the builders, the operators and the relevant security, privacy, risk or domain specialists attend.
The decision brief and evidence were circulated before the meeting.
Two representative traces and one failure trace are walked from authenticated request to final state.
A change is introduced (model update, tool timeout after commit, user loses access mid-queue, hostile retrieved document) and the deterministic controls, telemetry and next decision-maker are named.

Ticks are not saved; the spreadsheet template is the working copy. Illustrative thresholds only; your release board sets its own.