Most organisations do not have an AI agent problem. They have an AI agent sprawl problem: a pilot here, a copilot there, three teams each wiring their own tools, and nobody able to say what any of it is permitted to touch or whether it still works after the last model update.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
AgentOS is our answer — the shared platform underneath the agents we build, rather than another one-off agent. It is designed to be the place where an agent is designed, given tools, given policy, evaluated, released, and then watched in production.
What It Is Designed To Do
- Agent and workflow design — define what an agent does and the steps it may take, in one place rather than scattered across prompts.
- Model routing and provider abstraction — choose the model per task, and change that decision later without rewriting the agent.
- MCP and tool registry — a governed catalogue of what tools exist and which agents may call them.
- RAG collections and source governance — control what an agent may retrieve from, with permissions respected at query time.
- Prompt, skill and configuration versioning — changes are versioned artifacts, not edits someone made on a Tuesday.
- Policy and approval engine — consequential actions route to a human by rule, not by convention.
- Evaluation and release gates — an agent does not ship because it demoed well; it ships because it passed its test set.
- Execution traces, cost and latency observability — what the agent did, what it spent, and how long it took.
Why Build a Platform Instead of More Agents
Because the second agent is where the cost shows up. The first one is a project; the fifth one is an operations problem — five sets of credentials, five evaluation approaches, five ways of finding out something broke. A platform makes governance the default rather than something each project reinvents.
This is the same discipline we already apply to individual builds: scoped permissions, evaluation before rollout, and human approval where it matters. AgentOS is that discipline made reusable. It draws on the same foundations as our MCP development, RAG and evaluation work.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Frequently Asked Questions
What is AgentOS, and what is it not?
It is not a model, and it is not an end user chat product. It does not generate text itself; it calls providers that do. It is not an agent either, so nothing inside it answers a question or files a ticket until someone defines an agent in it. It is not a data warehouse: RAG collections are designed to point at sources that stay where they are, not to become a second copy of them. And it is not deployable today. It is in development, there is no build to install, and everything described here is design intent rather than shipped behavior.
What does it connect to, and what has to already exist on our side?
On the tool side the intended connection path is MCP: an agent reaches a system through an MCP server that exposes that system's operations as tools with schema defined inputs, rather than through integration code written into the agent. So the systems you want reached need an API and someone willing to authorize access to it. On your side the assumptions are an identity provider that can issue and validate tokens, an account with at least one model provider, and somewhere to run the platform and its connectors. Identity is the one that cannot be substituted. Without a directory that can be queried at call time, per user permissions have to be recreated inside the agent layer, which is the exact condition the platform is designed to remove.
Does it replace the systems we already run?
No. The system of record stays the system of record, and the MCP and tool registry is designed to describe what those systems expose rather than to hold their data. Identity is designed to come from your existing provider over OIDC or SAML instead of a separate user list. Approval requests are designed to route into a channel people already watch, not a new inbox that nobody opens. Execution traces are designed to be emitted in a form existing monitoring can ingest, using standard span and trace context conventions, so cost and latency land beside the rest of your telemetry rather than in an isolated console.
How is a rollout designed to proceed?
In order, and the order matters. First identity and one model provider, so every call is attributable before it is useful. Second, one MCP server for one system, read only, registered in the tool registry so what exists is visible. Third, one agent with a narrow task and a written test set, run against that set offline. Fourth, write access, and with it the policy rules that decide which actions route to a human and who that human is. Fifth, one real workload with traces and a named owner. Then promote it through a release gate.
Where does our data go, and what stays under our control?
The design keeps source data in its source. A RAG collection is designed to hold embeddings and pointers, with the permission check applied at query time against the identity of the caller, so a document a person cannot open is not reachable through an agent acting for that person. Prompts, skills, policy rules, tool grants and evaluation sets are your configuration, held as versioned artifacts you can export. Traces are the one place content accumulates, since a trace records what was sent and what came back; retention, and whether prompt and response bodies are stored in full or redacted, is designed to be your setting. What crosses a boundary is what an agent sends to a model provider, which is why routing is designed to be a governed decision rather than a per project one.
How is it designed to fit the delivery process we already have?
By behaving like code rather than like a console. A prompt change, a new tool grant or a policy edit is designed to arrive as a diff with an author, an approver and a version number that a later trace can be matched back to. Evaluation is designed to run in the pipeline that already runs your tests, so an agent that fails its set blocks the way a failing build blocks. Rollback is designed to be selecting an earlier artifact version, not reconstructing what a prompt said last month. Nothing here assumes a new change process; it assumes the one you have and gives it something versioned to act on.
What do we have to provide or decide?
Which systems are in scope, and for each one whether an agent may only read or may also write. Who owns each agent when it misbehaves at two in the morning. Which actions are consequential enough to require a human, and which role that human holds. What retention applies to traces. Which model providers are acceptable, and whether any category of data may not be sent to a hosted one. What a cost ceiling per agent should be. The hardest of these to hand off is the test set: it encodes what correct means for your work, in your cases, and nobody outside the business can write it for you.
What happens when a model changes or we want to switch providers?
The model identifier is designed to be treated as versioned configuration, not as an environment detail. Routing is designed to let a model be chosen per task and changed later without rewriting the agent, which only helps if the change is testable: the same evaluation set is designed to run against the candidate before it is promoted, and each trace is designed to record which model produced the run. Providers differ in tool call formats, context limits, and how strictly they hold to a supplied schema, so a swap is a change to be evaluated rather than a toggle to be flipped. Hosted model versions are also deprecated on the provider's schedule, which is the argument for keeping the pinned version in an artifact you control.