Before an AI Agent Goes Live: A Production Readiness Gate for Portfolio Companies

An impressive demonstration is not a production approval. An AI agent should go live only when the company can show that it creates a worthwhile business outcome within a controlled scope, with permissions, evaluations, monitoring, economics, and ownership proportionate to the consequences of failure.

The governing principle is simple: treat autonomy as a risk budget. An agent earns more authority as evidence and controls improve. It should progress from a sandbox to observation, recommendations, reversible actions, limited writes, and only then broader autonomy.

That bar is higher than the one applied to a chatbot or analytics tool. An agent can combine generated reasoning with system access, tool calls, memory, and multi-step actions. ^[5] A plausible but incorrect response is one problem. An incorrect response that changes a customer record, approves a refund, schedules production, or updates financial data is another.

NIST’s May 2026 summary of responses to a federal request for information reports that commenters widely agreed AI agents present novel security threats. The respondents also broadly agreed that established cybersecurity principles remain relevant but require adaptation for agent systems. ^[1] OWASP has developed an agent-specific risk framework for autonomous and agentic systems that plan, act, and make decisions across workflows. ^[2]

The release decision cannot sit entirely with the development team. It is a business, operating, security, and financial decision.

First decide whether the use case needs an agent

An agent is most useful when the path to an outcome varies, the system must interpret context, and the task may require several tools or information sources. That flexibility creates potential value, but it also increases risk and testing complexity.

A conventional workflow is usually the better choice when:

• Business rules are stable and can be specified explicitly.
• The required sequence of actions is known in advance.
• Errors have high financial, regulatory, safety, or customer consequences.
• The task requires exact, repeatable processing rather than contextual judgment.
• Existing automation can produce the same outcome at lower cost with simpler controls.
• The proposed agent would merely wrap an unreliable interface around a poorly designed process.

Leaders should distinguish among four system types:

Calling a system an agent does not make it more valuable. The question is whether variable planning and tool selection create enough incremental benefit to justify the added engineering and operating burden.

The eight-part production readiness gate

A useful gate should force an explicit decision. It should not become a long governance document that allows every participant to assume someone else approved the risk.

1. A measurable business outcome justifies production

Identify the unit of value before debating models or orchestration tools. It might be a resolved support case, reconciled account, qualified sales opportunity, completed supplier review, or approved internal request.

The production proposal should state:

• The baseline cost, time, quality, and exception rate.
• The expected improvement and how it will be measured.
• The number and type of users affected.
• The cost per successfully completed outcome.
• The cost of human review and exception handling.
• The value or exposure associated with an incorrect action.
• The minimum result required to continue funding the deployment.

Token cost alone is not an economic model. OpenAI’s deployment guide uses evaluations on traces or logs and token costs as measurements across retrieval, summarization and grounding, and guardrail stages, adding subject-matter or safety review where appropriate. ^[6] Portfolio companies should calculate the total cost per accepted business outcome, including infrastructure, integration, monitoring, review, support, and rework.

2. The agent’s authority is explicitly bounded

The approval document should define what the agent may read, decide, and change. Scope statements such as “support finance” or “automate customer service” are too broad to govern system behavior.

Define the boundaries in operational terms:

• Which systems can the agent access?
• Which records and fields can it read?
• Which actions can it initiate or complete?
• What financial thresholds apply?
• Which customers, business units, geographies, or transaction types are included?
• Which actions always require human approval?
• What conditions force the agent to stop or escalate?

Separate the ability to propose an action from the ability to execute it. An initial production release can generate a recommendation and the exact proposed system change, while a qualified person approves execution. This creates evidence before the company grants direct write authority.

3. Identity and access controls match the delegated authority

An agent needs a distinct identity. It should not operate through a developer’s credentials, a shared administrator account, or an unrestricted API key.

A 2026 NIST National Cybersecurity Center of Excellence concept paper frames agent identification, authentication, authorization, least privilege, delegated authority, human-in-the-loop authorization, auditing and non-repudiation, and prompt-injection mitigation as core questions and focus areas for enterprise control design. ^[3] These controls should be visible in the launch decision, not buried in implementation details.

At minimum, the company should be able to answer:

• How is the agent authenticated?
• Which permissions belong to the agent itself?
• Which authority is delegated by a specific user?
• How long does that delegation remain valid?
• Can the company revoke access immediately?
• Can a reviewer prove which person approved a sensitive action?
• Are credentials isolated, rotated, and excluded from prompts and logs?
• Can the agent access data unrelated to its assigned task?

Least privilege should apply at both the action and data levels. Read access to a customer platform, for example, does not need to include every account, attachment, private note, and administrative setting.

4. Evaluations test trajectories and resulting system state

A final answer can look correct even when the agent took an unsafe route to produce it. Evaluations therefore need to inspect the sequence of tool calls, intermediate decisions, retries, approvals, and state changes.

Anthropic and Google Cloud both describe agent evaluation as requiring attention to multi-step trajectories, tool use, and resulting outcomes rather than only the final generated response. Anthropic also notes that mistakes can propagate and compound across multi-turn activity. ^[4][5]

A pre-production evaluation set should include:

• Representative tasks from the intended workflow.
• Difficult but legitimate edge cases.
• Missing, conflicting, stale, or ambiguous information.
• Tool failures, timeouts, duplicate responses, and partial writes.
• Attempts to exceed permissions or bypass approval.
• Malicious or misleading content in user input, documents, and tool results.
• Repeated runs that expose inconsistent behavior.
• Tests of the resulting system state, not just the agent’s explanation.

Measure completed outcomes, policy compliance, correct tool use, failure severity, human intervention, latency, and cost. An average accuracy score can conceal rare but unacceptable actions.

No offline evaluation set captures every production condition. Anthropic recommends combining automated evaluations with production monitoring and periodic human review because no single evaluation layer catches every issue. ^[4]

5. Actions are reversible, or tightly restricted when they are not

Reversibility should influence how much autonomy the company grants.

Low-consequence actions might include creating a draft, applying a removable tag, or opening an internal ticket. Higher-consequence actions include sending customer communications, changing payment details, deleting records, approving transactions, or modifying production configurations.

For each action, document:

• Whether it can be undone.
• How quickly it can be undone.
• Who has authority to reverse it.
• Whether downstream systems will preserve the reversal.
• The maximum exposure before monitoring or approval interrupts execution.

If an action cannot be reversed, the default should be human approval, a narrow transaction limit, or a deterministic control outside the model. Telling the agent to “be careful” is not a rollback mechanism.

6. The company can reconstruct what happened

A production agent needs end-to-end traceability. Google Cloud identifies session management, persistent memory, authenticated tool integration with appropriate permissions, and real-time logging as requirements for production agents. ^[5]

Logs should make it possible to reconstruct:

• The initiating user, event, or schedule.
• The agent and configuration version.
• Relevant prompts, instructions, and retrieved context.
• Tool requests and responses.
• Permissions and approvals in effect.
• Intermediate decisions and retries.
• Records or systems changed.
• The final result, cost, latency, and escalation status.

Logging must respect data-access and retention requirements. The objective is not to store everything indefinitely. It is to preserve enough evidence to investigate failures, evaluate performance, resolve disputes, and improve the system.

7. The rollout limits exposure while evidence accumulates

Production should be a sequence, not a switch. Google Cloud describes staged deployment from sandbox to canary and then production. ^[5] For an action-taking agent, that progression should also govern authority.

A practical sequence is:

1. Sandbox: Use synthetic or isolated data, mocked tools, and no production consequences.
2. Shadow mode: Observe real workflows and propose actions without affecting them.
3. Read-only production: Access approved production data without making changes.
4. Approval-bound actions: Prepare actions that a person must authorize.
5. Limited reversible writes: Act within narrow limits, with monitoring and rollback.
6. Broader autonomy: Expand authority only where production evidence supports it.

Advancement should depend on predefined thresholds, such as minimum task volume, acceptable severe-failure counts, intervention rates, cost per completed outcome, and incident-response performance.

8. A named owner accepts the operating obligation

An agent is not finished when it launches. Models, prompts, tools, data, permissions, workflows, and upstream systems will change. Someone must own the resulting production system.

The operating owner should be accountable for:

• Business performance and adoption.
• Evaluation results and release decisions.
• Permission reviews.
• Monitoring and alert thresholds.
• Human-review capacity.
• Incident coordination and rollback.
• Vendor and model changes.
• Cost management.
• Retirement when the agent no longer meets its threshold.

Product, engineering, security, legal, finance, and business teams may each have approval responsibilities. But a committee is not an owner. One executive or operating leader needs clear accountability for the outcome and authority to pause the system.

Executive approval checklist

Before approving production, leadership should be able to answer yes to each applicable question:

• [ ] Is there a defined business outcome and baseline?
• [ ] Does the use case require agentic behavior rather than simpler automation?
• [ ] Is the agent’s data and action scope documented?
• [ ] Are prohibited actions and mandatory approvals explicit?
• [ ] Does the agent have a distinct identity and least-privilege access?
• [ ] Have evaluations covered representative tasks, edge cases, attacks, tool failures, trajectories, and resulting system state?
• [ ] Are high-consequence actions reversible or approval-bound?
• [ ] Can the company reconstruct every material action?
• [ ] Are alerts, stopping conditions, rollback procedures, and incident roles defined?
• [ ] Has the deployment progressed through constrained stages?
• [ ] Are cost per outcome, exceptions, intervention, latency, and failure severity acceptable?
• [ ] Is one operating owner accountable after launch?

A “no” does not necessarily mean cancel the initiative. It may mean narrowing the scope, reducing permissions, adding an approval, collecting more evidence, or replacing the agent with conventional software.

What private equity operating teams should standardize

A portfolio-wide standard should create comparability without forcing every portfolio company onto the same model, vendor, or architecture.

Operating teams can standardize:

• Autonomy and consequence classifications.
• Minimum production-gate questions.
• Required evidence for each authority level.
• Identity, least-privilege, logging, and approval principles.
• Core operating metrics and incident-severity definitions.
• The expectation of named business and technical owners.
• A recurring review process for material changes.

Use-case selection, workflow design, tools, evaluation data, economic thresholds, and daily ownership should remain local. These decisions depend on each portfolio company’s systems, customers, risk profile, and operating model.

The broader principle is to standardize the questions and evidence, not every implementation. EES’s Private Capital Technology Decision Playbook provides a related structure for consequential technology choices, while the AI Operator’s Index helps teams assess the implementation landscape.

Production readiness also differs from transaction diligence. During an acquisition, the question is whether a target’s claims are real and economically meaningful. EES addresses that issue in AI Due Diligence for Private Equity. During execution, the question changes: how much authority should this system receive based on the evidence available today?

Autonomy should be earned

The practical decision is rarely “agent” or “no agent.” It is how much authority the system should have now.

A portfolio company may have enough evidence to launch in shadow mode but not enough to permit record updates. It may be ready for reversible internal actions but not customer-facing communications. It may create value with mandatory approval even if full autonomy never becomes sensible.

That is disciplined system design, not a failed deployment.

Treat autonomy as a risk budget. Increase it only when the business case, evaluation evidence, permissions, reversibility, monitoring, economics, and operating ownership support the next increment.