baro — Docs

baro classifies every goal as focused, sequential, or parallel — before the first agent spawns — and enforces the decision in code.

Not every task deserves parallel agents. A follow-up bugfix wants one strong agent on one surface; a feature that steps through shared code wants a few ordered stories; a task with genuinely independent write surfaces is where a DAG fan-out earns its keep. Since 0.70.15, baro decides which shape a run should take — and lets you override it.

The three modes

Mode	Shape	Use for
`focused`	exactly one story, one strong agent	bugfixes, follow-ups, single-surface changes
`sequential`	a few ordered stories, one agent at a time	stepwise work on shared code
`parallel`	full DAG fan-out	independent write surfaces (different modules/files/contracts)

How the decision is made

Before planning starts, an intake step classifies your goal and returns a mode with a confidence and a reason. In the interactive TUI you see it as a picker:

Baro suggests: Focused (93% confident) — Single failing TypeScript finalizer
unit test/behavior surface

  ▸ Focused   (suggested)
    Sequential
    Parallel

Press Enter to accept, ↑/↓ to override. Your choice (or the accepted suggestion) becomes the run's mode contract.

The contract is enforced, not suggested

The mode is not a hint to the planner — it is enforced in code:

focused — if the planner still emits multiple stories, baro collapses them into one story (acceptance criteria and tests merged), routed to the strong model.
maxStories is a hard cap: excess stories are trimmed in priority order, keeping the dependency-closed prefix.
parallelism caps how many agents run at once; focused and sequential runs execute one story at a time regardless of --parallel.

The decision is stamped into prd.json (executionMode), surfaced on the TUI, and returned on the run record in baro cloud — so you can always see which shape a run took and why.

Controlling the mode

baro                     # Auto (default): intake classifies, picker confirms
baro --mode focused      # skip intake and the picker; force a mode
baro --mode parallel "add tests for the four stream mappers"
BARO_MODE=focused baro   # env var form (used by CI / the cloud runner)

--mode auto (the default) runs intake and shows the picker in the interactive TUI. Headless runs (baro --headless, CI, cloud) use the intake result directly — no picker.
An explicit --mode skips the intake LLM call entirely; the contract is built locally with your choice.
--quick implies focused and additionally skips the Architect, Critic and Surgeon — it remains the most surgical path for trivial goals.

In baro cloud

The compose box has the same selector — Auto / Focused / Sequential / Parallel. With Auto, the decided mode and its reason appear as a badge on the run view once the run starts, so you always know what shape the run took even when baro chose it.

Why this exists

Early baro imposed one shape — the parallel DAG — on every goal. Real usage showed the cost: follow-up bugfixes shredded into five stories and millions of tokens, vague one-line prompts interpreted as broad multi-agent epics. Modes are the fix: parallelism where independence is provable, restraint everywhere else. The full story, with both proof runs as public PRs, is in Not Every Task Deserves Parallel Agents.

Execution modes