I spent the past few weeks setting up and using Centaur, and wanted to share it here. Building your own control plane and managing agents on your own infrastructure is increasingly accessible, and will only become more compelling as agent processes scale.
Considering this is a long(ish) article, let me be as direct as possible upfront so you don’t waste your time reading if it’s not for you.
If you expect agentic work to scale (you should), you are going to need a system for managing increasingly autonomous agents. You cannot micromanage every agent interaction, execution and workflow.
Most of us are building elaborate systems directly into the agent/harness (memory, tools, permissions, state and logic, etc.).
This is likely the wrong approach to scaling agents.
Ideally, the agent/harness should be one component inside a deterministic system, not the other way around.
Centaur is the best open source solution I’ve found for this.
It is essentially a Rust API backed by Postgres that records state and coordinates execution (control plane). When work needs to happen, the control plane > Kubernetes, which creates isolated sandboxes in which your probabilistic machines (agents) do the work.
This whole system becomes more compelling as agent interactions scale. If you’re still interested in exploring:
I did a longer explainer video of the entire thing if you'd prefer to watch.
Condensed walkthrough below with some diagrams.
What is Centaur?
Everything I'm sharing here is open source. Centaur was created by Paradigm. It's an open-source control plane, a Rust API and Postgres database, for running and owning your own agent infrastructure.
Designed for teams, but (imo) seems like a good architecture for individuals managing agents at increasing scale.
The TLDR: do not build the system into the agent or harness. Make the agent one component inside a deterministic control plane that you own and manage one layer up.
Give the agent an isolated Kubernetes sandbox with a thin set of tools and workflows, and the ability to write and execute code. Keep the harness thin. Keep the secrets out of the box with Iron Proxy.
A few weeks back, Eiso Kant (from Poolside) shared the following re keeping the harness thin: giving the models a thin set of tools, and the ability to write/execute code.
Strongly recommend listening to this (2 mins).
Put the agent inside the system
(I don't have any strong opinions about defining 'agent' and 'harness') - but for the purposes of understanding control versus execution, let's just say the agent = model + harness.
The model is the neural network, the probabilistic brain in the middle. The harness is everything else that goes into making the agent. It includes memory, tools and the agentic loop that enables the model to act and take action in the world.
However, once you start scaling to many people and many agents, you do not want the system inside the agent. You want the agent and the harness to be one component inside the larger system.
When you are one person, you are the system
The marginal cost of intelligence is rapidly approaching zero. Most of the world still treats AI like a dumb chatbot, but we are very early. Agents proactively and autonomously taking action will only increase from here.
The challenge, and also the feature, is that language models are probabilistic. People like to complain about hallucinations, but prediction is the defining feature of these machines. Trying to manage an exponentially growing number of increasingly autonomous agents is going to be a massive challenge.
Imagine you have a genius intern with severe amnesia who is also slightly unhinged. Would you give this intern unfiltered access to your computer, your passwords and everything important?
Now multiply that by one hundred, one thousand or one million.
You cannot micromanage all of those agent processes, and you do not want a probabilistic machine behind the wheel.
What you need is a system to coordinate those agent processes at scale, so each one has exactly what it needs and a controlled blast radius. So it will not fuck shit up.
Give each agent process its own computer with the thinnest possible set of tools.
You need a surrounding system that reliably tracks what was requested, what is running, what has completed and who can do what. Those facts cannot depend on a probabilistic agent remembering to update them, a human trying to manage everything, or a particular harness staying alive.
This is an old systems engineering concept with renewed importance as agents become more capable and autonomous. Deterministic infrastructure around probabilistic execution.
Managed agent products already do this for you
Devin and Cognition were very early to this architecture. Amp recently released Orbs. Cursor has been doing this for a while, and Grok Bot also runs agents remotely.
When you use one of these services, the work is not happening on your computer or device. It runs in a dedicated virtual machine somewhere in the vendor's cloud. The vendor manages the model, access, approvals and sandboxes.
Inference margins are probably a large part of the answer. If a vendor controls the system you use, it also controls the models you use. The money is in inference and selling tokens.
The tradeoff is that the vendor owns the system on your behalf. Whatever system you want has to take the shape of its service. It controls which models, environments and workflows you can use.
Coding agents change that. Open source systems such as Centaur have already done much of the hard work. Cole Murray's Background Agents project is another open source example with a similar architecture and some different choices.
The TLDR of Centaur
Centaur divides the system into five architectural planes: ingress, control, execution, capabilities and egress.
The control plane
The control plane is the bread and butter.
At a high level, it is a Rust API and a Postgres database. Those two components are the deterministic control plane we have been talking about.
The modularity is one of the things I like most about Centaur. You can fork and lock the base repository, then create a separate overlay containing your specific business logic, workflows, tools, skills and agent identities. You do not need to put any of that into the base repo.
The execution plane
The control plane does not do the work. It is the orchestration layer. It orchestrates the environments where the work actually happens.
It decides what should run and sends those instructions to Kubernetes. Kubernetes creates, runs and supervises the sandbox containers.
This is the crux of it. Each agent gets an isolated computer in which to do its work.
Keeping credentials outside the sandbox
For an agent to be useful, it needs access to stuff. It might need Slack, GitHub, your CRM, model provider keys or another service. If you put the real credentials inside every sandbox with the agent, it is a recipe for disaster, particularly when prompt injection is involved.
Centaur solves this with Iron Proxy. The real keys stay outside the sandbox.
The agent receives fake or placeholder environment variables. When it makes an approved outbound request, Iron Proxy adds the real credential as the request leaves the sandbox. The agent can use the credential without ever seeing it.
Centaur Context is the missing piece
Centaur is the system that orchestrates and wraps the work your agents do. It stores operational state, including conversations, executions, workflow progress and what happened.
But it does not actually store or accumulate context and knowledge.
I think that is the missing piece here: the context factory. Building, owning and compounding context.
So I built Centaur Context, a separate open source application and UI that runs alongside Centaur with its own Postgres database.
Every time you have an agent interaction within Centaur, the agent can read from the stored and accumulated knowledge. Every time an interaction finishes, the system writes back to the same knowledge base.
The Curator takes the finished thread and places what is worth keeping into the shared context. It adds useful records and connects them to what already exists.
The Context Builder finds information relevant to the current request. Before the agent runs, it assembles a packet of relevant Objects, Connections and information for the agent to use.
A simple ontology for people and agents
Everything exists as an Object. An Object has a type, such as a Person, Task, Chat, Source or Memory. It also has a stable identity, title and description.
Objects are joined through Connections. Each Connection has a defined relationship and an explanation of why the relationship exists.
For example, the podcast episode I added in the demo is a Source. Sarah Guo is an Entity connected to it. The transcript is stored as an Artifact supporting the Source.
One interaction from start to finish
So now I want to come back to the demo and run through the workflow so you can see how it works.
I have a research agent called Rez that I talk to through Slack. I ask Rez to add an Invest Like the Best interview with Sarah Guo.
The request enters through Slack and is translated into the Centaur control plane. Centaur records the request and starts Codex inside an isolated sandbox with the identity, tools and permissions it needs.
Later, I ask Rez what Sarah Guo said about recursive self improvement in the interview.
Before Rez answers, the Context Builder searches the shared knowledge base and finds the saved Source. Rez can retrieve the transcript, find the relevant passage and answer from the original evidence.
The important part has nothing to do with the Slack bot itself.
The knowledge now exists outside the Slack conversation where it was first captured. Another person or agent can use it later.
The source ingestion workflow is specific to my company and lives in a private overlay. It is an example of what can be built on top of Centaur and Centaur Context. It is not included in either public repository.
The unglamorous work
I think the best place to start with evaluation is making sure you can see every interaction, and exactly what data, tools and information are being injected into each sandbox. That includes the system messages.
In one of my early interactions, a simple request started with about 30,000 input tokens. That did not sound right. I traced it back to a large prebuilt system prompt being sent into the sandbox with the Codex agent.
This is the important, unglamorous work. Look at the traces. Check the evidence. Review the Connections. Remove unnecessary context. Correct what the system got wrong.
How I would get started
Follow the official Centaur Quickstart and get one supported interaction running.
Once that works, follow the instructions to create an overlay. Start with the example overlay and add one tool or workflow for your particular use case.
Once you have both of those things working, install Centaur Context if you want this additional layer for compounding shared context.
Centaur Context currently requires two small hooks in the Centaur Slack interaction path. Before an agent runs, Centaur asks Context for relevant shared knowledge. After the interaction, it sends the conversation back for capture and curation.
That is it. If you get this running, or have any questions, please hit me up. I would love to work on this with other people who are interested in building and owning their own agent infrastructure, and particularly this component for compounding knowledge and context across agents.
I am also interested in what other people think. Is anyone already doing this? Are there other open source projects I should look at? Does this eventually make sense for individuals, or will it remain overkill outside teams?
Centaur:
Centaur Context:
Centaur Context GitHub repository