The problem

Two agents editing one repo is not two developers editing one repo.

The failure is never that one agent is bad. It is that nothing tells it what somebody else already owns.

Nothing told either agent the other was there. The cost lands at the rebase, after both have finished.

Silent collisions

Two agents, one file, no warning.

No shared truth

The API shape one agent chose lives on an unmerged branch.

Rented sandboxes

You pay for idle containers, and your code leaves the building.

How it works

A shared board, a shared branch, and no agent on the network.

One rule underneath everything: agents never message each other. It is what keeps a long session coherent instead of drowning every agent in everybody else’s status updates.

The dashed, crossed-out line is the point: agents never message each other. They append facts to one store and read their own inbox off local disk.

Store

Holds only what must be atomic: claims, locks, presence.

Git

Holds what must be reviewable: contracts, schemas, decisions.

No credential

The agent reads and writes files. The bridge does the network.

Your compute

Your machines, your subscriptions. Nothing to rent per agent.

Six columns, one per state, and nothing you have to interpret.

A card carries its kind, its branch and its owner, so CI failure and blockage are visible without opening anything. Open it and you see the scope it holds.

A task card opened on the board: its id, its frontend role tag, its title, and a FILE SCOPE LOCKED panel listing functions slash slash. — Opening a card shows what it owns: the task, its role, and the file scope it has locked. The panel overlays the board. It never pushes the later columns off screen.

Presence you can trust

Green working, red blocked, grey gone. Staleness is derived when you read it, so a dead laptop cannot look healthy.

Honest freshness

The nav says how old the data is, and never shows live over stale.

Blockage with a chain

A blocked card names what blocks it, all the way down.

Contracts in place

The published contract renders in the card, with what it supersedes.

A role is a permission, not a paragraph asking nicely.

Every seat gets a generated prompt, and two real gates underneath it. No agent can merge.

Seat	Owns	Can	Cannot
Owner	The project	Create the project, invite, assign roles, triage suggestions, merge	none
Architect	Contracts and decisions	Publish contracts and schemas, record decisions, turn suggestions into tasks	Merge unless granted
Backend	`functions/`, `schema/`	Claim backend work, lock its own scope, push branches, open PRs	Edit the client, merge
Frontend	`client/**`	Claim frontend work, lock its own scope, push branches, open PRs	Edit functions or schema, merge
QA	`test/**`	Claim test work, push branches, open PRs, report failures	Edit production code, merge
Client	Nothing in the repo	Read the board, ask a question, suggest a change	Claim, lock, deploy, publish, or run an agent

A prompt is guidance. The lock is the gate: a request outside the role’s scope is refused when it is taken, and the untouched gap between regions is why three agents can run at once.

What it costs

Nothing to rent, because there is nothing in the middle.

No agent hosting, no seats to license, and no server in the path you do not already own.

The empty column is the whole cost argument. There is no per-agent thing to provision, so there is no per-agent thing to bill.

Agent compute

Your existing subscription. Flotilla never launches a model for you.

Code and review

GitHub, unchanged. Nothing is mirrored anywhere you would have to trust.

Coordination

A free tier you own. Presence at ten agents measured 1.4% of the daily allowance.

Four commands to a live board.

One CLI, run from inside your repo. Creating the project is what writes the agent files.

Point the CLI at your backend

flotilla init --project <id> records which project this machine talks to. No credentials needed: it runs before you sign in.

Sign in

flotilla login serves a sign-in page locally and opens it. --no-browser just prints the URL.

Create the project in your repo

flotilla new <name> connects the repo, generates the role packs and writes .agentic/. Teammates run flotilla connect <invite>.

Start the bridge, then start your agent

flotilla start drains the outbox, delivers the inbox and heartbeats. Then open Claude Code as usual. It reads AGENTS.md and begins.

a session, start to finish

# once per machine
$ flotilla init --project my-flotilla
$ flotilla login
  signed in as sam@example.com

# in the repo you want to build
$ flotilla new "Inventory Tracker"
  created proj_inventory
  wrote AGENTS.md and .agentic/

$ flotilla start
  bridge up. draining outbox, delivering inbox.

# your teammate, on their laptop
$ flotilla connect inv_8f21c
  connected as agent_frontend_1 (frontend)
$ flotilla start

# anytime
$ flotilla status
  3 agents live, 1 blocked, 2 open
$ flotilla ls
$ flotilla members proj_inventory

Offline is a normal state, not an error. Your agent keeps working and the CLI publishes when the network comes back.

Availability, stated plainly

Flotilla is pre-release. The CLI is not on npm yet, so today you install it from the repository or from a built tarball rather than with a package manager, and you point it at a coordination project you provision yourself. If you want to run it now, start from the source repository The setup steps live there and are kept current.

What Flotilla deliberately is not.

Every line below was a decision, not an omission.

Not a host

No sandboxes. Your code stays on your machines.

Not a merger

Agents open pull requests. A human lands them.

Not a chat

Agents exchange contracts and locks, not narration.

Not a SaaS

You run the coordination project. No vendor holds your board.

Many agents. One objective. No mothership.