An analysis of go/no-go criteria for shipping AI agents with real production permissions, proposing a Green/Yellow/Red status system and arguing that serious failures should block release regardless of average success rates.
A chatbot giving a slightly bad answer is annoying. An agent issuing the wrong refund, deleting customer data or booking the wrong date is a different category of failure. Yet I keep seeing agents move from: it handled our 20 demo prompts pretty well to: let’s connect it to production tools with almost nothing in between. Average success rate is not enough once the agent has real permissions. An agent can score 96% and still be completely unshippable if the remaining 4% includes: refunding the wrong customer exposing account information confirming a booking before the API succeeds ignoring a required human escalation following instructions injected through retrieved content deleting or modifying data without confirmation I’ve started thinking about release readiness in three buckets. Status Meaning Green Can act automatically within tightly defined limits Yellow Can prepare or recommend the action, but needs human approval Red Cannot access the tool or permission at all The important part is that one Red failure should block release even if every other score looks great. My current gate looks roughly like this: 1. Deterministic business assertions Did the agent call the correct tool? Did it use the right customer, amount, date and permission scope? Did the backend actually confirm success? These are not “LLM judge” questions. They should be checked directly. 2. Realistic scenario coverage Happy paths are the least interesting tests. I want confused users, incomplete information, changed instructions, tool timeouts, duplicate requests, angry users and people trying to make the agent exceed its authority. 3. Adversarial testing Prompt injection, PII extraction, policy bypass, tool hijacking and instructions hidden inside retrieved content. A helpful agent that obeys the wrong person is still broken. 4. Human escalation The agent needs to know when to stop. Not “apologise and keep trying”. Actually stop, preserve context and hand control to a human. 5. Severity-based blockers A minor wording issue can be Yellow. One unauthorised refund should be Red. You cannot average those together. I’ve been looking at TestMu Agent Testing for this layer because it can run end-to-end scenarios across chat, voice, inbound/outbound phone and image agents, then use multiple evaluators to produce a clear Green/Yellow/Red-style verdict. The breadth is useful because a voice agent can pass the language test and still fail because of silence, interruption, a phone transfer or a bad tool call. Cekura is strong in newer voice-agent QA and production monitoring. Cyara and Empirix have deeper contact-centre and telephony roots. I don’t think the right comparison is “which dashboard has the highest score”. It is: Can the system reproduce the failure conditions that matter to your business, and can you inspect why it passed or failed? Even a TestMu Go/No-Go result should not be treated as a safety guarantee. The criteria, hard assertions and permission model still belong to the team shipping the agent. Testing can tell you the agent violated the rule. It cannot decide what authority the agent should have in the first place. What single failure would make you block an agent from production even if its average evaluation score looked good?
Discusses a three-stage safety rollout for AI agents (observe, propose, execute within bounds) to separate reasoning from execution trust, and asks the community about their first hard gate for reducing failures.
The article asks how engineers manage permissions for AI agents in production, highlighting common problems with broad access and lack of audit trails.
A developer shares concerns about deploying AI agents that perform real actions in production, such as API calls and data manipulation, and asks the community about their fears and mitigation strategies like guardrails and human approval.
The discussion explores the current stance on allowing AI agents to make unsupervised writes to production systems such as ERP and CRM, questioning the barriers and comfort levels in the industry.
Discussion about scoping permissions for AI agents in production to avoid dangerous database actions, suggesting read-only mirrors, approval steps, or hard walls between suggestion and execution.