Agents Runtime Operations
A practical reference for the people who connect, review, and operate Agents Runtime and Causal Audit in production.
Who does what
Separate the identity that sends runtime evidence from the people who review it. Apply tenant and project scope at every request, and give each person or service only the permissions it needs. Exact role names can differ by deployment; these are the practical responsibilities to keep distinct.
| Responsibility | Typical actions | Should not be assumed to do |
|---|---|---|
| Runtime service identity | Create executions, append safe events, complete runs, and read its permitted history. | Manage organization-wide settings or approve broad policy changes. |
| Runtime operator | Read executions and findings; run detection and reconciliation. | Alter evidence or bypass tenant boundaries. |
| Causal auditor | Create and inspect permitted audits and review their immutable results. | Run uncontrolled production retries through the audit feature. |
| Governance administrator | Manage scoped settings, permissions, and approved intervention policies. | Treat approval as permission to see private runtime content. |
Scope is part of authorization
A valid login alone is not enough. The control plane resolves the tenant context for protected reads, writes, jobs, findings, and audits. Do not build an integration that trusts a client-supplied scope without server-side authorization.Production Readiness
Before enabling a customer-facing runtime, verify the whole path—not only the Studio page. The API, workers, and Studio must use the same durable, tenant-scoped control-plane state.
- Runtime connector can start, append, and complete a test execution idempotently.
- Runtime events contain safe operational metadata and approved evidence references only.
- Authentication, authorization, and tenant/project scope are tested with least privilege.
- Detector settings are tuned for the intended agent scope and expected traffic volume.
- Job workers are running and can reach the required control-plane persistence.
- A replay adapter, intervention policy, and cost approval exist before enabling Causal Audit.
- Retention, access control, and incident procedures cover evidence references in the owning system.
Workers and Capacity
Ingestion records execution evidence through the API. Causal Audit work is submitted as a durable job and performed by workers: they prepare the governed samples, call the registered replay adapter, compare results, and finalize immutable lineage. A browser session does not need to stay open while that happens.
Workers need enough capacity for the requested sample count and the runtime's own limits. Queue delay, failed jobs, and replay-adapter errors should be monitored as operational signals. A failed sample is retained in the audit result; the platform does not quietly replace it with a production retry.
Causal Audit can create customer costs
Each controlled replay may consume model, runtime, tool, data, storage, or network resources. The customer or business approves, controls, and pays those external costs; AI Governance Control Plane does not set, absorb, or reimburse them. Start with a small sample and enforce your own budgets, quotas, and rate limits.Troubleshooting Guide
| What you see | Check first | Likely next action |
|---|---|---|
| No execution appears | Connector credentials, tenant scope, stable external execution ID, and API delivery result. | Send a small start/append/complete test and inspect the API error. |
| No finding appears | Detector enabled state, minimum observations, baseline, recent window, and thresholds. | Collect adequate normal evidence; do not lower thresholds merely to force a finding. |
| Finding will not resolve | Whether enough consecutive healthy windows have occurred and reconciliation has run. | Investigate the owning service, then let the configured recovery rule gather evidence. |
| Audit is ineligible | Completed source execution, eligible tool evidence, active matching policy, replay adapter, permissions, and scope. | Use the reported eligibility reason to fix the missing prerequisite; do not modify source history. |
| Audit failed or is delayed | Job status, worker health, adapter logs, runtime capacity, and external provider limits. | Address the failed dependency, then create a new governed audit if appropriate. |
| Late evidence is missing from a finding | Event occurrence time, allowed lateness, and detector-window finalization. | Keep the event as history and adjust future delivery/allowed-lateness settings deliberately. |
Operating Rhythm
- Review new or changed findings alongside deployments and runtime health signals.
- Investigate recurring conditions in the system that owns the agent, tool, or model.
- Reconcile only after remediation and enough healthy evidence has accumulated.
- Review active intervention policies and retire versions that should not authorize new audits.
- Review audit volume, queued work, sample size, costs, and replay-adapter reliability.
Read Job Execution for the general job model, Runtime Findings for detector behavior, and Controlled Replay Framework for causal audit safeguards.