How the freedom is built.
The three freedoms are architectural claims, so they can be checked. This is what each one rests on — the provider boundary, the primitives underneath, the data plane you own, the loop that holds a run together, and the ledger that records what happened.
Back to EnterpriseThe provider boundary sits below the agent loop, not beside it.
A tool call emitted by one vendor’s model on step 3 is consumed by another vendor’s model on step 4, because the wire format is provider-neutral and the state lives in your database rather than in a vendor’s session.
- Model choice is configuration. A model name and an options table per step — not source code, and not an application rewrite.
- Adding a provider is one integration module. Written against a stable interface, with provider-specific behaviour handled behind capability gates.
- Self-hosted models bind the same way. The interface that binds a frontier API binds a model running on your own hardware, which is what makes air-gapped deployment possible.
- Reasoning effort is bound per step. Classification and final synthesis do not have to share a thinking budget.
- Eligibility is a hard gate, applied before ranking. A target is excluded unless it is available — that deployment, region and quota pool, not merely its provider — and compatible with this request.
- Failover crosses failure domains. The next target is picked to share the fewest of region, quota pool, credential and provider with the one that just went, so an outage takes an option out rather than the column.
- Capacity is routed, not just quality. A rate limit or a regional ceiling falls back to the next configured model, including across vendors.
- Context is layered, not replayed. Full history is stored; each step is presented only the layers it needs, so the prompt a long run sends does not grow with everything that came before it.
Any supported frontier or open-weight model can serve any step. Support means an integration module exists for that provider — the set grows, and adding to it does not touch the agent loop, the tool registry or the persistence layer.
Four portable stateful interfaces, plus a Kubernetes-class compute layer.
No new distributed-systems substrate — the same primitives that already run planet-scale web services. Each has managed implementations on the major clouds and a self-hostable equivalent, so moving between them changes an infrastructure module and nothing above it.
| Interface | What it holds | What a deployment runs |
|---|---|---|
| SQL database | Messages, artifacts, agent steps, permissions | Cloud Spanner |
| Durable execution | Agent runs, retries, timers, signals | Temporal — Cloud or self-hosted |
| Cache and pub/sub | Presence, real-time fan-out, rate limits | Valkey, or a Redis-compatible service |
| Object store | Files and large tool results | GCS, S3, or any S3-compatible store |
| Compute | The stateless services and workers | Any Kubernetes-class cluster |
Being an interface is what makes a binding movable, and the claim is about that rather than about every row being interchangeable today. Execution, cache, object store and compute are already chosen per deployment. The SQL layer runs on Cloud Spanner, and the persistence code is written to a backend-neutral shape so that binding is infrastructure work to move rather than an application rewrite. Deployment shape is a separate axis: dedicated tenancy, your own cloud account, or a network with no route to the internet, with regions and isolation requirements scoped per deployment.
The data plane is yours, down to the deployment.
Enterprise runs single-tenant. We deploy a stack for you, with its own database, so the tenant boundary is the deployment itself rather than a predicate every query has to remember. Inside that stack, workspaces and channels scope every row.
Nothing to request.
Conversations, artifacts, tool results and every agent step sit in your deployment’s own database, and files in its own object store. You query them directly, on your own credentials.
A deployment setting, not a negotiation.
Region pinning is configuration. Per-tenant encryption keys live in your KMS and rotate without application downtime. Encrypted at rest and in transit throughout.
A transaction against your own schema.
Retention windows, redaction and hard-delete run as operations you control. Personally identifiable fields are separated so redaction does not rewrite the record around them.
Membership and visibility, explicitly.
Workspaces, channels and content each carry membership and visibility. Administrators manage access, identity and isolation centrally.
Consequential actions wait for a person.
A tool can pause its run and put the question in the channel. The work stops until a member with write access answers, and the run resumes with that answer in hand.
Your activity, if you want it.
Every step is a prompt, action and outcome in your own domain — the shape evaluation and fine-tuning pipelines already expect. Owning that dataset is the architectural claim; whether you ever train on it is your decision.
The router is the commodity.
The loop around it is not.
Routing layers are interchangeable — a request proxied to one of N model endpoints, and several good implementations exist. What is not interchangeable is the provider-neutral loop wrapped around one, because that is where the run’s state lives and what a vendor’s session cannot hold.
- It holds the plan. What the run intends, revised as it goes, and readable by every step that follows.
- It fingerprints every tool call. A repeat is detected and escalated rather than quietly run a second time.
- It guards against plan regression. Plan version and completion deltas move one way, so work cannot silently go backwards.
- It pauses and resumes on a signal. A person’s answer reaches an agent mid-run; the work waits rather than restarting.
- It writes each step to the ledger. Committed with that step’s own database writes, before the next step begins.
- It asks the router on every step. Each call resolves through its capability’s menu, so the model is an output of the step rather than of the conversation.
None of that is a model feature, and none of it moves when a model does. It is why swapping a provider is a configuration edit here and a rebuild elsewhere: in a closed stack the loop lives in the vendor’s runtime, so leaving means rebuilding the plan, the dedup state and the record along with it.
One durable row per tool call, in your own database.
Not an observability trace that rotates out of a vendor’s retention window — durable application state, committed with the step’s own database writes instead of shipped to a system that ages it out.
One row per tool call, with agent_loop_state completing the record alongside it, carrying the loop’s plan and enforcement state per step. The prompt is not stored as a column; what the step received from the run is, every tool call and every result, so a replay feeds a model the recorded inputs rather than a hand-rebuilt approximation of them. The parts that live in code rather than in rows — the system instruction, and the body of any skill the run loaded — are whatever is deployed at the moment you replay. Because this is a table and not a log, an auditor’s questions are queries: what an agent did on a given date, every step that errored and what the loop did next, every tool call carrying a given fingerprint.
An agent run is a durable business process — not a disposable chat session.
The loop is a sequence of stateless steps inside a durable workflow: each step reads its state fresh, does its work, and commits the result before the next one starts. Durability and recovery are properties of the substrate rather than glue the application has to maintain.
- Crash recovery without lost work. A worker dies mid-step and the step retries elsewhere, because nothing in memory was load-bearing. Retries are at-least-once, so a tool that writes to an outside system can repeat that write. The guarantee is that the run survives the crash, not that every external call happens exactly once.
- Horizontal scale on one queue. Throughput grows with worker count: no shard to rebalance, no coordinator.
- Human input mid-run. An @mention reaches a running agent and re-prioritises it without restarting the work.
- Hardened sandbox for generated code. Code the agent writes runs isolated, never in the application’s process.
Latency and throughput figures for a given deployment are shared under evaluation, against that deployment rather than against a number on a page.
Choose what comes next.
Keep what happened.
Bring the questions your architecture review will ask. We will answer them against a deployment, not a diagram.