The open-source Agent OS a company runs on

What an agent operating system has to hold

An agent operating system is a coordination layer that sits above a traditional operating system, giving AI agents structured access to memory, tools, and system resources while managing how they execute tasks. That definition comes from Dust. It earns its place by describing a job. Dust names four parts: memory management, scheduling and orchestration, tool management, and security and access control.

Dust draws the distinction that matters: "Modern automation tools add AI steps to a flow you define. An agent OS lets the agent define the flow." Once the agent chooses the order of work, four things have to exist outside it: a store for context between runs, a schedule and a queue, a boundary on what the agent may touch, and a record of what it did.

A product can do one of those well and still be far from the definition. The question for a buyer is which product does all four for a company, and who owns the thing that holds them.

Five products, five different jobs

Buildermethods Agent OS is a standards kit for coding tools. Its own description calls it "a system for injecting your codebase standards and writing better specs for spec-driven development", and it works alongside Claude Code, Cursor, and Antigravity. It writes markdown files into a project so a coding agent follows the team's conventions. It does not run an agent, hold memory between sessions, or decide who may change a permission.

Agno's AgentOS is a runtime. "AgentOS is the FastAPI for agents. It serves agents as an API, an MCP server, and through chat interfaces." It "runs in your infrastructure and writes runtime state to databases you configure." Of the rivals here, it comes closest to the coordination layer. A team that builds agents with the Agno SDK gets sessions, traces, approvals, and role-based access. The definitions and the company's rules stay in the team's application code, and the review path around them is the team's to build.

Contentstack Agent OS is a feature of a content platform. The company calls it "the system of action in the Contentstack AXP, turning your content, customer data and brand rules into the foundation AI agents need to act safely at enterprise scale." Polaris, Agent Builder, and automations sit inside it. For a content operation that is a real layer. It is Contentstack's to run, over Contentstack's data.

Two more names sit further from the definition. PwC also uses the name, on its AI services page. Fiserv sells agentOS as "one governed platform to create and use agents across Fiserv", aimed at banks. Neither is a layer a company outside those engagements installs and keeps.

Kortix is the layer the name describes. Agents, their skills, the company memory, and the connectors live as files in a git repo the company owns. It is open source. Read it, fork it, audit it.

The files are what a company keeps

A Kortix project is a git repo with kortix.yaml at its root. Agents sit in agents/<name>.md, skills in skills/<name>/SKILL.md, and company memory in memory/. Behavior lives in the agent's markdown file. Reach lives in the manifest, and the excerpt on this page shows the whole shape of it: an agent entry, the file it points at, and the connectors it may use.

That split pays off at review time. A person reading the repo can say what an agent is allowed to touch without opening a dashboard or asking a vendor. A diff shows what changed. A script can read the same files, which is why the layer maps cleanly onto the parts of an operating system.

The session loop carries the rest. The docs put it in four lines. "A project is a git repo with kortix.yaml at its root." "A session runs one agent in its own sandbox." "The agent commits, pushes the session branch, and opens a change request against the project's default branch." "A person with the project.gitops.merge permission reviews the change request and merges it into the default branch."

Session work reaches main through a change request. Merge is default-deny for agents. That is the part a runtime or a spec kit leaves to the team. A person reviews the diff, and the record of that approval sits beside the code it changed.

Open source matters here for a narrow reason. A permission model in a vendor's documentation describes what the product is meant to do. The same model in code a security reviewer can open is something the reviewer checks directly, on their own schedule. That is what owning the layer means in practice.

Three questions that sort the products

Ask whose repo holds the agent definitions. If the answer is a vendor dashboard, the vendor holds them. If the answer is a repo the company can clone, the definitions survive a change of vendor.

Ask where the memory lives. A database the company configures is better than a store it cannot see. A directory in the repo it already clones is better still, because memory becomes something a person can read, diff, and correct.

Ask who can merge a change to the configuration, and where that approval is recorded. An agent OS without a governed update path leaves the company unable to say who allowed a change. For the closed suites that come up in the same searches, see the alternatives comparison.

Kortix answers them with the company's repo, memory/ inside it, and a change request. Run it on Kortix Cloud, in your VPC, or on your own on-prem network, and self-host it free when the layer has to sit on your own machines. Any model provider with your own keys.