Self-hosted  ·  Apache-2.0  ·  Postgres + Docker
AgenticOS

One place to build, run and govern your company’s AI agents.

5,802 MCP servers 27 model providers 8 places it answers
built by
The problem

Five places.
Four questions nobody can answer.

A company ends up with agents in five places: one in a vendor’s copilot, one the data team wrote in a notebook, one inside a SaaS product you already pay for. Then somebody asks which agents are running, what they cost, what they touched, and who allowed it — and there is nowhere to look.

AgenticOS
What you already have

Three things you own, and cannot use yet.

The data
In Drive, in Confluence, in Postgres, in ten thousand PDFs nobody has read since they were signed. It is an asset the moment something can answer from it, and a storage bill until then.
The models
A subscription, a key, sometimes a GPU in the rack. Every team reaches a different one, with its own key and its own bill, and nothing compares them or moves an agent between them.
The place people work
Slack, Mattermost, a helpdesk, a channel per client. The tools that could help live somewhere else behind another login, so people go back to asking a colleague.

None of these is a missing feature. All three are yours already — what is missing is one place that puts them together.

AgenticOS
The idea

Code defines.
Configuration composes.

An engineer registers a capability once — typed, tested, reviewed. After that it is a switch in the browser for everyone else, and configuration can only ever reach what code registered. That is why the builder is safe to hand to somebody who does not write Python.

Every publish is a version. Promote it from dev to prod when it is ready — each environment with its own keys, its own budget and its own trace.

AgenticOS
Capabilities and the approval gate
Configuration, composing
Choosing what an agent may touch is a set of switches
The whole harness as switches: retrieval over your documents, a real browser, Python in a sandbox with files and a shell, charts, delegation — and any tool from a connected MCP server. Each one can be set to wait for a person before it acts on the outside world: the sudo of this platform.
What a spec holds
Instructions
What the agent is for, and what it must refuse
Model
A profile, not a vendor name. Change the profile and every agent using it moves — without one of them being republished
Capabilities
Which tools it may reach, and which of them wait for a person before acting on the outside world
Knowledge
Collections, skills and context files bound to it — including AGENTS.md, as a page somebody edits
Budget
A monthly cap, checked before each model request rather than tallied afterwards
Automations
The 07:00 triage, the Monday summary — a schedule or an event trigger, under the same limits and the same record as anything a person asked for
Exposure
Which of the eight surfaces it answers on, and who is allowed to reach it there

Versioned on publish, and exportable as YAML into your own git repository — so the thing under review is a file, and the thing that runs is the same file.

AgenticOS
The agent builder
The spec, in a browser
A draft, a published version, and the difference between them
Instructions, the model, the endpoint. Draft differs from v40 beside published — what is running is never what is being edited, and the promotion to prod is a deliberate act.
One runner

Built once. Answers in eight places.

Web chat
In the console, for everyone inside the organization
Slack
A mention runs as the person who sent it, in their own thread
A hosted page
A link you can send outside the company, with its own limits
Telegram
The same agent, the same budget, a different address book
An embedded widget
A snippet in your own site, with a scoped key and no login
Mattermost
For a company that keeps its chat on its own servers
The HTTP API
For your own product to call, authenticated by API key
A raw WebSocket
For a front end you are building yourself, token by token

Same budget, same approval gate, same audit trail — because it is the same runner behind all eight.

AgenticOS
One agent, answering
The reasoning, the tools it reached for, and what it cost
A person sees the answer. Whoever runs the platform sees which documents it cited, which commands it ran, and the tokens behind both.
Your documents

A scanned contract and a clean invoice are not the same problem.

PyMuPDF
Local, fast, and the only one that pulls images out to be described. The default, and no key
LiteParse
Local and layout-aware: keeps a table as a grid instead of flattening it into prose. OCR for scans, at a language and resolution you set. Nothing leaves your network
LlamaParse
Cloud, priced per page, four quality tiers — for the scans the two local readers mangle. Your own key, billed to you

Set per collection, or overridden for one upload: how a document is split (recursive, markdown or fixed), whether images get described, and how many pages to read at all. A choice, not a black box.

AgenticOS
The ingestion configurator
The configurator
Set once for the collection, overridden for one awkward file
Parser, OCR and its language, how the document is split and how large the pieces are, whether images get described and by which model. Most platforms give one ingestion path and a slider; this is where retrieval quality is actually won or lost.
The tools you already pay for

If the tool exists, you connect it — you do not build it.

5,802
MCP servers in the catalogue,
searchable by name
27
model providers behind
one interface
35
dashboard cards, arranged
by whoever is reading

Any server by URL, and the only work is choosing which of its tools this agent may reach. Ollama and a LiteLLM proxy are two of those 27 — so a model on your own GPU is a provider like any other, not a special case.

AgenticOS
MCP connections
MCP connections
Searchable by name, connected by URL
Every server in the catalogue is searchable by name and connected by URL — organization-wide connections and personal ones side by side, each carrying only the tools this organization allows an agent to reach.
The part that matters

The value of a platform like this is mostly in what it refuses.

refusedAnother organization’s key. A stored credential is sealed to the organization that stored it, so a bug in an unrelated code path still cannot decrypt yours.
refusedA secret in a response, a log or an audit entry. So the audit trail goes to an auditor unredacted.
refusedThe model request that would breach the month’s budget. Checked before the call rather than tallied on the invoice — and a run that fails still records what it spent.
refusedA second decision on a settled approval. A double click, a replayed webhook, two admins at once: nothing gets approved twice.
refusedA broken agent reaching a customer. A spec that does not hold is refused at publish, never halfway through a conversation.

Each of those is a test that fails without the code enforcing it, in a layer held at 100% coverage in CI. Our evidence is not how many companies use this — it is that your security team can read why.

AgenticOS
Approvals and spend
Governance, not a promise
What is waiting on a person, and what the month has cost
An approval is a row somebody decides once. Spend is per agent and per run, recorded even when the run failed — which is the number the next request is checked against.
Why we call it an OS
the test we would like to be judged on
Runs processes
Runs agents, stops one at its budget, keeps tenants apart in the database rather than in code
Enforces limits
Monthly caps per agent, checked before the request. A run that fails still records what it spent
Controls access
A permission catalog in code, roles composed from it, grants that widen and never narrow. Approval is the sudo
Talks to hardware
One interface to 27 model providers and to any MCP server by URL — the driver layer
Keeps a filesystem
Collections, skills and context in your own Postgres, with embeddings kept per organization
Gives one shell
One runner behind all eight surfaces, plus a schedule and an event trigger
Writes an audit log
Who ran what, when, what it cost, and who approved it. Written even when the run failed
AgenticOS
Where it runs

Your Postgres.
Your Docker. Your network.

Nothing leaves
No tenancy on our infrastructure and no telemetry back to us. The model provider is your account and your key — including a model you run yourself, through Ollama or a LiteLLM proxy on your own network.
Apache-2.0
Read it, audit it, fork it. It keeps running if we stop existing, which is the only guarantee that means anything.
One command
A configurator, then make dev: Postgres, Redis, the API, the worker and the console.
AgenticOS
The dashboard
The dashboard
Everything the agents did, on a page each person arranges
35 cards: runs, spend, approvals waiting, service health, answer quality, sync freshness, sandbox capacity. Drag one, resize it, hide it, save the arrangement as a preset. Each card is gated on what that reader may see — so a finance lead and an engineer keep different dashboards on one deployment, and neither can arrange their way into the other’s data.
How this starts

Three steps, and the first one is a single command.

1 — It runs
One command on your own machine. It checks what is missing, asks four questions, and hands back a console with a working agent in it.
curl -fsSL …/quickstart.sh | bash
2 — It answers something real
Pick a question people actually ask each other. Upload the documents that answer it, and put the agent in the channel where they ask — Slack, Mattermost, or a link.
3 — It is governed
A monthly cap on that agent. Approval required on anything that writes. Then read the audit log and compare it with what people told you it was doing.

Stopping costs nothing, which is the point of starting this way: the specs export as YAML into your own repository, and the data was never anywhere but your database.

AgenticOS
AgenticOS

One place to build, run and govern your company’s AI agents.

5,802 MCP servers 27 model providers 8 places it answers
github.com/vstorm-co/agenticos
vstorm-co.github.io/agenticos
Apache-2.0 · read the code
built by