An AI agent orchestration platform is the layer that decides which agents run, what each one may touch, and what the whole thing spends. A guide to the two families of platform, the seven capabilities worth checking before you adopt one, and the cases where a terminal multiplexer is still the better answer.
the short version
An AI agent orchestration platform is the layer that decides which agents run, what each one may touch, how work moves between them, and what the whole thing costs. It is software you adopt rather than a practice you follow: the practice is orchestration, and the platform is the thing that holds the decisions for you so they stop living in your head and in four terminal tabs.
That distinction matters because the two words get used for each other constantly. Orchestration is something you already do the moment a second agent starts work on the same repository, with or without a tool. We wrote the practice up separately in what AI agent orchestration means, including the four topologies people run, and this post assumes you have read it or already know them. What follows is about the product category: what a piece of software has to do before the label is earned, what to ask a vendor, and the fairly common case where the correct purchase is nothing.
Seven capabilities separate a platform from a launcher with a nice window. Here they are in one line each, and the rest of the post is the long version.
Number seven is the one almost nobody asks about during evaluation and the one that costs the most when it goes wrong.
two families of platform, one phrase for both
If you search this term and come away confused, the confusion is real and it is not yours. Two different kinds of software are sold under the same words, and buying advice written about one is actively wrong about the other.
Family one: in-process frameworks
The first family orchestrates model calls inside a single program you wrote. You import a library, define some agents as objects or functions, wire them into a graph or a crew or a conversation, and run it. The agents are not processes; they are calls in a loop. This is the LangChain, CrewAI and AutoGen shape, and it is the right answer when the multi-agent behaviour is a feature of your product: a support triage flow, a document pipeline, a research assistant that calls three specialists before answering. The questions you evaluate it on are software-library questions, and we went through them in LangChain vs CrewAI vs AutoGen.
Family two: workspace platforms
The second family orchestrates long-lived agent processes against a real repository. Each agent is an actual program with an actual shell, reading and writing actual files on a disk you own, running for minutes at a time without supervision. Nobody wrote a graph. You are the graph, and the platform exists because being the graph by hand stops working somewhere around the third agent.
Here the questions are operational rather than architectural. Where does each agent write. What can it run. How do I know it is stuck. What did that cost. A table putting both families in one grid tells you nothing useful about either, and this post is about family two.
seven capabilities to check before you adopt one
Each can be verified in an afternoon of trialling, or asked about directly. Where a useful vendor question exists, it is written out.
1. Isolation: its own directory, its own branch
Two agents in one working directory are two processes writing the same files with no lock between them. Agent A reads a file, thinks, and writes back a version that quietly discards agent B's edit, and git will not warn you, because as far as git is concerned only one write happened. The usual fix is a worktree and a branch per agent. Containers are stronger: Sculptor runs parallel Claude Code agents in Docker containers, each with a full copy of the repository, which protects against destructive commands and not only collisions. Ask whether the isolation is created automatically before the agent starts. Worktrees offered as a checkbox are worktrees you will forget to tick.
2. An authority model: which agent may instruct which
Once agents can hand work to each other, any-to-any is the wrong default. A confused supervisor can dispatch a worker to rewrite something nobody asked about, and an agent that has read a prompt injection somewhere in your dependencies can do it on purpose. What you want is an explicit set of edges you can look at and delete. Ask to see the permission graph and to revoke one edge. If that means editing a config file and restarting, it is not a revocation, it is a redeployment. If they share a shell and anything can call anything, there is no authority model at all.
3. Spend visibility, per agent, while it runs
One agent in a terminal gives you no running total, and four give you four times no running total. Parallelism multiplies burn rate, the one variable a person watching several terminals cannot estimate by feel, and a number that arrives tomorrow on an invoice is accounting rather than control. This is hard rather than tedious, which is why many products skip it. Long coding sessions are dominated by cache reads rather than fresh input, so a meter that sums raw token counts against a single rate is wrong by a large multiple, and we went through that arithmetic in what Claude Code actually costs. In the comparison table we keep, checked 2 August 2026, most of the workspace tools we track are marked "not documented" on metering, and one, Crystal, we could not verify at all. Not documented is a different claim from absent. Ask whether the total is per agent, whether it appears without you asking, and what happens at a threshold. On that last part prefer a meter that warns over one that gates, since killing an agent mid-edit leaves a half-written file.
4. Blocked-agent surfacing
An agent that has finished, one that is mid-thought, and one that has sat on a permission prompt for eleven minutes look identical in a pane you are not looking at. Your attention is the resource that does not parallelise, so anything that makes you poll is spending the scarcest thing you have. Ask how, without clicking into a session, you learn which one needs you. A good answer is a badge, a sound, a colour on a node. A bad answer is a list of last-activity timestamps that asks you to infer.
5. Session durability
An agent that dies when you close the laptop, drop the network or restart the app is an agent you supervise rather than delegate to, and supervision cost is what orchestration exists to reduce. Test the three failure points separately: the machine sleeping, the connection dropping, and the tool itself restarting. The third is hardest to build and most often quietly missing, because it means the agent processes cannot be children of the window. Force-quit the app with three agents mid-task during the trial, before you have work in flight you mind losing.
6. Model and vendor neutrality
Different models fail differently, which is most of the argument for running several at once, and a platform supporting one agent CLI has bound you to one vendor's roadmap and one vendor's outages. Breadth varies: Vibe Kanban drives ten or more agent CLIs including Claude Code, Codex, Gemini, Copilot, Amp and Cursor, while Sculptor drives Claude Code only. Neither is wrong, they are different bets. The subtler part is maintenance, since these CLIs change in ways that break anything parsing their output. So ask not only which agents are supported today but whether you can point the tool at an arbitrary command when it has not caught up. An escape hatch to a plain shell is worth more than a long support matrix.
7. An exit
Here is the one people skip. Ask where the state lives. If the branches, the worktrees and the commits are in your repository, the platform is a lens over work that exists without it, and leaving costs you a workflow. If the task graph, the notes and the transcripts live in the vendor's database, leaving costs you the work.
This is not hypothetical. From the comparison table we keep, checked 2 August 2026: Vibe Kanban is Apache-2.0 and self-hostable, and Bloop, the company behind it, shut down on 10 April 2026, with the last release on 24 April 2026. Crystal is discontinued and replaced by Nimbalyst, last release 26 February 2026. Both put their state in git, so their users kept their repositories and lost a user interface. That is the good version of this outcome, and it happened twice in one table inside a year. So ask what you would still have if the vendor stopped tomorrow. A good answer arrives immediately, because it is a selling point. A bad one talks about export formats, and an export you have to remember to run is a chore with a deadline nobody warns you about.
where the platform runs, and what leaves your machine
The deployment shape decides who can see your source code, which is the constraint that settles the choice for anyone working under a policy. Three shapes exist.
Local desktop
The app runs on your machine, the agents are processes on your machine, and the repository never leaves it. Code still goes to a model provider, because that is what a coding agent does, but over the same API and terms as if you ran the CLI yourself: the orchestration layer adds no new party. The cost is that your laptop is the substrate, so close it and the work stops, and nobody else can see the session.
Self-hosted server
The same software on a machine you control, usually reached through a browser. Agents keep working when you close the laptop, several people can watch the same run, and the code stays inside your perimeter. You are buying availability and paying in operations: you now run a service, patch it and decide who may reach it. Open licences matter more here than anywhere else, because a self-hosted product you cannot fork is a service with extra steps.
Hosted SaaS
The vendor runs the machines. Your repository is cloned onto infrastructure they operate, the agents run there, and you get a URL. This shape has the best story about long-running work and machines that do not sleep, and it is the one where source code genuinely leaves your control. That is not a scandal: plenty of teams already host their code with a third party and this is no larger a step. It is a fact to check against your own agreements before you trial it rather than after, and to check for the tier you will actually use, since a local mode and a hosted mode of the same product can differ.
when you need no platform at all
One agent needs no orchestration platform. Two agents need a tmux config and the discipline to give each one its own worktree. That is not a compromise or a starter setup, it is a complete answer for a lot of working developers, and a platform is worth exactly the bottleneck it removes and not a penny more. The failure mode of adopting one early is not wasted money, it is that a tool you do not need yet teaches you nothing about the problems you were going to have. Three signals say you have outgrown the terminal, and each either happened this week or did not.
The first: you cannot say which agent is blocked. You have four panes, one of them has been waiting on a permission prompt for an unknown number of minutes, and finding out means visiting each in turn. The second: you have lost work to two agents editing the same file. Not a merge conflict, which git would have shown you, but a silent overwrite you found later while wondering why a fix you watched land had disappeared. The third: you cannot answer what the afternoon cost. Somebody asks, and the only honest answer is that you will know when the bill arrives.
None of the three is about ambition or scale. All three are about having lost track of something, which is what a platform is for. If none has happened to you, the terminal is still winning, and there is a decent argument for staying there anyway: Claude Squad manages several agents in isolated worktrees without leaving the terminal, is free and AGPL-3.0, and runs over SSH on a machine with no display.
build or buy
A small team can assemble a lot of this from parts it already has. Isolation is the easy part and it is most of the value: a shell script that creates a worktree and a branch per agent, launches the agent CLI in it, and tears the worktree down after a merge is a few dozen lines. Layout is a tmux config. Handing context between agents is a plan file committed to the repository, which beats any messaging protocol because it survives a restart and a human can read it. Merge order is a decision you write down before you start. A team with those four things has a working setup and has spent an afternoon.
Three things are genuinely annoying to build, for reasons effort does not remove.
A live spend meter across sessions. Not the display, which is easy, but the arithmetic: attributing usage to the right session, pricing cache reads and writes at their own rates rather than the input rate, and coping with transcript files appended to concurrently that contain duplicate lines. Get it wrong and you have a number that is confidently incorrect, which is worse than none because you will trust it.
Blocked-agent surfacing. There is no clean signal for "this agent is waiting for a human". You infer it from output patterns, from silence, from prompt text that changes between CLI versions. Every agent supported is another set of heuristics, and every CLI release is a chance for them to stop being true.
Durable sessions. Detaching processes so they survive the tool restarting, and reattaching with scrollback intact, has a long tail of edge cases around pseudo-terminals, resizing and cleanup after a crash. tmux gets you most of the way, which is why so many tools sit on it, and the last stretch is where the work is.
So build the isolation, because it is short and you will understand it. Buy, or adopt something open, when what you are missing is the meter, the blocked-agent signal and durability, and when you have noticed you are missing them rather than read that you should.
one implementation, and what it is not
Skribbl is our attempt at a workspace orchestration platform, and since this page is a checklist it would be poor form not to run it against the same questions. It is a macOS desktop app, Apple Silicon only, that puts real terminals on an infinite canvas. Each agent, Claude Code, Codex, Gemini or Grok, is a node running a real shell, and worktrees are bound to a group, so a fleet spawned in one action lands one worktree each. Authority is drawn: a line from one agent to another lets the first command the second, and rubbing it out revokes it, so the topology diagram and the permission model are one object rather than two that drift apart. Sessions survive restarts. A meter in the top bar shows spend at all times, and today it covers Claude Code only.
What it is not. Not a framework: if you are building agent behaviour into a product, this is the wrong family. Not hosted, and there is no server mode, so if you need agents that keep running when the laptop shuts we have no answer and some tools on our comparison page do. Not cross-platform. It includes no model and no subscription, so it does not reduce what your agents cost, it only shows you. And it does not decide your decomposition: every topology in the orchestration post is still your choice.
On the seventh question, the exit, our answer is the one we would want from anyone else. The work lives in your repository as branches and commits made by ordinary git commands in ordinary worktrees. Skribbl is closed source, a real cost to weigh, but if it vanished tomorrow you would keep every branch and every commit, and lose a canvas.