Orchestrating AI coding agents: lessons from building Brigadier

At Syncra we're building Brigadier (opens in a new tab), a local-first desktop app for long-running AI coding sessions. It is in development, and its source is public on GitHub.

The idea is simple. You talk to one orchestrator. It plans the work, hands tasks to workers, reviews what they send back and reports to you. The workers are the coding agents already installed and signed in on your machine, Claude Code and Codex to start with. Under the hood there is a Rust daemon that keeps running when the window closes, a Tauri desktop shell and a React interface.

Brigadier isn't ready for general use yet. The design decisions, though, are settled enough to write down, and most of them apply to anyone running more than one agent at a time.

1. The orchestrator only talks

The orchestrator never reads the repository, runs a command or edits a file. Its only tools are the ones Brigadier gives it: delegate a task, message a worker, read a report, ask the user, propose a plan. Anything that needs looking at goes to a worker, often a read-only scout.

This is about context. An orchestrator that reads files fills its context with file contents it will never need again. One that only exchanges messages, reports and decisions stays small enough to hold the whole plan of a long session in view. It also keeps the roles honest: the agent that decides what to do is not the one doing it, so it has no investment in defending a particular diff.

2. Workers report in a fixed shape

Workers don't chat with the orchestrator. They submit a structured report: a summary, the changes, the decisions they made, how they verified the work, open questions and references to artifacts. The report stays short. Full findings, logs and documents go into artifacts that the orchestrator can open when it needs them.

A fixed shape makes reports comparable, and it makes gaps visible. A report with an empty verification section says something on its own. Brigadier also checks reports mechanically. A report that names a file that doesn't exist, or one the worker left in a temporary folder, is sent back with instructions instead of being accepted.

3. One git worktree per worker

Every task that writes code runs in its own git worktree, created from the latest state of the session's branch. Parallel workers can't overwrite each other's files, and a failed experiment is thrown away by removing a folder. Only work on separate files runs in parallel.

Landing is deliberately strict. Finished work lands as a commit made with your git identity. Landing in your own checkout is a fast-forward only. If you switched branches, if the branch moved unexpectedly, or if an untracked file would be overwritten, the work waits as "ready to land" and nothing changes. Your uncommitted changes are never overwritten.

Agents are fast at writing code and careless about where it goes, so the tool has to be the careful one.

4. Review by the other vendor

A model reviewing its own work tends to agree with itself. In Brigadier, work is reviewed by a different vendor's model: Claude's work by Codex, Codex's by Claude. Each phase of a session ends with a fresh verifier that runs that review itself and checks every completion criterion for real.

"For real" matters. Verification means type checks, lint, the build, the existing test suite and a runtime smoke check, not a model saying the work looks correct. The final report states exactly what was verified and how, so you know what was checked and what wasn't.

5. Hand off instead of compacting

Long sessions fill a model's context. The usual answer is compaction: the tool summarises the conversation in place and carries on, losing whatever the summary dropped.

Brigadier's orchestrator never compacts. When its context grows large, it writes a handoff note, and a fresh session takes over from a briefing: the note, every decision made in the session, the current task board and the latest messages word for word. The full transcript stays on disk and searchable. You still see one conversation. Workers do the same. A long-running worker hands its task to a fresh session of the same model, in the same worktree, with the spec, a progress log and the current diff.

Behind this sits what we call the Project Brain: a store of what Brigadier already knows about a project, such as modules, conventions and past decisions, each with a record of where it came from. A question answered once doesn't have to be scouted again. When the files behind an answer change, the answer is marked as possibly outdated.

6. Outward actions stay with people

Workers never push, publish, deploy or open pull requests. When a task needs one of those steps, the worker lists it, and you start it yourself. The orchestrator asks for your approval before spending money, using credentials or destroying anything outside the session's own work.

How much else needs your approval is up to you, on three levels. Ask for approval has you approve every plan and change, with workers in the operating system's sandbox. Approve for me lets Brigadier approve on your behalf inside the sandbox and only asks what only you can answer. Full access runs workers like your own terminal, with a visible warning while it's on.

7. Leave no litter

Agents create things: worktrees, temporary folders, session files, dev servers, headless browsers. After a few days of agent work, a machine can be full of orphans nobody remembers starting.

Brigadier keeps a cleanup ledger. It records every file, folder, process and port each agent session creates, and removes them when the task finishes or the session is archived or deleted. A sweep runs again at every launch, in case a crash interrupted it. It deletes only what it recorded. Your own agent sessions and files are never touched.

8. Use the tools people already have

Brigadier drives the claude and codex command-line tools exactly as they are installed on your machine. It never reads their credentials. There is no Brigadier backend, no account and no telemetry. Your code, your conversations and what Brigadier learns about your project stay on your computer.

That constraint shaped a lot of the design. Brigadier can't rely on a server to hold state or recover a session, so the daemon owns the record: every conversation, task and decision lives in its local store, and every agent session is replaceable.

Where it stands

Brigadier is in development. The source is public on GitHub (opens in a new tab), and the plan in its repository describes where it is going, macOS first, then Windows and Linux.

The principles reach beyond one app. When we build agent features into client products, we apply the same rules: narrow roles, structured reports, verification you can check, and people in charge of anything that leaves the machine.