What is an agentic operating system? An open-source definition

The layer that gives agents what an operating system gives programs

An agentic operating system is the layer that runs AI agents the way an operating system runs programs. It gives each agent an identity, a workspace, tools it may reach, and a record of what it did. It also decides what that agent may touch before work starts.

An operating system earns the name by holding what programs depend on: a scheduler, memory, files, device access, and a boundary between one process and the next. Programs do not manage those themselves. Agents need the same services, with one difference that shapes every other decision. A program receives its instructions when it is built. An agent receives a task in plain language and picks its own steps, so the layer around it has to grant access from a standing rule instead of a fixed script.

Five jobs an operating system does for an agent

The agentic operating system schedules work. An agent runs from a trigger, a cron line or a queue rather than from a person pasting a prompt into a window. It keeps memory, so an agent carries context between sessions instead of relearning the company each morning. It connects tools through connectors, each one named in the agent's grant. It isolates execution. One isolated sandbox per session. Each session has its own isolated machine and branch. It keeps a record of which agent ran, what it touched and what came back.

Each job looks easy in a demo with one person. They get hard when a second person joins and asks who allowed the agent to do that. A scheduler with no identity model cannot answer. Neither can a memory store with no boundary around it. The five jobs describe one design problem, and the operating system either holds all of it or leaves the rest to scripts.

The six components a vendor will show you

Vendor demos follow a similar script, and six boxes appear. An agent runtime holds the loop. A model gateway routes each call to a provider. A memory store keeps context. A connector layer reaches the apps the agent works in. A scheduler runs triggers and long jobs. A permission model decides what each agent may reach, and an audit record shows what it did.

A demo needs the first four working. A company needs the last two to survive a security review. Write-ups usually list the loop, the memory and the connectors, then stop. That describes an environment one person can use. An operating layer gets shared, and sharing is a permissions problem before it is anything else.

The permission model and the approval path decide

Two things carry the weight. The first is the per-agent grant, a written answer to what this agent may reach: which connectors, which secrets, which repository actions. The second is the path a consequential action takes, meaning who approves it and where the record lands.

Kortix is open source, so its grant model ships as a file a reviewer can read. A project manifest names each agent and its instruction file, then lists the connectors, secrets, Apps and permissions that agent may use. Grants are deny-by-default: an agent with no connectors, secrets, apps or kortix_permissions key gets none of them, so it reaches no connector, reads no secret, opens no App and carries no permission. Two keys differ. An omitted tools key grants every tool, and an omitted skills key leaves skill access to the agent file's permission rules. A specialist therefore gains reach a line at a time, which is the opposite of the usual demo where every agent inherits the authority of whoever deployed it.

The permission model reads in plain sentences. Per-resource permissions for people and agents. Roles, groups, and an audit trail. Approval gates you set. Off until you set them. Session work reaches main through a change request. Merge is default-deny for agents. Those sentences cover the four questions an auditor asks: what an agent may touch, who may widen that, who approves a consequential action, and where the record lives.

Gates that start off are a fact to plan for. A team that writes no policy has an operating system that asks nothing before an agent acts. The default is a starting position, and the first week of a deployment is when the policy gets written and tested against real work.

Where an orchestration layer stops

An orchestration layer decides which agent or step runs next. It routes a task, passes state between nodes, retries a failure and ends a run. Frameworks such as LangGraph do that well, and a team with a repeatable pipeline should start there.

The operating layer sits underneath that decision. It answers what the agent may reach when it runs, which machine it runs on, and where the record of the run goes. An orchestration layer can call a tool; the operating system decides whether the call was allowed. Both get sold as agent infrastructure, and they answer different questions. The comparison with orchestration platforms takes the split apart row by row.

Workflow builders start from a process

A workflow builder starts from a process a person already understands: a form, an approval, a handoff. The builder draws that process as steps, and a model fills in one or two of them. Determinism is the point, and it fits work that repeats the same way every week.

An agentic OS starts from the agent. The steps are not known in advance, so control moves to the grant and the approval, which hold whatever the agent decides to do. A workflow with an agent step can run inside an agentic OS. A workflow builder cannot become one by adding agents, because the process graph is the unit of design in the builder and the agent is the unit of design here.

Desktop assistants run on one person's machine

A desktop assistant sees one person's screen and files and acts with that person's account. It suits that person and resists being handed to a team. There is no per-agent identity to grant, no shared record across people, and no boundary between one colleague's session and another's.

The model breaks the moment two people want the same agent. Whose account does it act as, whose files may it read, and where does the log live? An agentic OS answers with an identity per agent and a record that outlives a laptop. If the work stays with one operator on one machine, a local setup is cheaper and fine.

Two questions to ask before you trust a permission model

Ask a vendor to show where one agent's grant is written and what an omitted grant resolves to. An answer that points at a console screen is workable. An answer that points at a file in your own repository is stronger, because the grant then moves through the same review as code. The second question is who can widen that grant, and what has to happen before a consequential action runs.

The two answers together show whether the permission model is a product feature or a diagram. A model that names no default and no approver leaves the decision to whoever deploys the agent, and the security review will find that out later than the vendor would like.

An auditor asks four things: what may this agent touch, who may widen that, who approved a consequential action, and where the record is. A deck answers none of them. A grant file, a default, an approver and a log answer all four, and each one can be tested on a trial project in an afternoon.

The gap shows up at the security review. Teams arrive holding a diagram and no artifact. The permissions and approvals page walks through the four questions with the same manifest, and the home page comparison shows what to weigh.

Kortix keeps the manifest and the agent files in the repo the team already reviews, so the permission model is something a reviewer reads instead of something a salesperson describes.