Everything an agent needs to run in production, as one system.
You write the agents and choose the models. Tanomis supplies everything in between: execution, authority, supervision and evidence, built as one and delivered whole.
Sandbox, durable session, state and recovery.
Identity, credentials, models, tools and MCP.
Policy at three enforcement points, limits and approvals.
Traces, evaluations, a verifiable audit ledger and cost.
From an empty directory to a running, supervised agent.
Your team writes the agent. Tanomis supplies everything required to put it into production.
$ tanomis agent new support-copilot --harness claude-agents-sdk
✓ project scaffolded agent.py, agent.yaml, tests, lockfile
$ tanomis agent deploy . --tenants all --dry-run
✓ name, version, target tenants checked file count, checksum
✓ nothing uploaded yet
$ tanomis agent deploy . --scope global --tenants all
✓ built remotely immutable version
✓ snapshotted warm support-copilot@0.1.0
✓ enabled every tenant
$ tanomis session run support-copilot --tenant northwind --prompt …
✓ session and run live events streaming
● live in your terminal and in the Console
- ScaffoldA working projectagent.py, agent.yaml, tests and a lockfile.
- CheckA dry runName, version, target tenants, file count and checksum.
- DeployAn immutable versionBuilt remotely, snapshotted warm, enabled per tenant.
- RunA session and a recordEvery session and run, with decisions and ledger entries.
Bring your own agent, or start from an example.
Any framework, your own code
Tanomis hosts the harness of your choice and normalizes what it emits. Author code runs unmodified.
--harness claude-agents-sdk
Deploy what you built locally
Built an agent in Claude Code, Codex or Cursor? Deploy it to Tanomis and it runs governed, for your whole team.
“Deploy this agent to Tanomis.”
Start from a ready-made team
Take an example process with its agents, tools and controls already defined, and adapt it.
An agent is not a service with a model attached.
An agent chooses its own next step, so every part of its environment becomes a decision someone has to make before production. Tanomis makes them as one platform.
Every layer of supervision, on one execution path.
Each layer answers a different question about the same work, and catches something the others do not.
Every action gets a decision.
Only what falls outside the rules reaches a person, with the evidence beside it: the agent’s note, the records it compared, and the rule that stopped it.
Observability tells you what the agent did. Tanomis establishes whether the work was done.
- ObservableWe can reconstruct what the agent actually did.From the sealed trajectory and the hash-linked audit ledger.
- VerifiableClaims and effects are checked independently.By reading the systems of record, rather than asking the agent.
- SettledThe evidence reconciles into one outcome.Confirmed, partial, contradicted or unknown.
- AcceptedThe settled outcome satisfies the delegation.Against the objective, procedure, constraints and approvals given.
The action path and the verification path are separate on purpose: the agent never reports its own outcome.
One API, one console, one record.
Fleet visibility, versions, audit, performance and cost and outcomes per agent, for the people who run the agents and the people who own the work.
Reference architecture, from the request to the record.
Runs on Kubernetes, every subsystem a Kubernetes workload, on any cloud or on-premises. Open OIDC · OpenTelemetry · MCP · Gateway API. You keep the keys and the record.
Start managed. Move the trust boundary when you need to.
Same agent, same operating model. Changing the boundary does not change the agents, the APIs, the policies or the supervision model.
Tanomis Cloud
The easiest start.
BYOC
Your cloud, your trust boundary.
Self-hosted
Your infrastructure and operations.
Open standards underneath, so it runs where you already run things.
- Kubernetes and its object model
- Signed OCI images
- OIDC and OAuth 2.1
- OpenTelemetry, Gateway API, MCP
- PostgreSQL and object storage
- kubectl, Helm, your GitOps
- Your monitoring stack
- Your identity provider
- Your secret manager and cloud account
- The team that already runs your clusters
- A managed service tied to one cloud
- A vendor-operated data plane
- A proprietary runtime or SDK
- Any single model provider
- Our console, for day-two operations
What leaving looks like: the images are standard, the state is in your database and the ledger is in your storage, verifiable without us.
What your security team will ask.
Does the agent hold credentials?
No. Credentials are attached at the per-tenant gateway. The agent itself has no network and no identity of its own.
What can an agent reach?
All outbound traffic leaves through the effect gate, the sandbox’s only exit. Destinations are allowlisted, and undeclared or unsettled effects are refused. The Kubernetes API is denied to the sandbox.
Can we cap what agents spend?
Yes. Limits on spend, tokens, steps and time are enforced at the gateway as they are spent, and a run that will not stop is stopped.
How do we know the work was actually done?
Effects are verified independently by reading the systems of record, not by asking the agent, then settled and accepted against the original delegation.
Where do our data and records live?
With BYOC or self-hosted, your workloads, data, state and keys stay in your environment. The trajectory record stays under your keys and is not training data for us.
Can we keep our own security tools?
Yes. The policy engine, the guardrail service, the agent harness, the model providers and the evaluation stack are replaceable.
Start with one process. Every control on from day one.
The commands, the manifest and the full reference are in the docs.