What an AI operating system owns when it is open source

The difference is what owns the running state

An AI operating system is the layer that runs a company's agents. It owns the processes those agents run as, the file system they read and write, the schedule they fire on, and the permissions they act under. It also owns the path an update takes to reach the running system. An AI agent framework is a different kind of thing: a library you write agent code against. It ships patterns for tool calls, memory and retries. The machine those agents run on, the storage their work lands in, the clock that starts them and the review that lets a change through sit outside the framework's job.

That leftover is the running state, and it is the whole difference between the two names. A framework helps you write agents. An operating system owns what happens after the code is written: which processes exist, where their files live, what runs at 3 a.m., who may act, and how a change reaches the system without pausing it. Ask a product what owns its running state, and you know which of its two names it has earned.

What a framework gives you, and what it leaves to you

For one developer's weekend script, owning that state yourself is normal engineering. You write the loop, you store the transcripts, you wire the cron job, you deploy by hand. A company cannot stop there. The state a company accumulates is operational memory: who did what, which agent may touch which system, what the schedule looks like this week. It does not fit in one engineer's head, or in one team's private scripts.

So the name sets a test. A real operating system runs processes as isolated units, gives them a file system, schedules them, and updates them under review. A product that stops at the library boundary has not met the test, and the gap is exactly the part a company ends up maintaining itself.

The mapping, part by part

Kortix's docs carry a table headed "The parts", captioned "Each part of an operating system maps to a Kortix feature" (Read the docs). Eight rows pair a part of an operating system with the feature that plays it. Two of them carry the argument for a company.

Processes map to sessions. The docs state the isolation as a product fact: One isolated sandbox per session. Each session has its own isolated machine and branch. A session is one agent run. Its sandbox clones the repo and works on a new branch whose name is the session_id, a UUID with no prefix, so two parallel sessions work on two different branches of the same repo.

The front-door agent's prompt is part of the same repo (agents/kortix.md in the open repo). It opens by naming the project the agent works for, then tells the agent that its session is an ephemeral branch of the repo where only a commit and a push survive. A program, in this mapping, is a file a company can read and review like any other code.

Updates are the row companies feel first. In an operating system, an update is a controlled change to the running system. Kortix maps it to change requests, and the docs make the rule explicit: Session work reaches main through a change request. Merge is default-deny for agents. The docs walk the loop in four steps. A project is a git repo. A session runs one agent on its own branch. The agent opens a change request. A person with the project.gitops.merge grant reviews it and merges it into the default branch.

The remaining rows hold up the same way, without needing a metaphor. The scheduler row is worth one extra sentence, because it is where unattended work comes from: a trigger starts a session with no person present. A cron schedule fires it on the clock; a signed webhook fires it on an event. The shell row is the one that makes the word operating fit: the same system answers from a terminal, a browser and a chat window. For the same mapping written for a management audience, read the explainer on the Kortix blog.

Company as code

Company as code is the practice of keeping a company's working configuration and its accumulated state in a git repo. The configuration covers the agents, the skills that encode how the business does a job, the connectors and their grants, and the triggers. The state covers the memory the system accumulates and the record of what was done. Both are files, so both version and travel the way code does.

The manifest at the root of a Kortix project says the same thing about itself. Its header reads: "Source of truth for project-wide config that lives in git alongside the code" (the starter manifest). That sentence is the ownership clause of the operating-system idea. A framework leaves the running state wherever the team bolted it. An operating system built this way keeps the state in a repo the company owns.

This is also where the two names stop being academic. A company that keeps its running state in a vendor's private store has rented its own operational memory. A company that keeps it in a repo it owns, on agents whose code is open source, keeps the option to move it and the ability to audit it. For a company deciding where its running state lives, that is the standard worth holding.

What to check before you choose one

The mapping doubles as a buying checklist. Point it at any product that claims the category, and write down the answers before a demo ends.

• What is one process? An isolated unit, on its own machine and branch.
• Where does the file system live? In a repo the company owns.
• What runs when nobody is present? A scheduler the system itself operates, on a clock or a webhook.
• Who may act? Roles and grants for people and for agents, written where they can be reviewed.
• How does an update land? Through a reviewed change request against a default branch.

Kortix answers the five with the mapping its docs publish. Because the product is open source, the answers can be checked rather than taken on trust: the table, the agent file and the manifest are public files. A company about to hand its running state to something new deserves that much inspection first.