About AgenticOS¶
AgenticOS is the operating system for a company's AI agents: self-hosted, open source, multi-tenant.
It exists because of one observation. Most agent frameworks give you a library — you write Python, you deploy it, and every change to an agent's behaviour is a pull request, a review and a release. That is exactly right for a product feature and exactly wrong for the forty small agents a company actually wants, because the person who knows what the agent should say is not the person with commit access.
So here, code defines and configuration composes. A business team assembles agents in a browser — instructions, a model, a set of capabilities, a budget — and engineers extend what there is to assemble, in typed Python. Configuration can only ever reach what code registered, which is what makes a no-code Builder safe to hand to somebody who is not an engineer.
The spec is a document, so it versions on publish and exports as YAML into your own git repository. The ceiling is not that document: it is whatever your engineers put in the registry.
What makes something an operating system for agents¶
The word gets used loosely in this category, which is a fair complaint. It is worth stating what it has to mean, because an operating system is not a mood: it is seven jobs, and a product either does them or it does not.
Use this as a test. Run it on AgenticOS, and run it on anything you are comparing it against.
| An operating system… | …and for agents that is |
|---|---|
| Runs and isolates processes | A run is the process. It starts, it can be stopped, it is isolated from other tenants, and it leaves a record of what it did |
| Enforces resource limits — quota, cgroups | A budget, checked before the work is allowed rather than tallied afterwards, on a unit somebody is accountable for |
Controls access — users, permissions, sudo |
Permissions checked at the call site, not role names; and an escalation path for anything that acts on the outside world |
| Reaches hardware through drivers | One interface to many model providers and many tool servers, so swapping either does not rewrite the thing using it |
| Keeps a filesystem | Somewhere durable for the organization's own knowledge, with the access rules attached to it |
| Gives many interfaces one shell | The same agent answering on every surface through one execution path, rather than each surface assembling its own |
| Writes an audit log | Who ran what, when, what it cost, who approved it — written whether or not the run succeeded |
How AgenticOS answers each one¶
| Processes | Runs are first-class: history, cost, status, and tenant isolation enforced by database constraints rather than by service code |
| Resource limits | Monthly budgets per agent, checked before each model request. A run that fails still records what it spent, because a budget that ignores failures is not a budget |
| Access control | A permission catalog in code, roles composed from it, per-resource grants that widen and never narrow. approval: required is the sudo — the run parks and waits for a person |
| Drivers | 27 model providers behind a model profile, and any MCP server by URL. Change the profile and every agent using it moves, without one being republished |
| Filesystem | Collections, skills and context in your own Postgres, embeddings keyed per organization |
| Shell | One runner behind web chat, the API, Slack, Telegram, a widget, a hosted page and a schedule |
| Audit log | Every run, every approval decision, every secret rotation — with values, never rows, and never a plaintext key |
Why the test is written to be applied to us too
A checklist that only ever produces one answer is marketing. This one is genuinely usable against any product in the category, and it is how we would like to be judged — including on the row below, where the answer is not yet good enough.
Where this one is not finished¶
Monitoring is the weakest of the seven. Every run records a
logfire_trace_id and nothing yet reads it, so what you get today is run
history, cost and status rather than a trend you can act on. It is on
the roadmap as R11.
Two more gaps worth knowing before you compare: there is no SAML or SCIM yet — sign-in is JWT, API keys, Google OAuth and magic links — and there is no evaluation harness, so testing an agent before publishing it is something you do by hand.
Who it is for¶
A company that wants more than three agents, and wants them governed.
- The person who builds the agent does not write Python. They write instructions, switch on capabilities, point at a knowledge collection and set a budget.
- The person accountable for the bill gets budgets that stop a run, approvals on anything side-effecting, and an audit trail.
- The engineer gets a spec that exports as YAML into their own git repository, an HTTP API, and a platform they can read the source of.
What it deliberately is not¶
It is not a framework for writing one agent. Pydantic AI is the runtime underneath, and if what you want is a single agent in Python as part of a product, use it directly.
That is not the same as saying this is closed to code. Extending it is Python — a capability is typed, tested code in this repository, and a connector, a channel or an ingestion strategy is the same pattern. The difference is that you write the tool once and everybody composes with it afterwards.
It is not a hosted service. Nothing phones home. Model prices come from a snapshot bundled with the release, and the only outbound requests are the ones your agents make. An operating system installs on your own machine; nobody rents a kernel per seat.
It is not a place to write integrations. An integration with a SaaS product is an MCP connection, not a Python module somebody in this repository maintains against that product's API. That is why the capability catalog is short and stays short.
The part that is actually the product¶
Most of the value here is in what the platform refuses: a cross-tenant read, an ungranted scope, a budget breach, a second decision on a decided approval, a spec that fails validation at publish.
The happy path — a model call with some tools attached — is the easy half, and a dozen libraries do it well. The refusals are the half that decides whether you can hand an agent to somebody who is not you.
When to use something else¶
Four of the seven jobs are things a library will never do for you, and three of them are things a hosted platform will do without giving you the machine. Neither is a criticism; they are different products.
Where it came from¶
Generated from the Full-Stack AI Agent Template, which is why "the platform layer" and "template-inherited" are distinctions that show up in the contributor docs. The platform layer — everything AgenticOS adds on top — is held at 100% test coverage in CI. The inherited subsystems are reported but do not gate the build, because holding code we did not design to the same bar buys a coverage number rather than confidence.
The six decisions behind the shape of it — why an agent is a file, why the spec
format only moves forward, why validation happens at publish — are written for
contributors in
docs/about/design.md.
Who builds it¶
Vstorm, and whoever sends a pull request.
Recap¶
- Code defines, configuration composes — a business team assembles agents, engineers extend what there is to assemble, and neither waits for the other.
- "Operating system" is a specification here, not a label — seven jobs, each with a mechanism behind it.
- The test is meant to be applied to other products too, and to this one: monitoring is the row where the honest answer is "not yet".
- The product is mostly the refusals, not the happy path.
- It runs on your machine, because that is what an operating system does.