An open-source CompanyOS holds the layer an agent platform omits

Three layers sold as one word

Most teams reach this question holding a subscription that already runs agents. The demo worked. The pilot did not, and the person who owns it says the agents need more context. That is usually true, and it also describes a purchase nobody made.

Three layers get sold as a single idea. An agent runtime starts a job, gives it a machine and a model, and returns whatever the job produced. A knowledge layer keeps what the company knows where a model can read it: the pricing policy, the refund rule, the letter the sales team actually sends. An operating layer holds both, plus the question the other two never ask, which is what may change in the company's own records and who signs that off. Kortix is the third of those, built so that the first two arrive as parts of it rather than as two more invoices.

What each layer answers

Three questions separate them, and the answers rarely overlap.

Who runs the work. The runtime answers this one. It schedules, provisions, retries, and ends with text or a file. Most buying processes finish here, because the layer trials well: add a key, run a prompt, watch output land. The harder questions start when somebody asks where the prompt came from.

What the work may read. A knowledge layer answers this. At companyos.cc, a team's AI gets the same facts, procedures and templates inside the Claude, ChatGPT or Codex account each person already uses. Files and connected tools stay read-only to the AI. Where four people give four answers about onboarding, that is a real fix, and a cheap one.

What happens before a change goes live. Neither of the first two answers it well. An agent that edits a contract, issues a refund or moves a price needs a rule about what it may touch. It also needs a moment when a person sees the change first. A runtime can log the call. A shared drive can hold the policy. Nothing in either one puts the two in the same place.

Why files decide the boundary

An agent with no company memory gets briefed on every run. Someone pastes the policy into the prompt, the session ends, and the next one starts with nothing. The work is real, and the cost sits with the person who assembles the brief each Monday.

A knowledge layer with no runtime produces advice. The team reads the right procedure and then performs it by hand, which beats four different procedures and is still not what the buyer described in the kickoff.

The operating layer is where the two meet, and the meeting point is a file. An agent's prompt, the App it may read and the permission it holds sit in one place. A change to any of them arrives as a diff somebody reviews. That is what makes the third layer a purchase instead of an integration project.

Where an agent's instructions and permissions live

One agent registers with a name, a prompt and two settings, as the developer docs print it. A reviewer reads all of it without opening a settings screen.

agents:  report-writer:    prompt: Write the weekly report from the reports App.    kortix_permissions: [project.app.read]    apps: [reports]    # App slugs, all, or none (the default)

prompt is the job in a sentence the agent reads when it starts. The instruction travels with the agent, instead of in a briefing someone pastes each week. kortix_permissions names the one operation it may perform, and here that operation reads. apps names the App it may reach, and the default is none, so an agent that names no App reaches no App.

Those lines narrow what one agent may do. The project's rules decide what may land, and they are set per resource, for people and for agents. Roles and groups name who may do what. A record keeps every action. An agent's work lands on main through a change request; merge stays closed to agents unless an admin grants it.

Put the permission line beside the merge rule and the difference between the layers shows. A runtime can produce the diff. An operating layer decides whether the diff may land, and can show who let it.

Which order to buy in

The purchase order follows from the layer that is actually missing, and the answer changes with the situation.

• The output keeps missing the company's rules. Scheduling works; what the agent reads and what it may touch are missing. Buy the operating layer, and put the rules where the agent reads them.
• No agents run yet, and none are planned this year. Buy the knowledge layer. Shared facts help immediately, a runtime nobody switches on does not, and the cheaper fix is the honest one.
• A security review stands between you and the pilot. Buy in the order the reviewer reads: isolation, permissions, a log a reviewer can read, then the agents that depend on them.
• You expect to change model vendors next year. Buy the repo first. Memory that lives in someone's tenant moves when the tenant decides, on the schedule the tenant sets.

Three of those four end in the same place, a system that holds the agents, what they read and the review together. That is the layer to look for, and what a CompanyOS is defines it at more length.

Kortix is that system. It ships the three parts from one repository: the agents and their skills, the memory the company keeps, and the connector settings, running on cloud computers the platform provisions. A company that means to let agents change records should buy this layer first. A runtime added later plugs into rules that already exist, instead of starting a second migration. Read the docs covers the install order. The comparison puts the other products trading under the name side by side.