Agents Runtime
Agents Runtime helps you understand what an AI agent did after it ran elsewhere. It records safe operational facts, shows a timeline, and highlights repeatable conditions that need attention.
What it is for
An AI agent might answer customer questions, check a claim, or investigate a transaction. The agent continues to run in your own application. Agents Runtime is the place in AI Governance Control Plane where you can review a small, structured account of that run.
Think of it as a flight log, not the aircraft. Your runtime flies the agent; the control plane records the facts needed to review the flight.
Start with the right mental model
If you are familiar with a cloud platform's monitoring console, Agents Runtime plays a similar evidence role: it helps you see the health and history of work that happened elsewhere. But it is purpose-built for AI-agent runs. It keeps the execution timeline, governed evidence references, and findings together without taking over model serving, tool hosting, or workflow orchestration.
| You own | AI Governance Control Plane owns | Why the split helps |
|---|---|---|
| Agent code, prompts, tools, models, data, and live traffic. | The bounded record, tenant-scoped access, findings, policy controls, and audit history. | Sensitive content and production behavior stay with the system that owns them. |
| How to resolve approved evidence and run an isolated replay. | Whether that replay is authorized, traceable, and complete enough to support Causal Audit. | A review can be rigorous without giving the platform unrestricted runtime access. |
Example
A claims agent checks a customer's policy, looks for previous claims, and recommends a review. The runtime can report that the run started, which tools it used, how long they took, whether an error occurred, and that the run finished. Later, an operator can see the sequence without needing access to a hidden model reasoning trace.
Claims agent runs in your application → sends safe events to AI Governance Control Plane → execution timeline is stored → deterministic checks identify unusual patterns → operator reviews evidence and follows up
What it records
One execution is one run of one agent. An execution contains ordered events: small facts such as a model call, tool call, policy decision, evaluation, error, or completion.
| Record | Plain-language meaning | Example |
|---|---|---|
| Agent | The named, versioned automated worker. | claims-agent v2.1 |
| Execution | One attempt by that worker to do its job. | Claim 8421 review |
| Event | One ordered fact from within the attempt. | Policy lookup completed in 120 ms |
| Evidence reference | A safe pointer to approved evidence held by the runtime. | artifact://claims/8421 |
How a runtime connects
A runtime integration follows one small, repeatable pattern. It reports a start record, sends zero or more ordered events, and marks the execution complete. It can retry delivery safely by reusing the same external execution identity and event idempotency key.
1. Agent begins work → create one execution record 2. Meaningful step → append an ordered event with safe metadata 3. Agent finishes → mark SUCCEEDED, FAILED, or CANCELLED 4. Operator reviews → inspect evidence and configured findings
A useful event might say that policy.lookup succeeded in 120 ms, cite an approved evidence reference, and include a correlation ID. It should not copy the returned policy record, the prompt, or a tool payload into the control plane. The Observe an Agent Runtime tutorial provides the complete API example.
Findings, not guesses
Agents Runtime can turn repeated, measurable conditions into a finding. A finding is not an AI-written opinion or an automatic incident ticket. It says that a configured rule saw a condition worth review.
For example, if policy lookups normally fail in 1% of runs but fail in 18% of a recent, sufficiently large set of runs, a tool-failure finding can explain the baseline, the recent result, and the rule that compared them. An operator can investigate the actual tool or runtime outside the control plane.
Findings for one historical execution can also come from a Causal Audit. Those findings explain whether a specific tool result changed a measured outcome; they are not time-series alerts.
Operating the evidence
Studio presents two related but different review workflows. Knowing which one you are using prevents a common mistake: treating a historical causal result as an operational alert that will disappear after one healthy run.
| Action | When to use it | What happens next |
|---|---|---|
| Detect | New execution evidence has arrived or a deployment changed runtime behavior. | Configured deterministic detectors check the available observation windows and create or refresh operational findings. |
| Reconcile | A team has remediated a tool, model, policy, or integration issue. | The platform looks for enough consecutive healthy windows before resolving an operational finding; one good run is not proof of recovery. |
| Review Causal Audit | You need to understand one completed execution's sensitivity to approved tool evidence. | Review or close the historical case after investigation. It remains immutable and is not reconciled by later healthy traffic. |
Detector thresholds, observation windows, and recovery rules are scoped settings. Choose the narrowest scope that makes sense for the agent: a project-specific threshold should not quietly become a system-wide rule.
Privacy & safety
The runtime sends operational metadata and approved references, not a raw transcript. Do not send prompts, responses, conversation messages, chain of thought, credentials, tokens, passwords, tool arguments, tool outputs, or tool results in event attributes.
Keep sensitive content in the system that owns it
Use a durable reference and a digest when a later governed process must verify evidence. The control plane can preserve traceability without becoming a broad store of private agent content.What it does not do
- It does not run, deploy, or orchestrate your agent.
- It does not read or reconstruct private model reasoning.
- It does not make an operational finding mean that a root cause is proven.
- It does not alter a completed execution record.
Next steps
Read Causal Audit to learn how an eligible tool result can be checked safely. To work through a concrete setup, follow the Observe an Agent Runtime tutorial. For the detailed data contract, read Agent Runtime Integration; for detector behavior, read Runtime Findings.