A CompanyOS is the layer above your tools that gives AI agents one model of the business and one way to act on it. It is not a manual that agents read. It is the structure they act through: an ontology surfaced from the tools you already use, rules attached to each action, and every change kept as code.

The term spread on X in October 2026, after Yohei Nakajima wrote about building a “FirmOS” at Untapped Capital. Most versions since then describe a better place to write down how the company works, so that an agent can read it. This note sets out our view and compares it with five of those takes. The practical steps are in how to build a company OS for AI agents without migrating your tools.

The layer above your tools

Every company already runs on a stack of tools: a CRM, an ERP or accounting package, a finance tool, shared drives and inboxes. Each one holds part of how the company works, and none of them holds the whole picture. People fill the gaps from memory. They know that one customer's quotes need the sales director, or that an order above a certain value waits for finance.

An agent does not have that memory. Give it raw access to the tools and it has to guess. A CompanyOS is the layer above the tools that makes them coherent for agents. It holds one model of customers, orders, contracts, approvals and who owns what, and every action an agent takes goes through it.

It sits above the tools, not in place of them, so the CRM and the ERP stay the systems of record. Agents do not get raw access to those tools. They work through an ontology, and the ontology sits on a graph. The note on context graph vs knowledge graph vs ontology explains how those pieces fit together.

The ontology is already in your tools

The usual instinct is to run a workshop and design the company's ontology from scratch. That is slow, and it tends to describe how people think the company works rather than how it actually works.

The ontology is already there in your existing tools. The objects, the links between them, the fields people actually fill in and the order in which work really moves are all in the data. The job is to uncover that structure and bring it to the surface, not to invent it. People then confirm and correct what was surfaced instead of writing it from a blank page. The steps are in how to build an ontology for AI agents.

Once the ontology is surfaced, agents get access to it and not to the tools underneath. That is a much narrower surface than raw tool access, and it is far easier to check.

Rules live on the actions

Many agent setups keep their rules in prompts: a line in a system prompt, a note in a skill file, a warning in a README. Rules spread out like that drift apart and contradict each other, and nobody can see all of them in one place.

We put each rule on the action it governs. Take invoices. An agent does not simply send an invoice. Sending an invoice is an action in the ontology, and that action has a rule that a person approves it. The agent prepares the invoice, a person clicks approve, and only then does it go out. The rule belongs to the action, not to whichever agent happens to call it. The note on approvals and control for AI agents covers how to design those approvals.

That gives you one place per action to see what an agent may do on its own, what it may only propose and who signs off. Changing a rule means changing it once, on the action, instead of hunting through prompts. Evals run on these actions all the time, so when the business changes, for example when people stop approving a certain action, you see a failing check instead of silent drift. Those evals start from what good looks like on real examples, as described in agree the standard before you build.

A CompanyOS as code

If a CompanyOS is the structure agents act through, it should be treated like code. Ortelian's platform is a CompanyOS as code. It works like GitHub for how the company runs: every change to the ontology, a rule or a pipeline is a diff with history and blame. You can see who changed the approval rule on invoices, when they changed it and why, and you can roll the change back.

You get that once the CompanyOS lives as code rather than in a wiki. We argued in why coding agents work and company agents don't that coding agents work because a repository is already a world an agent can stand in. A CompanyOS as code gives company agents the same kind of footing.

Each domain owns its part

Asking who edits the CompanyOS assumes there is one editor. There isn't. Finance owns the finance actions and their rules, sales owns the sales actions, and operations owns how orders move through production. The CompanyOS is the shared base they all build on, with ownership split by domain, the same way code ownership works in a large repository.

Each domain changes its own actions and rules and reviews any change that touches them. Shared objects, such as a customer or an order, are agreed across domains. Agents see the same structure whichever domain they work in.

How this compares to five takes on X

The discussion on X produced several views that are close to ours. Here is what five people said, in their own words, and where we agree or differ.

Yohei Nakajima. In his post, Yohei wrote that “instead of a ‘company brain’ that holds everything, the OS is for storing rules, processes, decisions made, which tools to use and how.” He added that “the source of truth is often best held in your existing tools (CRM, etc.)” and called the approach a “flipped playbook”, where “you're constantly updating the playbook as you decide or learn new things day-to-day running the business.” We agree that the source of truth should stay in the tools you already use, and that you should not need a migration first. Where we differ is the starting point. A flipped playbook grows from rules written down as work happens. We start from the structure that is already in the tools: we surface the ontology, attach the rules to actions on it, and keep both honest with evals that run all the time.

Untapped Capital. Untapped's write up, The CompanyOS Thesis, describes how they do it today. “Coding agents extract candidate decisions, facts, organizations, and processes from our internal notes.” Then “A person reviews the candidates and locks in what becomes shared context.” And “Our rules live in Git, so every change is a reviewable diff with an author and a date.” That is close to what we mean by a CompanyOS as code. We would put those diffs on the ontology and its actions, so that a changed rule changes what an agent can do, not only what it reads.

Matan-Paul Shetrit. In his reply to Yohei, Matan-Paul wrote: “A company doesn't run on its docs, it runs on handoffs, approvals and escalations, and that's the operating system agents have to plug into.” He also named the open problem: “The hard part is who gets to edit it”. Our answer is ownership by domain, with approvals set on each action.

Josh Rosen. Josh replied that the OS “might be best expressed by a graph of checkpoints that steer agent work centrally across all of your agents.” He went on: “That data model is essentially accumulated institutional knowledge for how work gets done and not the final output of the work.” That is close to our view. The point we would stress is that the data model is uncovered from your tools, not designed from scratch.

Harrison Chase. Harrison sketched the path as a sequence: “Coding agents (Claude code, codex)”, then “personal agents (instinct, muse)”, then “companyOS (???)”. We think the step to a CompanyOS needs the ontology and the action boundaries, not only better agents.

What makes our view different

Most CompanyOS takes are about giving agents a better playbook to read. Ours is about giving them a better structure to act through. The ontology is surfaced from the tools you already use rather than written from scratch. Rules sit on each action, and a person approves the actions that need it. Evals run all the time, so changes in the business show up as failing checks. Everything is kept as code, with diffs, history and blame, and ownership is split by domain on one shared base.

How Ortelian does this

Ortelian is a platform plus a forward deployed team. The platform is the CompanyOS as code described above, and it is running with clients today. Our team works with yours to surface the ontology from your tools, set the actions and approvals, and agree the evals before agents go live. Access is set up with our team as part of an engagement. The work covers sales, finance and operations, not one function. The platform is hosted in the EU, and you own your data, your world model and the IP built on it.

When an AI tool only needs to read, the same base serves it as described in the company context layer.

Sources

Yohei Nakajima (@yoheinakajima), post on X, October 2026.
Untapped Capital (@UntappedVC), The CompanyOS Thesis: Building a Shared Operating Layer for Humans and Agents, article on X, October 2026.
Matan-Paul Shetrit (@MatanPaul), post on X, October 2026.
Josh Rosen (@JoshARosen), post on X, October 2026.
Harrison Chase (@hwchase17), post on X, October 2026.