What an open-source agent fleet needs, and what a builder adds

What running a fleet means

A fleet is running when four questions have an answer a person can point at. Who is each agent, and what is its job? Where does a task execute? What may the agent do without asking? And where is the record of what it did? A dashboard is a view over those four answers, not a fifth one.

Most teams write the first answer down and keep the other three in their heads. That holds at two agents. At five it stops: nobody can say which agent sent the customer mail, and the person who could have said is away.

Kortix keeps the answers as files. A project is one git repo. Its agents, skills, memory and connector settings are files in that repo.

Step 1: write the fleet down in one repo

An agent is an assistant with a job description. It has instructions that say what it does, a model it thinks with, and permissions that decide what it may touch. Write those three things per agent, one block per agent, and the fleet becomes something a reviewer can read in a diff.

The manifest is where a fleet starts, and this one defines a single agent in a handful of lines:

# 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

default_agent picks the agent that a bare kortix sessions new runs. Each name under agents holds a description, a prompt and the reach that comes with it. The trailing comments spell out the defaults, because those defaults are easy to misread. tools: all arrives with a warning. An omitted skills gives the agent no skills at all, and an omitted workspace gives it no checkout of the repository.

A fourth agent is a fourth block. So is a fifth. The registry is the file, the file is in git, and the question of who widened an agent's reach has an answer in a commit.

Step 2: give every task its own sandbox

Shared state breaks first. Two agents in one checkout overwrite each other's half-written file. One agent's dependency install turns another's test run into a hunt for a version nobody changed. A session that inherits the last session's working tree starts on top of work that has not been reviewed.

Every session runs on its own isolated cloud computer. A session never touches your laptop or another session. That is the sentence that lets the third and fourth agent run beside the first, because execution stops being a resource you ration and nothing queues behind a colleague's long job.

A session is one unit of agent work, and kortix sessions new starts one. It works on its own branch, named after the session, so the work has an address before anyone opens a file.

Step 3: put the gate where the writes are

Approval at the planning layer does nothing. The moment that matters is the call that leaves the building.

A connector rule set to Ask holds the action until a person approves it. An approval covers one exact action. A changed detail needs a new approval. A reply you approved on Tuesday does not cover the same reply to a different customer on Wednesday, and a $40 refund does not carry a $400 one.

The other half of the rule is easy to skip. Every key is optional. No tool call of this agent waits for a person: an omitted permission is allow. A fleet nobody configured runs as far as its connectors reach, which is fine on day one and less fine on day forty.

Three settings cover the work. Allow the reads. Set Ask on anything that writes outside the project: sending mail, posting to a channel, moving money, closing a ticket. Block the actions no agent in the fleet should take at any hour.

Step 4: route project changes through review

An agent that can rewrite its own skill is useful and risky in the same motion. When an agent changes the project itself, for example a skill or its memory, it opens a change request. A person reviews it on the Review page and merges it.

That is the only route from session work into the default branch, and kortix cr merge is the command that walks it. A session branch merges into the default branch, so the fleet's own definitions pass the same gate as the work they produce.

Two things follow. The diff is the review: a permission that went from Ask to Allow is three visible lines, where a settings screen would have shown a checkbox and no history. And an agent cannot quietly become a different agent over a weekend.

Step 5: watch each agent, not the fleet total

A total hides the agent that costs the most and the one that keeps failing. Record per agent instead: sessions started, credits spent, actions that waited for approval, change requests opened, and how many of those came back with changes requested.

Kortix records every action in an audit log (each entry has a title and a route). That settles the argument about what actually ran. Read it beside the credit line, because a cheap agent that opens change requests nobody merges looks busy in one column and idle in the other.

The quiet failure to watch for is an agent whose sessions all end in a change request that stalls. Its count of sessions keeps climbing while its output stays at zero, and a fleet total will not tell you which of the five it is.

Where a visual builder earns its place

FleetQ is an open-source, self-hosted agent orchestration platform. It draws work as visual DAG workflows with 8 node types, splits a crew into coordinator, worker and reviewer roles, and sets a per-tier risk policy of auto, ask or reject. A credit ledger pauses work on overspend. If the job is one pipeline of fixed steps that runs on a clock, drawing that pipeline is faster than describing it, and the drawing becomes the documentation.

LangSmith Fleet takes a different route: a no-code builder, agents that work in Slack, Teams and Gmail, tool-level approval requirements with a central agent inbox, and tracing in LangSmith. It fits a team that wants the builder and the hosting from one vendor.

Neither choice removes the four questions. FleetQ keeps definitions in its database, LangSmith Fleet keeps them in its builder, and Kortix keeps them in files in your repo. The difference shows on the day someone asks who changed an agent's permissions last month, and the answer is either a commit or a support ticket.

A drawn map helps people see the shape of the work, but the definitions it draws still belong in files a person can diff.