A CTO’s checklist before an agent reaches production

A production agent is a distributed software system with probabilistic behaviour and permission to affect a workflow. Treating it as a model integration understates both the engineering task and the decision the CTO must make.

The production gate should answer a specific question: is this exact system configuration ready to perform this defined workflow, for these users, with these permissions and operating controls? A generic “AI readiness” checklist cannot answer it. The checklist below is a review surface; thresholds still depend on consequence and organisational risk appetite.

Make the workflow contract explicit

Start with the outcome the system is meant to produce and the states it may change. Name the permitted users, inputs, tools and destinations. Record exclusions: cases the agent must refuse, escalate or hand back to ordinary software or a person.

Turn that scope into acceptance criteria. For a support agent, “help customers” is not testable; “resolve eligible address changes while requiring confirmation before saving and escalating identity mismatch” is. Include quality, policy, cost, latency and handoff requirements where they affect the decision.

The NIST AI RMF Core begins measurement from mapped context and intended use. That order is essential. Without a workflow contract, test results are numbers looking for a decision.

Freeze and identify the system

The release candidate is more than a model name. Capture prompts, tool schemas, policy rules, retrieval sources, memory behaviour, orchestration, application commit, model/provider version, evaluation harness and infrastructure configuration. State which dependencies can change behind stable interfaces and how such change is detected.

Give the runtime a distinct workload identity. Do not let it inherit a developer’s or shared service account’s privileges. Use scoped, short-lived credentials and enforce authorisation outside the model. The agent may propose an action; a deterministic control should decide whether the authenticated principal is allowed to perform it.

This manifest supports reproduction, incident investigation and rollback. If the team cannot identify the configuration that produced an action, it cannot make a defensible release claim about that configuration.

Evaluate the workflow, including bad days

Exercise representative routine cases, legitimate edge conditions, prohibited requests, hostile content, stale context and tool failures. Grade the final state and action trace, not only the final response. Repeat non-deterministic cases enough to understand variability, and record invalid or inconclusive runs rather than removing them from the denominator.

Define the gate before reviewing results:

Evidence area	CTO production question
Outcome	Does the final workflow state meet the acceptance rule?
Authority	Are tool calls permitted, confirmed and attributable?
Recovery	What happens after timeout, partial execution or duplicate delivery?
Handoff	Can an operator continue with context and authority intact?
Operations	Are cost, latency and failure signals actionable at expected load?

No finite test proves safety in unseen situations. The purpose is to reduce uncertainty within a stated scope and expose what the release decision is accepting.

Apply secure delivery discipline to every component

Agent systems inherit familiar software risks alongside AI-specific ones. Dependency provenance, secret handling, environment separation, code review, vulnerability response and protected build/release processes still matter. The NIST Secure Software Development Framework provides outcome-based practices that can be integrated into different development lifecycles rather than treated as a separate ceremony.

Threat-model the path from untrusted input to privileged action. Test whether retrieved documents, browser content or tool descriptions can redirect the agent. Check data flows across model providers, vector stores, logs and human review tools. Confirm that production permissions are no broader than the evaluated ones.

The UK NCSC secure AI development guidance organizes work across secure design, development, deployment, operation and maintenance. A production gate should cover all five realities, even if the organisation groups them differently.

Make observability answer operational questions

Collect enough trace evidence to reconstruct significant decisions: request identity, version, relevant context references, tool calls, authorisation outcomes, external state change, errors, retries, human intervention and final disposition. Avoid logging secrets or unnecessary personal data merely because the framework supports it.

Dashboards should answer questions with owners attached. Are unauthorised calls being blocked? Are retries causing duplicate actions? Is handoff rising for one policy path? Has cost per qualified completion changed after a model update? Which alert requires someone to do what?

Set baselines during controlled release. An alert threshold invented after an incident is not a release control. Neither is a trace that operators cannot search quickly enough to support containment.

Test containment and recovery end to end

Exercise credential revocation, capability suspension, queue draining, rollback and restoration from known state. Test partial external actions: if an email was sent or a payment initiated, reverting an internal database alone does not restore reality. Define compensating actions and the authority to execute them.

Integrate the agent into the organisation’s incident process. NIST SP 800-61 Rev. 3 frames preparation, detection, response and recovery as part of broader cybersecurity risk management. The agent runbook should name severity triggers, evidence preservation, communications, provider escalation and return-to-service criteria.

A controlled launch can constrain cohort, transaction value, tool set or operating hours while evidence grows. That is a production decision, not an excuse to leave ownership unresolved.

Sign one decision record

End the review with configuration, scope, evidence, findings, residual uncertainty, operating obligations and one named decision owner. Classify open items as blockers, release constraints, monitored risks or backlog—not a flat list that obscures significance.

The CTO should be able to answer: what exact system are we releasing, what is it allowed to do, what evidence supports that choice, how will we know it is losing control, and how will we stop and recover? If any answer relies on “the model should handle it,” the production gate is not complete.

Run the gate as a challenge, not a recital

The production review should include the workflow owner and the engineers who built and will operate the system, plus security, privacy, risk or domain specialists according to consequence. Circulate the decision brief and evidence before the meeting. Use the session for unresolved questions and trade-offs rather than reading a checklist aloud.

Choose two representative traces and one failure trace. Walk each from authenticated request through context, policy, tool calls and final state. Then introduce a change: the provider updates a model, a tool times out after committing, the user loses access while work is queued, or a retrieved document contains hostile instructions. Ask which controls remain deterministic, what telemetry would reveal the event and who makes the next decision.

Record four dispositions. A blocker prevents the proposed release. A constraint narrows users, authority or operating conditions. A monitored risk has a defined signal, threshold and response. A backlog item is genuinely outside the approved scope. This vocabulary prevents a long issue list from hiding one release-critical gap.

Finally, set an evidence expiry rule. The gate remains valid only for the identified configuration and context. Model, prompt, tool, policy, data, permission or workflow changes should trigger a proportionate review. A production sign-off without such triggers becomes less trustworthy with every successful deployment after it.

After the meeting, publish the signed record to the teams that operate the workflow. Operators need to know the approved boundaries and escalation conditions; developers need the constraints that future changes must preserve. A production gate hidden in an executive folder cannot govern day-to-day engineering.

The CTO’s decision is therefore not whether the agent demo is ready. It is whether an identified system, with bounded authority and an owned recovery path, is ready to become an operating dependency.