Run an open-source fleet whose rules are files

What open source has to cover in a fleet

An agent fleet is several agents run as one unit: one owner, one policy, one record of what each one did. Most fleet tools open a different layer. They publish the agent loop, the prompt and the tool calls, and they let you swap the model. That layer is worth having. It is also the part you would rewrite first.

The fleet's expensive layer sits above the loop. A registry says which agents exist, who owns each one and what job it has. A permission set says what each agent may touch. An approval record says who said yes to which write, and when. When those three live in a vendor dashboard, you can fork the agent loop and still leave the fleet behind, because a fork of the loop does not move the rules.

Ask a fleet tool three questions before you install it: where the definitions live, where the permission is written, and where the approval is recorded. A tool that answers "in the product" to all three is a service you are using, whatever its repository says.

Two open-source fleets beside Kortix

FleetQ is an open-source (AGPL-3.0) self-hosted agent orchestration platform, built on PHP 8.4 and Laravel 13. Its center is a visual workflow builder: eight node types, multi-agent crews with coordinator, worker and reviewer roles, a per-tier risk policy of auto, ask or reject, and a budget ledger that pauses work on overspend. It runs on Docker Compose, takes your own keys or a local model through Ollama, LM Studio or vLLM, and also sells a managed cloud at fleetq.net (FleetQ on GitHub). For a team with a fixed pipeline, the DAG is the documentation and the budget controls are native. A reader who wants agents to choose their own steps will fight the DAG, and the definitions live in FleetQ's database and editor rather than in files you can diff.

PilotDeck is an open-source (AGPL-3.0) task-oriented agent workspace from OpenBMB, aimed at one person or a small team running many projects. Each workspace carries its own files, memory and skills, and the product documents memory you can read and edit, model routing by task difficulty, and background work that lands deliverables as files. It installs with a one-line script or Docker Compose, and it speaks MCP natively (PilotDeck on GitHub). For a reader who wants a local workbench with visible memory, that is a direct match. It is a workspace product, not a governance layer: its own pages describe no organization registry and no approval step for writes, so a fleet that answers to a policy needs something above it.

The policy is a file, and the file has a default

Kortix treats a fleet as a project, and a project is one git repo. This manifest is enough to start one:

# yaml-language-server: $schema=https://kortix.com/schema/kortix.schema.jsondefault_agent: assistant agents:  assistant:    description: Answers questions about the project.    prompt: You answer questions about this project. Read the files before you answer.    tools: all                               # omitted: all, with a warning    skills: all                              # omitted: no skills    workspace: { project_repository: true }  # omitted: no repository in /workspace

The agents: block is the registry. Each entry says what the agent is for, which file holds its instructions, and which tools, skills and workspace it gets. Put the same file in every environment and the fleet definition travels with the code, through review, like any other change.

The default is the part to read twice. Every key is optional. No tool call of this agent waits for a person: an omitted permission is allow. A fleet with no permission line is a fleet where every write runs. That is a fine default for a first agent and a poor one for a fleet that touches a bank account or a customer list. Writing the rule down is the work, and a git diff makes that work reviewable.

An approval is worth more when it is narrow. An approval covers one exact action. A changed detail needs a new approval. The yes belongs to the action the person saw, not to a category of action they approved last month.

What Kortix adds to the two

A project is one git repo. Its agents, skills, memory and connector settings are files in that repo. That is the difference between a fleet you can hand to a new owner and a fleet you have to rebuild: the registry, the prompts, the memory and the connector grants arrive as a clone.

Every session runs on its own isolated cloud computer. A session never touches your laptop or another session. A fleet is only as safe as its worst-behaved agent, and a shared machine turns one bad command into everyone's problem. Isolation per session keeps a runaway task in its own box.

The same repository also decides where the fleet runs. Run the same Kortix on your own box. One Docker Compose stack, the same images the managed cloud runs, with your Postgres database and the stack's file storage on disk you control. Nothing about the manifest changes when you move, so a team can start on the managed cloud and end on its own hardware without rewriting the fleet.

What it costs to start

The pricing page lists three plans, quoted as written.

• Free: $0, 500 credits / month, 1 project, bring your own API key for any premium model, connect your ChatGPT subscription.
• Credits: $50 / month and up, unlimited members, one shared credit pool, unused credits roll over one month, up to 200 projects.
• Enterprise: custom, SAML SSO + SCIM directory sync, advanced RBAC + audit logs, cloud/VPC/on-prem, BYOK.

Self-hosting the software is free; the compute and the model calls are yours to pay. A team that already has a server and provider keys can run a fleet for the price of those bills. A team that wants one shared credit pool and no hardware starts on Credits at $50 a month. The plans are quoted from the Kortix pricing page, checked November 2026.

How to choose between them

Start from the work, not from the feature list. If your fleet runs the same pipeline every day, with fixed stages and a budget per run, FleetQ's DAG and ledger fit that shape. If one person keeps many projects moving and wants the memory visible on a laptop, PilotDeck is built for that. If the fleet answers to a policy, holds approvals on exact actions and has to hand over its record, the registry, the permission set and the approval log have to be files in a repo.

The test is whether you can take the registry, the permissions and the record with you when you leave. If yes, the fleet is yours. If the answer depends on an account staying open, the fleet is a subscription with extra steps.

What open source covers beyond the code

The code is the easy half. The registry, the policy and the record are the half a fleet lives on.

• registry: The fleet is a repo you clone on the first day and on the day you leave.
• policy: The permission is a line in the manifest, reviewed in a diff like any other change.
• record: Kortix records every action in an audit log (each entry has a title and a route).
• host: The same images on your own hardware, with the Postgres database and the stack's file storage on disk you control.