An open-source agentic OS a company can govern

What an agentic OS holds

The name describes an operating system for agents, and the original shows what such a layer has to hold. A conventional operating system gives a program an identity, a filesystem, memory, a scheduler and the right to touch a device. An agentic OS gives an agent the same five, with a person on the other end of the decisions that cannot be undone.

The five are concrete: the agent definitions, the skills they load, the memory they work from, the connectors that reach other systems, and the permissions that bound each one. A setup that misses the last one is a folder of prompts with a scheduler attached.

Kortix is the open-source AI Operating System: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. That object list is what separates the layer from a desktop assistant. An assistant is a window onto a model. This layer owns the definitions, the access and the memory, so adding a second person is a configuration change.

A list of components is the easy half. What an agentic operating system is covers the full set and the boundary against an orchestration tool. The harder half starts when the operator stops being one person.

The personal setup works because it has one operator

Most setups that carry the name today belong to one person: a folder of notes for memory, a config file, a coding agent, and a shell on the same laptop. Everything sits in one home directory, next to the person who owns it. The whole thing takes an afternoon.

Nothing there is broken. With one operator there is one trust boundary, so an agent that reaches whatever the person can reach has nothing to separate. Memory is a folder that person reads and edits. The record of a session is the scrollback they watched. The setup is small, and it is honest about being small.

Scale it to a team and each of those properties turns into a debt, because every one of them depended on a single person being present.

Four things break when a second person joins

Memory collides first. A notes folder has one author and no merge path. Two people writing to the same memory need an owner per file, a diff, and a way to disagree without overwriting each other, which is a different problem from writing good notes.

Access breaks second. An agent on a laptop inherits the credentials in the keychain beside it, so its reach equals the owner's reach. That trade is reasonable for one person and impossible to defend for a team, because the second hire cannot be given a narrower grant than the first. Per-resource permissions for people and agents. Roles, groups, and an audit trail. That vocabulary is where a company version starts.

The record breaks third. A scrollback answers "what did the agent do" for whoever was sitting there, and stops answering when they close the terminal. A team needs an answer that names the agent, the resource and the session, and can be read by someone who was not in the room. It also needs an approval step on the actions that cannot be undone, held by a person with the authority to say no.

Parallel work breaks fourth. One laptop holds one checkout of the repo, so two agents editing the same files overwrite each other, and neither can be trusted to report what it changed. One isolated sandbox per session. Each session has its own isolated machine and branch. Two sessions then cannot collide, and neither inherits the other's half-finished state.

How a company version is laid out

The four problems share one shape of answer, and it is the shape of a repository. A single project repo holds the agent definitions, the skills, the memory and the connector names. A manifest at the root, kortix.yaml, holds the governance: which agent may call which connector, which secret it may read, which permissions it carries. Each agent is a markdown file holding behavior, model and prompt, and the manifest points at that file.

In the starter project the two halves look like this: a grant block for the default agent, and the stock agent file that block names. Both are short enough to review in a meeting. A reviewer checks four deny-by-default grants: connectors, secrets, apps and kortix_permissions. Leave one out and the agent reaches no connector, reads no secret, opens no App and carries no permission, so a specialist widens by exception. Two keys run the other way: an omitted tools key still grants every tool, and an omitted skills key leaves skill access to the agent file's permission rules.

Consequential work then takes one path. Session work reaches main through a change request. Merge is default-deny for agents. Review happens on a diff instead of a chat transcript, and the diff is the record. None of that is exotic: it is the review path a company already uses for code, pointed at the work of agents, which is why a platform lead can defend it in one meeting with security. The grant model is the part to check first, and permissions and approvals walks through the four questions a reviewer asks of it.

Where the state lives, and who can read it

The repo decides how the rest ages. Memory in git can be reviewed like any other change. Grants sit next to the agents they bound. A fork carries the whole company brain, which makes leaving a vendor a clone rather than a negotiation.

Running the instance is a separate decision, with its own install steps in self-hosted agentic operating system. The repository is the part that stays the same either way, and it is the part a security reviewer asks about.

Code a company can inspect settles whether the permission model does what the vendor says it does. Open source. Read it, fork it, audit it.

All four of those failures trace back to where the state lives and who may widen access, so the repo and the manifest carry more weight than the model inside the agent.