A company OS for AI agents is the layer that tells agents what exists in your business, which rules apply and what they may do. You can build it without migrating anything: pipelines map your existing tools into a graph, an ontology on top defines the objects, rules and allowed actions, and agents read and act only through that ontology.

What people mean by a company OS

The term spread on X in October 2026. Yohei Nakajima wrote that teams of agents and people will work through a CompanyOS. Instead of a company brain that holds everything, it stores rules, processes, decisions made and which tools to use and how. It can mirror some data, but the source of truth is often best kept in the tools the company already uses, such as the CRM. He calls it a flipped playbook: you keep updating it as you decide and learn, instead of writing every rule up front.

Untapped's write up, The CompanyOS Thesis, puts the contrast in one line: “A company brain copies records. A CompanyOS holds the rules for working with them.” In their version, coding agents extract candidate decisions, facts and processes from internal notes, a person reviews them and locks in what becomes shared, and the rules live in Git, so every change is a reviewable diff with an author and a date. Untapped also lists what is still open, including which actions can skip human approval.

Where we agree: no copied brain, no migration

Untapped moved away from a company brain because it became “a second copy of the CRM, the inbox, and the document system, and that copy drifts out of date and needs constant syncing.” We see the same thing. A pile of copied documents goes stale, and nobody can say which version an answer came from.

We also agree that the tools stay the source of truth. A manufacturer's ERP, CRM and planning sheets keep doing their job. You should not need a migration or a cleanup project before AI is useful.

Where rules alone fall short

A rule is always about something. Take a rule that quotes above a set value need the sales director's approval. It applies to a quote, for a customer, on a product line. A rule that one customer's rush orders go ahead without prepayment applies to that customer and that kind of order. To use either rule, an agent first has to work out which customer this is, which quote the order refers to and which terms were agreed.

If a company OS holds only rules, the agent still goes to the CRM, the ERP and the inbox to find those things, on every run. Each agent pieces the company together slightly differently, so two people asking the same question can get two answers. TextQL's Decision-Bench shows how hard that piecing together is. In their benchmark one $176.31 order touches 71 tables across 12 ERP modules, and of the dashboard data sources that passed the format checks, 72.8% failed the numerical checks. The numbers looked right and were wrong.

Our order: no raw tool access, then an ontology, then a graph

Almost every AI problem is a context problem, so the first decision is what an agent sees and touches. Our order has three steps.

No raw tool access. Agents do not get direct access to the CRM, the ERP or the inbox, for reading or for writing.
An ontology. A written definition of the kinds of things in the business, how they relate and what can be done with each: a Customer, a Quote, an Order, a Production step. See what is an ontology for AI agents.
A graph underneath. The particular customers, quotes and orders, with their relationships, kept current from the tools. See what is a context graph for AI agents.

Together, the ontology and the graph are what we call a world model for knowledge work. Agents read and act only through it.

How the tools feed the graph without migrating anything

Data pipelines read from the tools and map what they find into the graph. They match the same thing across systems once: the customer in the CRM and the customer in the ERP become one Customer, with both records linked to it. There is still a copy, but it is produced by pipelines you can inspect and rerun, not kept up by hand. Anyone can see where a fact came from and when it was last refreshed.

Older systems are not a blocker. When an ERP has no API, the pipelines work from data exports or from read access to the database underneath. The note on AI for order intake and quoting on a legacy ERP walks through that case.

Rules attach to the entities they are about

In a company OS built this way, a rule lives on the thing it applies to. A payment term sits on the Customer it was agreed with. An approval threshold sits on the kind of Quote it governs. A note about a supplier's lead time sits on that Supplier, and every Order that depends on the supplier can see it.

Each rule keeps an owner, a source and the date it last changed. When a rule changes, you can see every agent and every piece of work that depends on it, because they all point to the same entity instead of holding their own copy of the rule in a prompt. This is where we build on the CompanyOS idea: the rules are the same rules, they just have something to attach to.

How agents act: allowed actions, not raw writes

No raw tool access covers writes too. The ontology defines the actions an agent may take on each kind of thing: draft a quote for a Customer, create an Order from an approved Quote, flag a Production step as late. An agent can only take those actions. Where we have write access to a tool, the action writes back to it through the pipelines. Where there is only read access, such as read access to an ERP database, the action produces a draft that a person enters. Either way, the ERP or the CRM stays the system of record.

Each action carries its own checks and approvals. Anything that cannot be undone, that leaves the company or that decides something about a person waits for a person, as set out in approvals and control for AI agents. Palantir's Foundry works the same way: changes to objects are made by applying actions, each a single transaction, and an action type can check who is allowed to take it.

What the outside evidence says

Structured context gives better answers. In data.world's benchmark by Sequeda and colleagues, GPT-4 answered enterprise insurance questions correctly 16.7% of the time over the SQL schema and 54.2% of the time over a knowledge graph representation.
The gap holds with newer models. dbt's 2026 rerun on the same dataset scored 98.2% and 100% through a semantic layer for two current models, against 90.0% and 84.1% when the models wrote SQL directly. dbt notes that the SQL runs were given the entire schema, which is not practical for larger datasets.
Vendors are building ontologies for agents. Microsoft's Fabric IQ ontology is meant to ground agents in governed definitions, relationships and rules, and binds to source data without requiring the ontology to become a separate data store.
Broad raw access is what attacks exploit. In a GitHub MCP demonstration by Invariant Labs, a malicious public issue hijacked an agent and led it to leak data from private repositories into a public pull request. In a Supabase demonstration by General Analysis, instructions planted in a customer support ticket led a coding assistant with full database rights to read sensitive test data and copy it into a reply the customer could see.

Company OS vs company brain vs context layer

	Company brain	Company OS (rules layer)	Company context layer
What it holds	Copies of documents, notes and records	Rules, processes, decisions and pointers to the tools	Approved sources, definitions, relationships, versions and permissions
What agents touch	The copy, through search	The rules, then the tools directly	The layer, through connectors from ChatGPT, Copilot, Claude and your agents
How it stays current	Syncing the copy, which drifts	People lock in rules proposed from work, versioned in Git	Owners per source, inspectable pipelines and scheduled answer checks
What it leaves open	Which copy is official, and how current it is	What each rule applies to, and how agents act safely	Which actions agents may take

What we describe here combines them: the approved definitions of a context layer and the rules of a company OS, both attached to entities in a graph, with allowed actions on top. The note on the company context layer covers the read side in more detail.

Where to start

Start with one piece of work where wrong answers are costly, such as quoting at a manufacturer that makes to order. List the kinds of things that work depends on: Customer, Quote, Product, Order, Production step. Connect only the sources they come from. Write down the rules people already apply and attach each one to its entity, with an owner. Define the few actions the agent may take and where a person approves. Then run it next to the people who do the work today and compare the results.

The next piece of work extends the same graph instead of starting again. The steps are in how to build a world model for your company.

How Ortelian does this

Ortelian is a platform plus a forward deployed team. We build the knowledge graph and the inspectable data pipelines for a company's operations, whether that is orders, quoting and production at a manufacturer or work in finance and operations. Our team works with yours to map the work, define the ontology and set the actions and approvals before anything goes live. Your tools stay where they are. The platform is hosted in the EU, and you own your data and the IP built for it.