Flock
Perch's experimental multi-agent mode. It plans a custom team of workers for a hard task, runs them in phases, and has checker workers verify the result before you see it.
Flock is Perch's multi-agent mode. Where a normal turn is one model working through a task, a flock is a team: Perch plans a set of focused workers for the specific task in front of it, runs them together, and has checker workers review the result before it reaches you.
It is built for hard, multi-part work, the kind where one pass is not enough: reviewing a branch for regressions, auditing a folder of payments, mapping a large repository and naming its risks. For a small, single-step task, a normal turn is faster, and Flock declines those before any work begins.
Experimental
Starting a run
In Perch Terminal, begin any task with /flock followed by what you want done:
/flock review this branch for regressions and verify the testsPerch plans the team, then streams each worker as it runs. You watch the flock form, work, and finish, with a plain count of the tool calls it took. Cancel at any time with Esc in the desktop app or Ctrl-C in the CLI.
How a flock is planned
Given your task, Perch designs a team for it rather than reaching for a fixed template.
- A planner reads the task and returns a team of two to ten workers, each with a specific role ("Regression Hunter", "Patch Worker", "Citation Checker"), a bounded objective, a set of tools it is allowed to use, and where it sits in the run. The plan is built for your task, not chosen from a menu.
- A deterministic fallback takes over if the planner cannot run, for example when you are signed out or offline, or if it returns something invalid. It assembles a team from a fixed set of thirteen proven roles. The result is a safe, if less tailored, flock rather than a failed one.
In both cases the plan is not trusted as-is. Worker counts, write permissions, tool access, and every other number are validated and clamped by Perch before anything runs.
How the team runs
Workers run in phases, and in parallel within a phase where their work allows it:
Scout. Workers that read and map the material first, so the rest of the team acts on what is actually there.
Work. Workers that do the core task, patching code, drafting a section, running an analysis, each with its own focused context and a narrow objective.
Verify. Checker workers review what the team produced.
Reduce. The results are gathered into a single answer.
Each worker gets a bounded piece with its own context, so one step does not pollute another, and a large task moves in pieces instead of one overloaded request. Workers wait on the outputs they depend on; a worker whose dependency is unavailable is skipped rather than handed empty context.
How the work checks itself
Verification is where Flock earns the extra time. Checker workers review the team's output, and their findings never silently pass:
- If a checker finds unsupported claims, missing citations, contradictions, or gaps, the draft goes through one bounded revision pass, then the same checker rechecks it once.
- The findings, the recheck verdict, and a clear next step travel with the final answer, so you see what was questioned and whether it was resolved.
- A partial result is reported as partial. Flock does not dress up an incomplete run as a finished one.
Drafting work that cites sources is held to a grounding contract: claims carry inline [n] markers back to what a scout actually found, and anything unsupported is flagged for verification rather than left to stand.
Roles and callsigns
Every worker has two names. Its role ("Regression Hunter") is what the model works as. Its callsign ("Eagle", "Shawarma", "Bell") is presentation only, a way to tell workers apart at a glance while the run streams. Callsigns never appear inside a worker's instructions, so they cannot influence the work. In the CLI a row reads:
Regression Hunter · Eagle · runningLimits and guardrails
Flock runs inside hard limits, enforced by Perch rather than requested from the model:
| Guardrail | Limit |
|---|---|
| Workers per flock | 2 to 10 |
| Workers that can write to your files | 2 (up to 4 when you explicitly take the wheel) |
| Wall-clock time | 8 minutes by default, 10 minutes hard maximum |
| Total tool calls across the run | 160 |
| Iterations per worker | 10 |
Two rules hold regardless of the plan:
- No recursion. A flock worker cannot start its own flock or delegate to more agents. Orchestration tools are stripped from every worker.
- Honest results. Unavailable models are reported, not faked; unread files are reported as unread; a run that runs out of budget finishes from the evidence it gathered and says so.
What Flock is not
- It is not available in web chat. It needs the local file access that only Perch Terminal has.
- It is not instant. If you need a quick answer, use a normal turn.
- It is not a black box. Every worker's role, status, and cost is visible while it runs.
For the single-agent foundation Flock is built on, see The operator and agents. For how citations are verified, see Citations.
The operator and agents
How Perch goes beyond chat to read files, run analysis in a sandbox, and coordinate focused workers on larger tasks.
Perch Roost
Roost is Perch's routing engine. It picks the right model for each task, races across providers for speed and reliability, and lets text-only models work with images.