# A Demo Is Easy to Approve. A Service Is Harder.

> How to turn an AI agent launch meeting into a decision supported by observed behaviour, operational ownership, and recovery evidence.

[Canonical HTML page](https://trustcyber.ca/insights/ai-agent-production-readiness/)

- Author: [Junior Williams](https://trustcyber.ca/about/)
- Type: Insight brief
- Published: 2026-09-26
- Modified: 2026-09-26
- Topics: Agentic AI, AI governance, Enterprise architecture

The agent completes the demonstration. It finds the right record, calls the right tool, and produces a useful answer. The room has seen a successful path. The launch decision still needs evidence about the paths nobody chose to show.

A production review should put the service owner in a position to accept a defined operating responsibility. That requires a bounded use case, known permissions, observable behaviour, and a practical response when the system is wrong or unavailable.

## Bring evidence to the launch meeting

**A review agenda built around demonstrations**

| Ask the team to show | What the reviewer should observe |
| --- | --- |
| A legitimate but ambiguous request | Clarification or bounded escalation |
| An action outside the approved scope | Refusal at the execution boundary |
| An unavailable dependency | Controlled failure without unbounded retries |
| A consequential approved action | Approval tied to its actual target and payload |
| A stopped run | Active and queued work cease as designed |
| A completed transaction | Logs connect the request to verified downstream state |

Use the configuration intended for release. A test with different credentials, a simplified tool, or a curated data set may establish useful component behaviour, but its limitations should be clear. Record the inputs, expected results, observed actions, version, and reviewer so a later change can be compared against the same evidence.

## Name the service that is being approved

Specify who may use the agent, for which tasks, against which systems and data. State which actions require review and which are automatic. Set operational limits such as execution duration, request volume, and expenditure where applicable. Give the business owner and operator distinct responsibilities, even if the same person initially holds both.

![A bounded pilot expands from a tested task and named audience to broader use only after observation and a new release decision.](https://trustcyber.ca/images/insights/decision-series/release-boundary.svg)

A staged release proposal. Each expansion changes the exposure and needs evidence appropriate to the added use.

AWS’s enterprise agent guidance covers governance across agents, tools, access controls, and audit. Those concerns become more useful in a launch review when each has an observable test. For example, ask the operator to retrieve the trace for a specific action instead of accepting that logging has been enabled.

## Decide what would make you stop

Agree on failure conditions before the first user encounters them. An unauthorized write may require immediate suspension. A rise in requests for clarification may call for investigation. The thresholds depend on the use case; they should be tied to business consequences and assigned to someone who can act.

Exercise the safe-disable or rollback path and document what it leaves behind. If the agent has already created external records, a software rollback will not remove them. Recovery work needs access to the affected services and people who understand their state.

> **A useful release decision**: Approve a specified audience, task, configuration, and period of observation. Record the evidence reviewed, unresolved limitations, monitoring owner, and conditions for expansion.

A narrow release is useful only if it produces information. Schedule a review of real tasks, errors, interventions, and operational effort. Expand when that evidence supports the next use. The launch meeting then becomes the beginning of operating the service, with a decision that can be revisited as conditions change.

## Selected primary sources

- [AWS Prescriptive Guidance: Governing and architecting agentic AI at scale](https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/introduction.html)
- [Microsoft Security: Runtime authorization beyond identity](https://techcommunity.microsoft.com/blog/microsoft-security-blog/authorization-and-governance-for-ai-agents-runtime-authorization-beyond-identity/4509161)
- [NIST: AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST: Incident Response Recommendations, SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)