FlowCrew

github.com/cuibuaa/flow-crew · MIT · Node/TypeScript

Give it a brief. Walk away. Come back to a result it has already proven — or an honest “it didn’t work.”

FlowCrew is a self-evolving multi-agent architecture: give it a goal, and a supervised crew (planner, coder, researcher, reviewer, QA, supervisor) plans, executes, retries, and iteratively self-corrects — unattended, for hours — until the result is independently verified. Its core is a designed set of execution primitives (“atoms”) and a harness loop: the planner compiles the goal into a graph of verifiable atoms, an inner loop converges each stage (gate → fix → retry), and an outer loop carries findings and dead ends across runs. Node/TypeScript, MIT.

What makes it different

• A plan the engine executes literally. The planner decomposes a brief into a graph of small, individually verifiable stages, written in a fixed vocabulary the engine validates — a role it invents is rejected, not guessed at. An inner loop converges each stage (gate → fix → retry); an outer loop carries findings and dead ends across runs, so a later run pivots instead of repeating.
• A supervisor that watches the run — and still cannot say “done.” It samples progress, sends insufficient work back, ends a stage that has gone quiet, and can force a re-plan. But the same population of models writes the work, measures it, and judges the measurement, so a fluent “it passed” is not independent evidence. A run ends successfully only when the checks it declared for itself run as scripts and exit clean. The crew can raise that bar on itself; nothing in it can lower it. ceiling (“found nothing”), incomplete (“ran out of budget”) and shipped stay distinct outcomes — never a crash dressed up as a success.
• Every hand-off is a file, not a conversation. Plan, work, verdict, scope request, approval — each is a typed artifact at a known path, refused if malformed rather than interpreted. That is also what makes flowcrew rehearse possible: the real scheduler driven by a scripted stand-in, in about a second, at zero token cost, to catch a broken brief before it costs hours.
• Stopping is a rule, not a judgement. In research mode a fixed policy — not the supervisor — computes keep/drop and continue/ship/ceiling from the history of results. A round counts as improvement only if it beats the running best by more than the measurement’s own uncertainty, so noise cannot be banked as progress.
• One engine for research and engineering. The same loop chases a metric (beat a baseline) or satisfies a contract (pass the tests).
• Parks instead of guessing. A consequential action suspends the run for a decision in an approval inbox. A live dashboard carries run traces, the knowledge graph, reruns, and approvals.

Why I built it

Most agent frameworks are optimized to produce an answer. The failure mode that actually hurts in long autonomous work isn’t a wrong answer — it’s a confident wrong one, discovered hours later. So the design question I cared about was not “how do I get the agent to finish?” but “how do I make the system catch itself when it’s wrong?”

That question turned out to have a measurable answer. Across 2,989 runs, 86 were stopped by a deterministic check — and in 27 of them the supervisor, the strongest judge in the system, had already declared the goal met. I wrote up how each design decision followed from a problem like that, including the one result that surprised me most (declaring a stage’s write scope cut a run from 131 minutes to 37.6):

Building something that tells me the truth when I’m not watching