What should an operating contract for a production AI agent define?

It should define what creates work, the unit of work, valid inputs, permitted tools and side effects, completion criteria, execution limits, and where uncertainty goes. It should also specify approvals, handoffs, deferrals, or stop conditions so autonomy remains a business permission rather than an open-ended model capability.

How should scheduled AI agent work be orchestrated in production?

The scheduler should identify due logical work, assign a stable run identifier, and place it on a durable queue; a separate worker should execute the unit. Each run should use explicit states and an append-only event trail so failures can be recovered and explained.

How can AI agent retries avoid duplicate business actions?

Build an idempotency key from stable business identifiers and pass it to downstream tools when possible. Otherwise, use a side-effect ledger or read-before-retry reconciliation, and retry only classified transient failures within a bounded budget.

What should production AI agent evaluations cover?

Evaluations should test the full workflow: context, retrieved data, procedures, tool calls, proposed side effects, handoff decisions, final response, and business outcome. Use deterministic checks for exact requirements and an LLM judge only for semantic criteria such as relevance or tone.

How should AI agent behavior changes be released safely?

Bundle instructions, procedures, retrieval logic, tool schemas, model settings, and related changes into an immutable candidate release, then run targeted and regression evaluations. Roll it out to controlled traffic, compare it with the baseline, and promote, pause, or roll back using criteria chosen in advance.

Which metrics are needed to monitor a production AI agent?

Execution telemetry should track whether work ran reliably, including trigger coverage, delays, failures, retries, duplicate side effects, latency, and cost per successful task. Behavior telemetry should measure outcome quality, procedure and tool correctness, grounding, handoffs, corrections, and segmented regressions.

What incident-response process should teams use for AI agents?

Contain the issue, preserve evidence, classify the failure, and reconcile external actions before replaying any run. Correct the narrowest responsible component and add the failed case to an evaluation pack so the incident feeds regression coverage.

What should an operating contract for a production AI agent define?

It should define what creates work, the unit of work, valid inputs, permitted tools and side effects, completion criteria, execution limits, and where uncertainty goes. It should also specify approvals, handoffs, deferrals, or stop conditions so autonomy remains a business permission rather than an open-ended model capability.

How should scheduled AI agent work be orchestrated in production?

The scheduler should identify due logical work, assign a stable run identifier, and place it on a durable queue; a separate worker should execute the unit. Each run should use explicit states and an append-only event trail so failures can be recovered and explained.

How can AI agent retries avoid duplicate business actions?

Build an idempotency key from stable business identifiers and pass it to downstream tools when possible. Otherwise, use a side-effect ledger or read-before-retry reconciliation, and retry only classified transient failures within a bounded budget.

What should production AI agent evaluations cover?

Evaluations should test the full workflow: context, retrieved data, procedures, tool calls, proposed side effects, handoff decisions, final response, and business outcome. Use deterministic checks for exact requirements and an LLM judge only for semantic criteria such as relevance or tone.

How should AI agent behavior changes be released safely?

Bundle instructions, procedures, retrieval logic, tool schemas, model settings, and related changes into an immutable candidate release, then run targeted and regression evaluations. Roll it out to controlled traffic, compare it with the baseline, and promote, pause, or roll back using criteria chosen in advance.

Which metrics are needed to monitor a production AI agent?

Execution telemetry should track whether work ran reliably, including trigger coverage, delays, failures, retries, duplicate side effects, latency, and cost per successful task. Behavior telemetry should measure outcome quality, procedure and tool correctness, grounding, handoffs, corrections, and segmented regressions.

What incident-response process should teams use for AI agents?

Contain the issue, preserve evidence, classify the failure, and reconcile external actions before replaying any run. Correct the narrowest responsible component and add the failed case to an evaluation pack so the incident feeds regression coverage.

Production AI Agent Operations: A Practical Operating Model

Your AI agent passed the pilot. Now you have a harder decision: can you let it run when nobody is watching?

The production problem is not primarily whether the model can produce a good answer. It is whether the surrounding system makes every execution bounded, recoverable, explainable, and safe to change. That requires an operating model spanning product policy, workflow orchestration, evaluations, releases, monitoring, and incident response.

Start with an operating contract, not a smarter prompt

An interactive assistant waits for a person to initiate work and supervise the result. A production agent may wake up on a schedule, respond to an event, retrieve current data, call several tools, make a decision, and deliver an outcome before anyone has reviewed it. That is the point where a useful feature becomes an operated service.

A schedule alone does not create that service. An unattended workflow also needs execution history, retries, isolation, parallel processing, stored results, and visible failure states. Without those controls, a missed model call or failed delivery can quietly erase an entire run.

Before choosing infrastructure, write an operating contract for the workflow. This is the product specification for autonomy. It should answer seven questions:

What creates work? Name the schedule, event, user action, or upstream system that can create a run. Define how duplicate triggers are recognized.
What is the unit of work? A weekly report for one account, a resolved support conversation, and a batch of leads are different units. Pick one so success, cost, ownership, and retries can be measured consistently.
Which inputs are valid? Specify required fields, acceptable freshness, access rights, and the conditions that should reject or quarantine an input before the model sees it.
What may the agent do? List allowed tools, data scopes, side effects, and approval requirements. A tool being technically available does not mean the agent has product permission to use it in every situation.
What counts as complete? Separate a model response from the business outcome. A report is not complete merely because text was generated; it may also need validation, storage, delivery, and a delivery receipt.
What are the execution limits? Give the run a deadline, retry budget, cost budget, and maximum scope of change. The correct values depend on the workflow, but leaving them undefined turns unusual behavior into unlimited behavior.
Where does uncertainty go? Define when the agent should ask for approval, hand off, defer the task, or stop. A visible review state is a legitimate outcome, not an embarrassing failure.

This contract prevents a common product mistake: treating autonomy as a model capability instead of a permission granted by the business. The model can propose what is possible. Your operating contract decides what is permitted.

Key takeaways

The scheduler should create work; a durable worker should execute it.
A retry is safe only when repeating the operation cannot duplicate its business effect.
Agent quality must be evaluated before release and monitored after release.
Reliability metrics and decision-quality metrics answer different questions; you need both.
Autonomy should increase only when the next level has explicit permissions, release gates, rollback controls, and an accountable owner.

Design every run as a recoverable state machine

A basic cron job often combines scheduling, data retrieval, model calls, tool use, storage, and delivery in one process. That design is easy to demonstrate and difficult to operate. If the process crashes after a side effect but before recording success, the next attempt cannot tell whether it should repeat the action.

Use the scheduler as a control-plane component. Its job is to identify the logical work due, assign a stable run identifier, and place that work on a durable queue. A separate worker should claim and execute each unit. Isolating scheduled work from the customer-facing application also prevents a background failure from consuming the same process that serves interactive traffic. This separation is the important pattern behind isolated workflow tasks with independent logs, retries, and scaling; the pattern matters more than the infrastructure vendor.

Represent the run with explicit states rather than one success flag. A practical lifecycle is:

QUEUED: the logical work exists but no worker owns it.
RUNNING: a worker holds a time-limited lease and is emitting progress or heartbeat events.
NEEDS_REVIEW: execution stopped at a defined approval or uncertainty boundary.
BUSINESS_REJECTED: the system worked correctly, but policy or input conditions prohibited the requested outcome.
SUCCEEDED: every component included in the completion contract finished.
FAILED_RETRYABLE: a transient dependency or infrastructure failure may succeed on another bounded attempt.
FAILED_TERMINAL: the run exhausted its retry budget or encountered a condition that another attempt will not fix.

Store an append-only event trail beside the current state. At minimum, the run record should retain its identifier, tenant or account, trigger, workflow version, model identifier, instruction version, tool-schema versions, input reference, attempt count, timestamps, tool calls, side-effect references, final outcome, and failure classification. If sensitive inputs cannot be retained, store appropriately protected references and the metadata needed for investigation rather than copying data into every log.

The run record is not merely engineering telemetry. It is the evidence product, operations, and risk owners need when a customer asks what happened.

Make retries idempotent at the business boundary

Retrying a model call is usually less dangerous than retrying an external side effect. Sending an email twice, creating a second refund, updating the wrong CRM state, or submitting the same order again can turn a recovered technical failure into a customer-facing incident.

Create an idempotency key from stable business identifiers such as the tenant, workflow, logical task, and reporting period. Pass that key into downstream tools where supported. Where it is not supported, maintain a side-effect ledger that records the intended action, request fingerprint, external reference, and confirmed result. Before another attempt writes, it should reconcile against that ledger or read the downstream state.

Do not wrap the entire agent loop in one indiscriminate retry policy. Classify failures first:

Retry transient timeouts, rate limits, temporary unavailability, and lost worker leases with bounded backoff.
Do not retry invalid inputs, denied permissions, policy violations, or a request that exceeds the workflow’s limits.
Reconcile ambiguous writes before retrying them. A lost response does not prove that the downstream action failed.
Move exhausted work into a visible terminal queue with an owner, reason code, and safe replay procedure.

Failure mode	Production control	Evidence you should retain
The scheduler fires twice	Stable idempotency key and unique logical-run constraint	One accepted run plus a duplicate-suppression event
The model or dependency times out	Bounded retry with classified errors	Attempt history, latency, error class, and final disposition
A CRM write succeeds but its response is lost	Downstream idempotency or read-before-retry reconciliation	External object reference and side-effect ledger entry
Input data is missing or stale	Pre-execution validation and quarantine	Validation rule, rejected fields, and business reason code
A worker crashes mid-run	Time-limited lease, heartbeat, and safe requeue	Last completed step and ownership history
Generation succeeds but delivery fails	Separate outcome and delivery states	Stored result, delivery attempts, and receipt or terminal error

Separating generation from delivery is especially useful. It lets you resend a completed artifact without asking the model to regenerate it, which avoids both inconsistent output and unnecessary cost.

Evaluate behavior as a release gate, not a launch task

A conventional service should return the same result for the same deterministic logic and inputs. An AI agent reasons through variable language and context, so similar requests can produce different behavior and expose many more scenarios than a team can review manually. A passing demonstration therefore proves only that one path worked once.

Your evaluation system should test the complete workflow: the conversation or task, context available to the agent, retrieved data, procedures followed, tools called, side effects proposed, handoff decision, final response, and business outcome. Testing only the final prose can miss the most consequential error in the run.

Build evaluation scenarios from real operating conditions. Start with common successful cases, then add policy boundaries, missing context, conflicting instructions, dependency failures, ambiguous requests, emotional or adversarial language where relevant, and previous production failures. Each scenario should contain:

The initiating message or event and the context revealed later.
The account state, attributes, permissions, and data the agent can access.
The tools that are available and any tools that must not be used.
The required outcome, required process steps, and acceptable alternatives.
Conditions that require a handoff, approval, refusal, or no action.
Critical failure conditions that should block a release even if other criteria pass.
The evaluator type and the evidence it will inspect.

Use deterministic checks wherever the expected behavior can be expressed exactly. A schema validator can confirm required fields. An event assertion can verify that the correct procedure or tool was invoked. A permission check can prove that an action stayed within scope. Reserve an LLM judge for semantic criteria such as whether an explanation was relevant, complete, or consistent with the intended tone.

This mixed approach produces more useful failure information than asking one judge for a general quality score. Combining deterministic criteria with an LLM judge, while retaining the transcript, event log, and outcome, makes it possible to inspect how the agent reached its result rather than accepting a pass or fail without evidence.

Treat critical criteria as gates, not ingredients in an average. An agent that follows nine style rules but violates one refund boundary has not achieved a 90 percent success in any operationally useful sense. Segment quality by task, policy, customer state, tool path, and release version so a frequent easy case cannot hide a rare severe failure.

Bundle every behavior change into a versioned release

Agent behavior can change when you edit instructions, procedures, knowledge, retrieval logic, tool descriptions, tool schemas, model settings, or the model itself. Changing one component can improve its target scenario while regressing another. Treat the complete configuration as an immutable release artifact.

A disciplined release flow looks like this:

Create a candidate release containing all intended behavior and configuration changes.
Run the relevant evaluation packs and the broader regression suite against the candidate.
Inspect failed transcripts and event traces, especially when an aggregate score appears stable.
Require explicit approval for changes that expand tool permissions, side effects, data access, or autonomy.
Send only controlled traffic to the candidate through a limited rollout, feature flag, or A/B test where the comparison is appropriate.
Compare candidate and baseline by scenario segment, operational reliability, decision quality, business outcome, latency, and cost per successful task.
Promote, pause, or roll back using criteria chosen before the rollout began.

Testing changes away from the live configuration and then publishing them gradually or through an A/B test reduces the blast radius of an unexpected regression. It also gives product leaders a real release decision instead of a vague debate about whether a prompt feels better.

Version the evaluators too. A changed judge prompt or model can move the score even when the agent did not change. Preserve evaluator versions, calibration examples, and human-reviewed disagreements so the measurement system remains auditable.

Monitor the two systems you actually run

Production agent operations contain two overlapping systems. The execution system moves work reliably. The decision system chooses what to do. A green queue does not prove good decisions, and a strong evaluation score does not prove that scheduled runs actually reached customers.

Execution telemetry shows whether the service ran

Trigger coverage: Did every expected logical task create exactly one run?
Start delay: How long did queued work wait before a worker claimed it?
Completion and terminal-failure rates: Which workflows, tenants, dependencies, and release versions account for failure?
Retry recovery: Which transient failures recovered, and which repeatedly consumed the retry budget?
Duplicate side effects: Did any logical run create more than one external business action?
Step latency: Is time accumulating in retrieval, model reasoning, tool execution, validation, or delivery?
Cost per successful task: How much model and tool usage produced a completed business outcome, excluding attempts that never delivered one?

Behavior telemetry shows whether the agent acted well

Outcome quality: Did the task reach the correct business result?
Procedure adherence: Did the agent follow required steps and respect prohibited ones?
Tool correctness: Did it select the right connector, parameters, account, and data scope?
Grounding: Can consequential claims be traced to the permitted context or system of record?
Handoff quality: Did the agent escalate when required and provide enough context for a person to continue?
Correction signals: Was the output edited, reopened, rejected, reversed, or followed by a customer complaint?
Segmented regression: Did performance deteriorate for a particular intent, policy boundary, customer state, language pattern, or release?

Every alert should have a named owner and a pre-agreed response. Page immediately for unauthorized actions, cross-tenant data exposure, or repeated irreversible side effects. Pause the affected workflow or tool permission while the impact is still bounded. A low-risk wording issue can usually enter a review queue; it should not wake an on-call engineer merely because an LLM judge disliked the phrasing.

Sampling is useful for broad review, but it is not enough for critical controls. Run deterministic policy, permission, schema, and side-effect checks on every eligible execution. Apply automated semantic monitoring wherever the evaluator is reliable enough, then sample for human calibration and for failure modes your automated checks do not yet express.

The feedback loop must be closed. Flagged live interactions can become the next evaluation scenarios, turning production failures into permanent regression coverage. Otherwise, monitoring creates a stream of tickets while the same class of defect keeps returning.

Use one incident loop from containment to regression test

Contain: Pause the trigger, disable the affected tool, reduce traffic, restore the previous release, or route work to human review.
Preserve: Retain the run record, release configuration, input references, retrieval evidence, tool events, outputs, and external side-effect identifiers.
Classify: Separate orchestration failure, bad context, reasoning failure, tool failure, policy gap, evaluator gap, and operator error. More than one class may apply.
Reconcile: Determine which external actions completed, duplicated, or remain ambiguous before replaying any run.
Correct: Change the narrowest responsible component and add the failed case to an evaluation pack.
Validate: Run the focused evaluation and the wider regression suite before restoring traffic gradually.
Learn: Update the operating contract, alert, runbook, or autonomy boundary if the incident exposed a missing control.

A kill switch is useful only if it stops the relevant behavior quickly and has been tested. Know whether your control pauses new triggers, cancels queued work, interrupts active tool calls, revokes credentials, or merely hides the user interface. Those are not equivalent actions.

Increase autonomy only when the control system earns it

Do not classify an agent as simply autonomous or not autonomous. Autonomy is a set of permissions across initiation, decision-making, tool use, side effects, and exception handling. Increase those permissions in steps.

Draft: The agent prepares an answer or action, but a person decides whether to use it.
Recommend: The agent proposes a structured action with evidence, expected effect, and an approval request.
Execute reversible actions: The agent acts within a narrow scope where changes can be inspected and undone.
Execute bounded workflows: The agent completes approved task classes independently while exceptions and selected samples receive review.
Operate unattended: The agent initiates and completes eligible work without routine supervision, but hard limits, continuous monitoring, rollback, and human escalation remain in force.

The progression is not a maturity contest. A consequential or hard-to-reverse action may permanently belong at the recommend stage. The right autonomy level is the highest one for which you can detect a bad decision before its impact exceeds the business’s tolerance.

Ownership must be equally explicit. The product owner defines the promised outcome, eligible use cases, autonomy boundary, evaluation gates, and rollout criteria. Engineering or platform ownership covers orchestration, identity, tool enforcement, observability, rollback, and incident response. Domain and risk owners define prohibited actions and approval conditions. Operations owns the review queue, reason taxonomy, and feedback quality. One person can hold several roles in a smaller organization, but the decisions should not become ownerless.

Before granting the next level of autonomy, require a clear yes to each of these checks:

Every logical task receives a stable run identifier and an immutable release version.
Every external side effect is idempotent, reconciled, or protected by approval.
Every terminal failure is visible to an accountable owner.
Retries are bounded and limited to classified transient failures.
Critical policy and permission criteria run as release gates.
The candidate can receive limited traffic independently of the current release.
The rollback and kill-switch paths have been exercised, not merely documented.
Live failures can be converted into regression scenarios with retained evidence.
Time, cost, data access, and tool permissions have enforceable limits.
A runbook names who contains, investigates, reconciles, and restores the workflow.

Choose one unattended workflow this week and write its operating contract. Then add a durable run ledger, one idempotent side-effect path, a focused evaluation pack, and a controlled release mechanism. Run it at its current autonomy level until the evidence supports the next one. Production readiness is not the moment the agent starts acting alone; it is the moment you can explain, constrain, and recover what it does.