System architecture
Five layers.
No implicit trust.
Separate reasoning from authority, execution from state, and observations from decisions. Each layer needs a defined interface—and a defined failure behavior.
Runtime & orchestration
Own the execution lifecycle: accepted request, scheduled work, bounded steps, cancellation and terminal outcome. A model may propose the next action; the runtime must not turn that proposal into unrestricted authority.
- Responsibility
- Track run identity, deadlines, step limits and retry budgets. Distinguish completed, failed, cancelled and outcome-unknown states.
- Interface shape
- A versioned run envelope carrying principal reference, workload scope, correlation ID, deadline and policy version. Dispatch returns a typed outcome.
| Failure mode | Required handling |
|---|---|
| Timeout after dispatch | Stop dependent work. Reconcile the downstream action before retrying; a timeout is not proof that nothing happened. |
| Retry loop or cancellation | Enforce a finite retry budget and cancellation propagation. Record work that cannot be cancelled. |
We define runtime behavior in scope. The customer owns queue infrastructure and business rules for resumable work; recovery tests are shared.
Tools & policy gateway
Mediate every supported tool invocation and model-provider route. Check the requesting principal, permitted action, resource scope, input schema and egress destination before dispatch.
- Responsibility
- Centralize policy decisions, approval requirements, request validation and usage attribution. Treat model output and tool responses as untrusted input.
- Interface shape
- Typed action requests with a tool version, validated arguments, principal and resource references. Return a decision ID and a typed result or refusal.
| Failure mode | Required handling |
|---|---|
| Policy cannot be evaluated | Deny the protected action. Do not fall back to a broader service credential. |
| Duplicate or malformed request | Reject invalid schemas; require idempotency or explicit reconciliation for side-effecting operations. |
We implement agreed checks and adapters. The customer authorizes resources and provider accounts; tool contracts and high-impact actions are reviewed together.
Isolation & sandboxing
Keep generated code, tool processes and temporary files inside an approved execution boundary. A process, container or virtual machine is a mechanism—not a complete isolation argument.
- Responsibility
- Minimize capabilities, constrain compute and temporary storage, and deny unapproved network paths. Separate workloads according to the threat model.
- Interface shape
- An execution manifest containing an approved image reference, resource limits, permitted mounts, secret references and destination allowlist.
| Failure mode | Required handling |
|---|---|
| Resource exhaustion | Terminate bounded work, isolate the affected run and retain a safe failure record. Do not expand limits automatically. |
| Unexpected egress or boundary failure | Stop affected dispatch and quarantine execution. Assess credential exposure and host impact before restarting. |
We define execution controls in scope. The customer owns host hardening and network enforcement unless explicitly included; boundary testing is shared.
State & memory storage
Separate transient run state, durable business state and retrieval memory. Information that can be retrieved is not automatically information a principal may read.
- Responsibility
- Apply scope checks at read and write time. Preserve provenance, schema versions and deletion requirements. Do not allow retrieved content to redefine policy.
- Interface shape
- Scoped keys or queries carrying principal and workload context, source permissions, version preconditions and retention classification.
| Failure mode | Required handling |
|---|---|
| Stale permissions or missing provenance | Refuse the affected retrieval until authority can be established. Invalidate derived records when source access changes. |
| Partial write or conflicting version | Use explicit transaction or reconciliation semantics. Test restore and schema compatibility before resuming dependent runs. |
We implement scoped state access in scope. The customer owns source data rights, storage administration and retention decisions; deletion and restore tests are shared.
Observation & audit
Instrument decisions and outcomes across the other layers. Operational signals answer what is happening; audit records explain which authority permitted an action and what outcome was observed.
- Responsibility
- Propagate correlation IDs; record policy and tool versions, decision references and outcome states. Exclude credentials and avoid raw payloads by default.
- Interface shape
- Versioned, redacted events with timestamps, workload and run references, decision outcome, error classification and usage attribution.
| Failure mode | Required handling |
|---|---|
| Audit sink unavailable | Use an agreed bounded buffer. If required evidence cannot be preserved, block actions that require it; never silently discard records. |
| Missing or delayed events | Expose gaps and delivery lag as signals. Reconcile records without presenting incomplete evidence as a complete history. |
We define events and failure handling. The customer owns sink access, retention and protection; evidentiary requirements are confirmed together.