a CLI, not a SaaS.

The problem that won't stay solved

Anyone running multiple coding agents in parallel has tried the obvious stack: tmux panes, shell scripts, maybe a Makefile that fans out to claude and aider on different feature branches. It works until it doesn't. Sessions crash mid-task. Two agents grab the same file. The logs scroll off. You restart and it's not obvious what got finished, what's half-done, and what was never started.

The lesson, learned the hard way, is that orchestration of agents needs the same primitives as orchestration of anything else: an event log, lock leases, bounded timeouts, and a merge queue. brat is the bundle of those primitives, plus the adapters to talk to the agents that actually do the work.

Built on Gritee

The substrate is Gritee, an append-only event log that lives in refs/grite/wal. It is not a database. It is a chain of immutable events stamped into git refs — meaning every brat installation gets durable, audited, replayable state for free, without any external service.

This shapes the design end to end. Tasks aren't rows; they are projections from events. A crash isn't corruption; it's a pause. The materialized view (the sled-backed local cache each actor reads from) is always derivable from the WAL. If you want to know why something happened, you read the log.

The six roles

The harness is split into six roles, named after a small-town transport metaphor. The Mayor is the AI orchestrator that breaks down work. Convoys are bundles of related tasks. Witnesses spawn and supervise agent sessions (we call them polecats — they're scrappy, fast, occasionally bite). The Refinery owns the merge queue. The Deacon does background cleanup. Tasks are individual work items. That's the whole vocabulary; once you know it, every command makes sense.

Engines we wrap, on purpose

brat ships adapters for Claude Code, Aider, OpenCode, Codex, Continue, Gemini, and GitHub Copilot. We added each one because someone on the project actually used it, not because we wanted a long table on the README. Adding a new engine is an adapter — a couple hundred lines of Rust that knows how to spawn the binary, handle its session protocol, and parse its output. We will keep adding them as long as the underlying tools keep existing.

What we deliberately don't do: prompt engineering, model selection, vendor billing. Those belong to you and to the engine you picked.

Why a CLI instead of a control plane

brat is a CLI plus an optional HTTP daemon. The CLI is the unit of correctness — every command is a complete transaction against the WAL, so even if you ctrl-C it, the system is in a defined state. The daemon (bratd) exists for the web dashboard and for multi-session coordination, but it auto-starts when something needs it and idle-shuts-down after fifteen minutes. There's nothing to keep running.

That design is a deliberate response to where this category usually goes: a hosted SaaS that owns the orchestration plane, charges per agent-hour, and locks your state in their database. We think that arrangement is a category error for tooling that is fundamentally local — your code, your git history, your agent invocations. The right shape is a binary you install and forget, not a service you subscribe to.

What honest positioning looks like

The README has a section called "what brat doesn't solve" and we put it on the homepage too. Engine reliability is outside our control. Real merge conflicts still need a human. Prompt quality is your job. CI/CD setup is your job. We can give you the harness; we can't give you good taste.

If that's the deal you want, brat is for you. If you want a vendor to take all of that on, brat is not for you, and we'll point you somewhere honest about which alternative fits.

Who is building it

brat is a project of neul-labs. It is MIT-licensed, written in Rust, and lives in the open at github.com/neul-labs/brat. Contributions, bug reports, and adapters for new engines are all welcome. The docs are at brat.docs.neullabs.com.