Open source AI agent orchestration, explained

What AI agent orchestration is

AI agent orchestration is the practice of coordinating several AI agents so they finish one body of work together. An orchestrator decides which agent handles which part of the job, starts each run, tracks what every agent produces, and returns the results as one reviewable outcome. A single agent works one task at a time, so a multi-part job turns into a queue of prompts you feed by hand. Orchestration is closer to staffing a project: research runs while drafting runs, a checker reviews the draft, and the pieces meet at the end as one deliverable.

The word covers two jobs that often get merged. Coordination is the logic: who does what, in which order, and what hands off to whom. The runtime is the machinery: where each agent actually runs, what it may touch, and how its output reaches you. A tool that covers only the first half leaves the second half to you.

How agent orchestration works

Most setups follow the same shape. A configuration defines the agents and what each one may touch. Work starts on demand, human-assisted, or automated on a schedule or an incoming webhook. Each run gets its own environment, so parallel agents cannot overwrite each other's files or scramble shared state. Finished work returns through a defined path, and whether a person approves that result is one of the checks that matter when you pick a tool.

The hard parts are state and safety. Two agents editing the same files at once produce conflicts nobody can audit. Agents with unrestricted reach take actions nobody signed off on. And configuration held inside a vendor's application cannot be versioned, diffed, or moved with you when you switch tools.

What to look for in an orchestration setup

Five checks separate a setup you own from one that owns you:

• Where the configuration lives: files in a git repo you control, or settings inside someone else's application.
• Isolation between runs: one isolated sandbox per session, or everything sharing one environment.
• The review gate: whether finished work can reach your production state without a person approving it.
• Model choice: any model with your own keys, or only the models the vendor meters and bills.
• Hosting: whether the whole system runs on infrastructure you control.

Coordination logic is the part most tools and most explainers cover. Ownership is the part that decides what you have a year from now. When the configuration is a git repo, you can diff a change, roll it back, and see who edited what, and you can move the whole system to a new host by cloning the repo. When the configuration lives inside a vendor's application, none of that is true, and self-hosting the runtime does not fix it: the machinery is open while the configuration still belongs to the vendor.

How Kortix orchestrates agents

Kortix is built around those checks. The configuration is one git repo: agents as markdown files under agents/, skills under skills/, project memory under memory/, and a kortix.yaml file that declares the machine image, the connectors and triggers, and the secret names and grants. Grants are deny-by-default: an agent with no declared connectors, secrets, skills, or permissions gets none of that access. kortix init turns a directory into a Kortix. The repo is public, so you can read, fork, and audit all of it (Kortix on GitHub).

Work runs in sessions. A session runs an agent in an isolated sandbox, on its own branch, with the repo already cloned in. That is what lets thousands of agents run in parallel on one config, each on its own cloud computer. 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.

When an agent finishes, it commits on its branch and opens a change request toward main. Session work reaches main through a change request, and merge is default-deny for agents: a person reviews the diff and decides what lands. An agent can edit its own configuration on its session branch and propose the change. A person approves that too. New or changed agents and skills reach future sessions the same way, only after a change request merges them into the default branch.

The manifest reference's example shows the pattern: two agents, one file, two different reaches.

default_agent: kortix agents:  kortix:    file: agents/kortix.md    connectors: all    secrets: all   release-bot:    file: agents/release-bot.md    connectors: [github]    kortix_permissions: [project.gitops.push]    secrets: [GITHUB_AGENT_TOKEN]

For every field and rule, read the docs.

That review gate is what makes parallel orchestration safe to leave running: every change arrives as a diff a person reads before it lands. Where the system runs is your call: Kortix Cloud, your VPC, or your own on-prem network, and self-host is free. To install it yourself, the self-hosting guide on this site walks through the commands, and the comparison chart lines Kortix up against other open source options. For the wider category, Kortix keeps a running guide on its blog.