Ship agents your organization can trust
Corbits is a platform for deploying secure, auditable agents with organizational guardrails. You get the run, audit, and manage layer that turns a promising agent into something you can put in front of real work: control over what agents can do, an audit trail of what they did, and observability into how they’re behaving right now. This is the part of the agent stack most teams are missing. Building an agent is the easy 20%. Running it safely — with the right permissions, a record you can hand to security, and the ability to shut it down when it goes wrong — is the other 80%. Corbits owns that 80%. It is not a general agentic toolkit; it’s the control plane you run agents on. That serves two readers at once:- Builders and developers who want to ship capable agents without hand-rolling permissions, secrets handling, and audit logging for every deployment.
- Enterprise evaluators — a head of AI, plus the compliance and security teams standing behind them — who need to know an agent can be granted exactly what it needs, nothing more, and that every action is accountable. Control and audit is the whole point.
The platform in one view
Corbits is layered. Apps sit on top. A control plane runs, governs, and audits the agents that run on it. An agent runtime does the work.1
Apps
Finished products people use every day — Intercode and Workbench. Workbench runs on the control plane below: the same credentials, grants, and audit trail described here govern its agents. Intercode is a standalone CLI that applies the same guardrail discipline in its own process rather than on the control plane — the right boundary for a local tool.
2
Platform / control plane
This is the layer that runs, governs, and audits agents. Organizational guardrails live here: what an agent is allowed to touch, which credentials it can use, and a tamper-evident, cryptographically signed record of everything it does.
3
Agent runtime
The execution engine underneath, powered by Interchange. It runs the agents; the control plane decides what the ones deployed on it are permitted to do while they run.
We build on this stack ourselves. Workbench is a first-party app running on the same control plane we offer you — the credentials, grants, and audit trail described here are the ones it depends on. Intercode is a standalone CLI that applies the same guardrail discipline — enforcement as tool middleware, hard-deny guards — in its own process rather than on the control plane.
The apps
Two flagship apps show what the platform makes possible.Intercode
A standalone coding-agent CLI. Bring agentic coding into your workflow, guarded by the same enforcement discipline — tool middleware and hard-deny guards — enforced in-process.
Workbench
A go-to-market workspace where agents do real GTM work — governed, observable, and accountable by default.
Guardrails: control what agents can do
The heart of the platform is how it governs agents. Corbits separates Credentials — the secrets and identities an agent can act with — from Grants — the specific, scoped permissions that say what it’s allowed to do. Grants are fail-closed: if nothing explicitly permits an action, it’s denied by default. That’s what lets an organization hand an agent real capability without handing it the keys to everything.Guardrails: Credentials vs. Grants
How organizational guardrails work — scoped grants, credential separation, and default-deny. Start here if you’re evaluating for security or compliance.
Bring any major model, no lock-in
Model choice is a property of the Interchange runtime at the base of the platform: it speaks to the major model providers natively, so you pick models on cost and capability rather than on what your platform happens to support. Anthropic (with extended thinking and prompt caching), Google Gemini, and OpenAI are first-class, alongside any OpenAI-compatible endpoint (OpenRouter, self-hosted, or local). Run several models side by side, or move a workload to a cheaper one, without re-platforming. No single-vendor lock-in, and no waiting on us to add the model you need.Durable, resumable workflows
A single agent turn is not the unit of real work. The jobs teams actually want to automate run for hours, hand work across several agents, and have to survive a process dying partway through. Multi-step orchestration is a property of the Interchange runtime at the base of the platform, which runs a workflow as a declared graph of steps rather than an open-ended agent loop. Declaring the graph up front is what makes the run bounded and recoverable:- Loops are bounded. A loop declares its maximum iteration count as part of the definition, and a definition that omits it is rejected. A rework loop cannot spin past its declared ceiling.
- Actions are checkpointed and replayable. An action step is a host-effect node rather than a model call. Its external effects run through a capability-checked, deduplicating effect ledger, so a replayed handler sees the results already recorded instead of re-firing work the run had committed.
- One stage, many items. A map step runs the same agent step once per item in its input and gathers the results in order.
- Cycles are caught at definition time. The step graph is validated when the workflow is defined, so a dependency cycle fails then rather than in production.
- Crashes do not double-fire effects. A run that dies mid-loop resumes without repeating effects it already committed, and an agent step interrupted mid-invocation refuses to re-invoke rather than risk running its side effects a second time.
Where to go next
Guardrails
Credentials, grants, and default-deny — the control model.
Intercode
The standalone coding-agent CLI, built on the platform’s runtime primitives.
Workbench
The governed go-to-market workspace.