Runs in your environment
Agents run on your OpenShift or Kubernetes clusters, next to your data, managed with the tools your platform team already uses.
- One hub, many clusters
- Git and GitOps for every change
- Public or self-hosted models
Run AI agents with enterprise control
Carbon.run runs AI agents in your own infrastructure, with scoped access, human approvals, a full record and budgets that hold.
The pilot works. The rollout gets complicated.
Running one agent is easy. Running fifty across departments, on live systems and data, raises questions each team answers differently. A platform answers them once.
- Which agents exist, and who owns them?
- What may each agent touch?
- Who approves what matters?
- What does it cost, and who pays?
- How do we prove what happened?
One operating layer for all agent work.
The same paved road for every team: agent catalog, triggers, integrations, security, approvals, budgets, a full record and quality checks.
Access and approvals
Security writes the rules once, for every agent. Sensitive actions wait for a named person, and the agent continues the moment they decide.
- Allow, deny or require approval
- Plan approval before big changes
- Keys never reach the agent
Evidence of what happened
Every run leaves a transcript, a trace, its sources and every policy decision. You can answer what an agent saw and did, months later.
- Step-by-step transcripts
- Who approved what, and when
- Retention and legal holds
Cost you can see and limit
Tokens are counted outside the agent, priced at your rates, and shown per team, project, agent and run. Budgets can stop new runs at the limit.
- Alerts at 50, 80 and 100%
- Quotas against runaway triggers
- Showback with CSV export
One application for builders, operators, approvers and finance.
The dashboard is organised by what people do: build, run, observe, improve and govern. Everything you see can also be done as YAML in Git.
See what needs you first
Plans to approve and questions to answer sit at the top. Below them, every run, grouped under the agent that started it.
- Five run modes: one-time, persistent, scheduled and event-driven
- Stop, retry, resume or fork any run
- Bulk actions and saved views
Review a run step by step
The full conversation, every file read, every command and every comment posted, with timing, tokens and the result.
- Live stream while the agent works
- Send a hint to steer a running agent
- Artifacts previewed in the browser
Decide with the context in front of you
One queue for plans, write-back to Git, catalog and memory changes, and actions an agent asks to take. Each request shows what the agent proposes and its risk.
- The waiting agent costs nothing while it waits
- Requests expire, so nothing hangs forever
- Every decision records who and when
Know which agents exist
Agents, skills, tool servers and policies in one catalog, with their owner, model, policy and how often each is used.
- Import agents and skills from Git branches or tags
- Fork into a team, promote for everyone
- Malformed agents are rejected at the door
An agent is a reviewed resource
Instructions, model and fallback model, skills, tools, policy, secrets and where it may run. Edit it in a form or as YAML, and version it like any workload.
- Teach a capability once, reuse it everywhere
- Change models without changing agents
No surprise invoice
Spend per namespace, project, agent, model or single run, against the budget for the month. Finance gets numbers it can charge back.
- Monthly or rolling budgets per team
- Optional blocking of new runs at the limit
- Your negotiated prices, including self-hosted models
Operate agents like any production service
Personal and shared dashboards for requests, tokens, latency and spend, with alert rules and an in-app inbox.
- Prometheus metrics for your own monitoring
- Presets and kiosk mode for a team screen
See how the pieces connect
A live graph of agents, their runs, the tool servers they use and the clusters they run on.
- Spot shared dependencies at a glance
- Follow multi-agent work as one story
Screens show sample data for a fictional bank. All names and numbers are invented.
Agents propose. People decide what matters.
An agent picks up a ticket and delivers a reviewed merge request. The platform, not the agent's author, sets the boundaries at every step.
Something happens
A merge request, an issue, a schedule or a person starts the run. Filters and rate limits keep a busy repository from flooding the system.
A person approves the plan
Before a large change, the agent's plan goes to a person. The run waits without using compute.
The agent works in a fenced space
Short-lived access to the code it needs, the internet closed except for allowed sites, keys held outside the agent.
Sensitive actions wait
Merging, commenting or changing the catalog can be allowed, held for approval or denied, tool by tool.
Everything is recorded
Transcript, sources, policy decisions, approvals, tokens and cost. A summary goes back to the merge request.
Everything an agent platform is made of.
From your infrastructure up to the people who decide, with controls wrapped around every run. All of it is in production today.
People
Dashboard and assistant
Forms for business builders, YAML for platform engineers.
People in the loop
Every decision has a queue, an owner, a deadline and a record.
Agents
Agent catalog
Agents and their building blocks are declared, versioned in Git and shared on purpose.
Running agents
Agents that start on events and schedules, run for minutes or days, and can be steered.
Quality and improvement
Quality measured, not hoped for.
Controls
Security and access
Set by the platform team, built on the controls your security team already knows.
Cost and quotas
Finance knows who spends what; limits hold.
Observability and audit
The record is written as the work happens.
Connections
Models
Model access, keys and counting live outside the agent.
Integrations
Pluggable providers and open standards, so you are not locked to one vendor.
Your infrastructure
Multi-cluster
One place to govern; agents run where the data is.
Operations
The platform is a workload your team runs like any other.
A small set of reviewed rules covers every agent.
Your security team writes policy once instead of reviewing every agent. Agents cannot widen their own permissions, and a malicious repository cannot change their rules.
Keys never reach the agent
A proxy next to the agent holds the real model key and adds it to each request. An agent cannot leak a key it never sees.
Internet closed by default
Outbound traffic goes through a proxy that allows or denies by host or URL.
Secrets masked
Secrets are masked in model requests, transcripts and memory, in plain, JSON, URL and base64 forms.
Short-lived credentials
Signed, rotating tokens per run. Git tokens expire when the run ends.
Independent metering
Tokens are counted from the model responses, not from what the agent reports.
Workload identity
Optional SPIFFE/SPIRE identity per agent, verifiable by other systems.
Start with work someone owns and can check.
These are examples we assess with you, not packaged solutions. Carbon.run supports other governed work too, in development and in business departments.
Merge request review
Every merge request gets a first review against your own checklist. A person makes the final decision.
Merge request opened → agent reviews → comment and status posted
From ticket to merge request
An agent plans a bounded change from an issue, a person approves the plan, and the change arrives as a merge request for review.
Issue labelled → plan approved → merge request for review
Knowledge work with your playbook
Contract checks, reports or questionnaires done the same way every time, using your own tools and documents through MCP.
Request arrives → agent drafts with sources → expert approves
We develop Carbon.run with agents running on Carbon.run.
Our engineers approve every change. CROZ has built and run container platforms for demanding organizations for twenty years.
An engineer files a ticket → an agent plans, a person approves → the agent delivers a merge request → review agents check it, an engineer merges
Keep your assistants. Add agents that do work.
Assistants help individual people, and you should keep them. Carbon.run is for agents that work inside your systems, alongside what you have.
Carbon.run is most useful when:
- agents must run in your own infrastructure, or next to data in several networks
- several departments need agents under one set of security rules, budgets and approvals
- your platform team wants to run agents with the tools it already uses: OpenShift or Kubernetes, Git, GitOps
- you want to keep the option to change model provider without rebuilding your agents
From first conversation to a decision based on evidence.
Carbon.run is a starting point, not a box. CROZ fits it to your systems, your rules and your way of working.
Discover
A workshop with IT and business owners. Together we pick two use cases, one in development and one in another department, and agree how to judge the result.
Pilot
Both use cases on Carbon.run in your environment, with real users, approvals switched on and budgets capped. We connect your systems and set access, review and spend rules.
Decide
Time, quality and cost measured from the pilot. Then scale to more teams, adjust, or stop. Your platform team gets what it needs to run it.
Straight answers, so there are no surprises later.
On your OpenShift or Kubernetes clusters, in your data center or your cloud account. One hub can place agents on several clusters, so agents run next to the data under one set of rules. It is not a SaaS service.
Agents run on the Claude Agent SDK, with Anthropic models directly or through any Anthropic-compatible endpoint, such as your own AI gateway or a self-hosted model. Model access lives outside the agent, so you can change models without changing agents. A second agent runtime is planned.
GitLab is built in. Any system with an MCP tool server, such as wikis, ticket systems, document stores or your own APIs, can become an agent tool. Email and webhooks reach people and chat tools. GitHub and Bitbucket providers are planned.
No. You choose. Approval queues cover agent plans, questions, write-back to Git, catalog and memory changes, and actions an agent asks to take. For an agent's own shell commands and file edits, policy allows or denies them.
Audit records, policy decisions and run history are available through the API today. A ready-made SIEM connector is in progress.
No. Agents are configured in forms or as YAML. It is not a drag-and-drop workflow designer: an agent gets instructions, skills and tools, and works out the steps itself, within its policy.
The platform, plus the people who build it. We help you pick the right first use cases, fit the platform to your environment and rules, run the pilot with you, and prepare your platform team to operate it.
Let's talk about your first workflow.
Tell us the task, the team and what gets in the way today. We'll show you Carbon.run live on our own installation.