Orchestration runs the steps; an open-source agentic OS grants them

Two jobs share one category name

An orchestration platform coordinates work that is already defined. It decides which agent runs next, what happens when a step fails, and where a person takes over. UiPath describes its own product as the layer that coordinates "AI agents, robots, and people across long-running processes" (UiPath). That is a scheduling job, and a hard one.

An agentic operating system answers a different question. What may each agent reach, with whose credentials, on which sandbox, and what record exists after it acts? The answer needs a home that a person can read and a reviewer can diff. In Kortix that home is the project repo, where the manifest, the agent files, the skills and the connectors travel together.

Where a grant lives

The manifest is a file in the repo. The manifest reference says kortix.yaml declares the agents and what each one may reach. The starter template's manifest shows the shape of an agent entry:

agents:
  kortix:
    file: agents/kortix.md
    connectors: all
    secrets: all
    kortix_permissions: all
    skills: all

A grant nobody wrote grants nothing. 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; a person widens it on purpose. Two keys run the other way: an omitted tools key grants every tool, and an omitted skills key leaves skill access to the agent file's permission rules. Cut the connector list to one app and the agent reaches that app only. Permissions run the same way for the people around the agents: "Per-resource permissions for people and agents. Roles, groups, and an audit trail." The permissions docs map roles and groups onto a project.

Nothing is approved by default either. "Approval gates you set. Off until you set them." The merge step follows the same rule: "Session work reaches main through a change request. Merge is default-deny for agents." An auditor who asks who approved a payment gets one of two artifacts: a step in a process history, or a change request that carries the approver into the repo beside the diff it allowed.

The label gets blurred on purpose

Lyzr sells an agentic OS, and its buyer's guide defines the term this way: "an agentic OS means an enterprise AI agent orchestration platform" (Lyzr). The same guide warns that many vendors relabel an old product and keep the marketing. Both statements are useful. Read them together and the label stops telling you which job a product does, so ask about the artifact instead.

UiPath is the cleaner case. It keeps the word orchestration and describes a governance layer over agents, robots and people, including agents built by other vendors (UiPath). Its policy, audit and human-in-the-loop controls sit at that layer. That is a real answer when a process spans systems from several vendors.

Three questions that settle it

1. Can you draw the process once and keep it? A fixed sequence with exceptions is orchestration work, and a scheduler earns its price.
2. Do agents need different reach from each other, reviewed when it changes? That is a grant file, and the file belongs in git next to the code.
3. When the auditor asks who approved an action, which artifact do you open? A process log, or a change request with a person's name on the merge.

If your problem is a repeatable process, you want orchestration. If it is a workforce of agents that must be granted, approved and audited, you want the operating system. Teams buy the first when they needed the second, and the gap shows up in the first audit of a consequential action.

Where the environment runs decides whose disk holds the record. "Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free." A scheduler can arrange work across systems you do not own. The grant and the audit trail have to sit somewhere you do.