An agent control plane routes work; an open-source fleet keeps the record

Two terms doing different jobs

An agent control plane decides where work goes. It takes a task, picks the agent that should handle it, and follows the run to the end. An agent fleet is a different object: the agents themselves, the rules that let each one act, the person who answers for it, and the record of what it did.

The two get mixed up because both are described in the same words. Agents, tools, runs, tasks: the vocabulary is shared, so the products look alike on a features page. Behind it sits a real split. One is a routing decision, made per task, again and again. The other is a standing decision about authority, made once and enforced all day.

What routing buys, and what it leaves out

Routing is work, and a good control plane does it well. It queues tasks, schedules them, retries a failed run, and fans one request out to several agents at once. Those features matter. They are also the easy half, because a queue and a retry loop are not hard to build.

The hard half is a set of questions a router never has to answer. Who owns this agent? What may it touch? Who approved the write that just landed? Where does the record of that approval live? A control plane can call an agent it does not own, hand it a task, and lose sight of the consequence. When a write goes wrong, its log shows a call. A log of calls is not an authority record.

Three layers wear one name

The phrase covers at least three systems that buyers treat as one. The first is a routing layer: it matches work to agents. The second is a model gateway: it holds the keys, picks the model and meters spend. The third is governance: who may act, what a person has to approve, and where the audit record sits.

A fleet owner usually needs the third layer on day one, needs the first by the time two agents compete for the same queue, and can rent the second from any provider. Buying a router when the gap is governance leaves the gap open.

The market shows the split. LangSmith Fleet is a no-code agent builder whose agents work in Slack, Teams and Gmail, with tool-level approval requirements and a central agent inbox; LangChain hosts it. FleetQ is an open-source orchestration tool you run yourself on Docker Compose, with a per-tier risk policy of auto, ask or reject. Both are honest answers to a routing question. Both also keep the fleet's definition inside their product, which is the part a router cannot hand back.

Pick by the problem you actually have

If your problem is throughput across a fixed set of agents you already trust, a control plane is the shorter path. Buy it, point it at the agents, and spend the saved weeks on the work. That holds when the agents are yours, the permissions are settled, and someone can say who approved last month's changes.

If your problem is authority and change, the file matters more than the router. Authority is hard to delegate because it lives in details: which tool a prompt may call, which memory an agent may read, which person signs off. A control plane holds those details somewhere. The question is whether that somewhere is yours.

An owned fleet keeps the answer where a person can read it. In Kortix, a project is one git repo. Its agents, skills, memory and connector settings are files in that repo. A permission becomes a line in a diff, and the reviewer reading it sees what the agent runs from.

The default in that file is permissive, and the file says so. Every key is optional. No tool call of this agent waits for a person: an omitted permission is allow. The permissive default is a reason to own the file rather than rent it: the person who sets the policy can see it, diff it, and hand it to a reviewer.

Change has the same shape. When an agent changes the project itself, for example a skill or its memory, it opens a change request, which a person reviews on the Review page and merges, so ownership arrives with a check attached instead of access alone.

Every action is recorded. The record is the difference between a fleet you can defend in a security review and one you can only describe.

Read a manifest as a policy

The definition of a fleet is short enough to read in a meeting. Ten lines name the default agent, its instructions, the tools it may call, the skills it loads, and whether it gets a repository in its workspace. The comments carry the part that bites: each one states what an omitted key means, so a missing line is a decision, not an oversight.

That is the artifact most control planes cannot hand back. LangSmith Fleet lets you export agent files for pro-code use, and the file leaves cleanly. The history behind it does not: who changed a permission, when, and which person merged it. In a repo, that history is the commit log, and it survives the vendor.

Why the two compose

Keep a control plane for the work it does well, and put the fleet's definitions, permissions and approvals in a repo you own. The two do not compete for the same layer. A router that reads its agent list from a git repo is a better router, and a fleet with a good router gets tasks to the right agent faster.

Before you buy either, ask five things. Where do the definitions live, and who can edit them? Is the default permission allow or deny? Does an approval attach to the specific call or to the tool in general? Can the audit record be exported? Can you run the whole thing on your own infrastructure?

None of those questions needs a demo. Each has an answer in a file or a console, and the answers tell you which layer you are missing.