Why a thin CLI beats SaaS for agent orchestration

Most of the multi-agent orchestration story for AI coding tools is heading in one direction: hosted control planes, agent dashboards as a service, per-seat pricing, your sessions running in someone else’s VPC. There are real reasons for that — the network effects are good, the operability is somebody else’s problem, and most teams don’t want to think about the substrate.

We picked the other path. brat is a single Rust binary you install. The optional daemon (bratd) auto-starts when something needs it and shuts down after fifteen minutes of idle. There is no account, no login, no telemetry phoning home. The state lives in your repo. The agents run on your machine. This post is why.

The category is “local tooling,” not “platform”

The first thing we wanted to be clear about, internally, was the right category for this work. A multi-agent harness for coding tools is not the same kind of thing as a CI platform or a deploy platform. It runs against your code, on your hardware, alongside binaries (claude, aider, codex) that are already CLI-shaped and that you already have running locally.

The harness is closer in shape to git or make than it is to GitHub Actions. It is a tool you reach for, not a service you sign up to. We took that observation seriously and let it shape the design from the first commit.

The implications are immediate. Tools don’t have accounts. Tools don’t need a control plane to function. Tools don’t make you renew a subscription to keep using yesterday’s work. Tools install with one command and stay out of your way until you call them.

”But what about the dashboard?”

This is the first objection that comes up internally and externally. brat has a web dashboard — we ship it, we use it, we put it in the demo script. How does that square with “no SaaS”?

The answer is that the dashboard is local too. bratd is an HTTP daemon that runs on localhost by default. It auto-starts when a command needs it (which is, in practice, only the UI and the multi-session coordination commands), and it shuts down after fifteen minutes of idle. There is no remote endpoint. There is no analytics service. There is no “your session is live in our cloud.”

If you want the dashboard, you start it with ./scripts/ui-demo.sh and point your browser at localhost:5173. If you don’t, you never run that script and the daemon never wakes up. The CLI is the unit of correctness; the daemon is a convenience.

This matters because it means you can use brat in environments where the SaaS version of this product would not be allowed: behind a corporate firewall, on an air-gapped build server, in a regulated environment that won’t let you send code or prompts to an unmanaged third party. We didn’t design for those environments specifically. We just designed for “tool, not platform,” and those environments fell out.

The control-plane tradeoff

We are not pretending the SaaS alternative has no advantages. It absolutely does, and an honest design conversation has to name them.

A hosted control plane lets you see every team’s agent fleet in one place. It lets you bill by usage. It can offer features brat cannot — federated search across teams, central policy enforcement, shared prompt libraries with access control. If your organization is large enough that those things are valuable, the SaaS shape is a reasonable answer.

What you give up is everything we listed under “tool” above. You give up the ability to use it without an account. You give up the ability to operate it in isolation. You give up the option of treating your agent orchestration the same way you treat your build tooling — owned, scriptable, local.

We made the trade in the other direction because the population we wanted to serve first is people running AI coding agents on their own machines or on machines they already own. For that population the harness should be invisible. You install it once and you don’t think about it again unless you want to.

The honest cost of “local first”

There are real costs to this design. We pay them on purpose.

Distribution. A Rust binary is harder to ship than a web app. We have to think about install scripts, package managers, build targets. Anyone using brat has to have cargo or accept a curl-bash. The SaaS version of this would land in your browser, no installation step.

Observability. When something goes wrong in someone else’s local environment, we can’t go look. We have a brat doctor command and we ask for the WAL excerpt and the engine version, but it is not the same as having a metrics pipeline that tells us your sessions are failing at 11pm on Tuesdays.

Update cadence. Hosted services update under you. brat updates when you cargo install --git again. We tried to make the upgrade path painless — the WAL is forward-compatible, your config is stable, your existing tasks resume — but it is still your responsibility.

Multi-team coordination. brat operates one harness per repo. If you have ten repos and ten teams, you have ten harnesses. There is no central view because we deliberately did not build a central thing.

We think those costs are worth it. We also think it’s important to write them down so we are not surprised by them later.

Why Rust, since you asked

The choice of Rust was downstream of the choice to be a CLI. We wanted a single-binary distribution, predictable performance, the ability to write a sled-backed materialized view without GC pauses, and a type system that would help us reason about state transitions. Rust gave us all of that. We don’t have a religious position; we have a tooling one. (Also, both the substrate — Gritee — and the engine adapters are Rust crates we wanted to share with.)

What this means for users

If you are a small team running coding agents on your own machines, brat should feel like the right size of thing. It installs, you point it at a repo, you start a Mayor, and you go. You never make an account. You never set up SSO. You never get an invoice. The whole thing fits in a single shell window most of the time.

If you are a large organization that needs federated observability across many teams, brat is probably not the only tool you need. We are honest about that on the home page and in the compare pages. There are likely places where a hosted control plane will be the right answer for you. Use brat for the work where it fits, use something else for the work where it doesn’t, and let the tools earn their place.

The minimum viable proof

The fastest way to see whether the local-first model works for you is to run the demo:

git clone https://github.com/neul-labs/brat
cd brat
cargo build --release
./scripts/mayor-demo.sh --with-ui

If, fifteen minutes later, you have not had to create an account, sign in, send any data anywhere external, or fight with a SaaS UI, then the design point is doing its job. That’s the proof we can offer. Everything else is the README.