Multi-Agent Systems That Run for Days: Inside

The promise of AI coding tools has always slightly outrun the reality. You get a capable agent, you hand it a task, and somewhere between "this is incredible" and "wait, why did it delete that file," you're back in the driver's seat. The bottleneck isn't the model's intelligence anymore—it's yours. Your attention. Your bandwidth to babysit.

That's the premise Luke Alvoeiro opened with at the AI Engineer conference, and it's a framing worth sitting with. "The bottleneck in software engineering nowadays is not intelligence," he said. "It's now limited by human attention. Even the best engineers can only complete a couple of tasks at a time. They may have a backlog of 50 features but they can only drive a few forward per day because every task requires their attention."

Alvoeiro is an engineer at Factory (previously the creator of Goose, now one of the leading open-source coding agents, which was donated to the Agentic AI Foundation). His talk wasn't about a single clever agent trick—it was about an entire architecture his team built to let agent systems run for days without falling apart. They call it Missions.

The Taxonomy Problem Nobody Talks About

Before getting into Missions specifically, Alvoeiro laid out something genuinely useful: a taxonomy of five distinct multi-agent patterns. Most people building multi-agent systems are doing so without shared vocabulary, which is why the field, as he put it, "is a bit of a mess."

The five patterns he named: delegation (one agent spawns another), creator-verifier (one agent builds, a separate agent checks), direct communication (agents DM each other without a coordinator—hard to get right because state fragments), negotiation (agents interact over a shared resource, ideally in a net-positive-sum way), and broadcast (one agent pushes updates to many—less flashy but critical for long-running coherence).

This taxonomy isn't just organizational neatness. It matters because Missions is explicitly a composition of four of these patterns. The orchestrator delegates to workers. Validators run as creator-verifier pairs with those workers. Shared mission state is a broadcast mechanism. Milestone negotiations happen when the orchestrator evaluates handoff summaries and decides whether to course-correct.

The architecture has three roles: an orchestrator that handles planning and produces a "validation contract" before any code is written; workers that each start with clean context, implement a single feature, then commit via Git; and validators that check the work adversarially—meaning they've never seen the code before and have no stake in it succeeding.

The Validation Contract Is the Whole Game

Here's where Missions diverges most sharply from typical agent pipelines, and it's worth explaining carefully.

Most coding agent validation works like this: an agent builds something, writes tests to cover it, tests pass, done. The problem is that tests written after implementation are shaped by the implementation. They confirm what the code does, not what the code was supposed to do. Alvoeiro put it cleanly: "Tests written after implementation don't catch bugs. They confirm decisions."

The validation contract flips this. Before any coding begins, the orchestrator—in conversation with the user—produces a set of correctness assertions that define what "done" means independently of how the code gets written. For complex projects, this can run to hundreds of assertions. Each feature gets assigned assertions it must satisfy, and the sum of all features must cover every assertion. The spec is fixed before the work starts.

After each milestone, two types of validators run. The scrutiny validator is the traditional one—tests, type checking, lint, plus dedicated code review agents per completed feature. The user testing validator is more interesting: it actually spawns the application and interacts with it via computer use, clicking buttons, filling out forms, checking that pages render. Alvoeiro noted that most of a mission's wall-clock time is spent here, waiting for real-world execution rather than generating tokens.

Neither validator has seen the code before. "Validation is adversarial by design," he said. That's not metaphorical—it's structural.

Why Serial Beats Parallel (At Least For Now)

One of the counterintuitive choices in Missions is that features execute serially—only one worker or validator runs at a time. The obvious move for throughput is parallelism, and Alvoeiro said they tried it. It doesn't work well for software development because agents conflict: they overwrite each other's changes, duplicate work, make inconsistent architectural decisions. Coordination overhead eats the speed gains, and you burn tokens in the process.

Serial execution with targeted internal parallelization is what they landed on. Within a feature, read-only operations (searching the codebase, researching APIs) get parallelized. Within validation, code review agents run in parallel. But the sequential structure keeps the state coherent.

This is the kind of finding that only comes from actually running these systems in production, not theorizing about them. Whether it holds as models get better at coordination is an open question Alvoeiro explicitly flagged.

The "Droid Whispering" Problem

There's a skill Alvoeiro's team has developed internally that he named—somewhat endearingly—"droid whispering." It's the ability to mentally model how different LLMs behave in different roles, where they fail, and how those failures compound over a multi-day run.

The insight behind this is that no single model is best at everything a mission needs. Planning benefits from slow, deliberate reasoning. Implementation needs fast code fluency and creativity. Validation needs precise instruction-following. Different roles might be better served by different model families, and—this is the structural move—using a different model provider for validation ensures it isn't biased by the same training distribution as the worker that wrote the code.

"If you're locked into one model provider, then you're constrained by that family's weakest capability," Alvoeiro said. "As models continue to specialize, the ability to put the right model in the right seat becomes a compounding advantage."

This cuts both ways. The validation contracts and milestone structure also mean Missions can run effectively on open-weight models that aren't at frontier performance—the scaffolding compensates for model weaknesses.

The Production Numbers

Factory shared some data from a Slack clone built via Missions, and a few figures stand out. 60% of time and tokens went to implementation. Validation almost never passes on the first attempt—follow-up features are nearly always created from validator findings. The end state: 50% of the final codebase is tests, with 90% code coverage.

Their longest mission ran for 16 days. They believe 30-day missions are achievable. Whether those numbers hold across domains beyond software development, or whether they represent a best-case scenario, isn't clear from the talk—that's the kind of context a single conference presentation can't fully provide.

The Bitter Lesson Problem

Every multi-agent system builder lives with a specific anxiety: the next model release makes the whole architecture obsolete overnight. Alvoeiro addressed this head-on. Almost all of Missions' orchestration logic lives in prompts rather than hardcoded state machines—about 700 lines of text where, as he put it, "four sentences of this can alter the execution strategy pretty dramatically." When models improve, the system absorbs that improvement rather than fighting it.

This is a genuine architectural philosophy, not just an engineering detail. It means Missions is designed to be a surface that models act on, not a rigid pipeline they're constrained by.

There are still open questions Alvoeiro flagged directly: how to further parallelize mission workloads without the coordination chaos they hit before, and how to start orchestrating missions themselves into even more complex workflows. The honest answer is that multi-day autonomous agent systems are new enough that nobody has all these answers yet.

What Missions represents—at minimum—is a serious, production-tested attempt to answer the question Alvoeiro opened with: what does software engineering look like when human attention is no longer the rate-limiting factor? Whether the answer is "teams of five engineers managing 30 workstreams instead of 10," as he projected, or something messier and more contingent, the structure he's describing is one of the more coherent proposals for getting there that I've seen.

The interesting pressure test isn't whether Missions works on a Slack clone. It's whether the "droid whispering" intuition—the ability to model which LLMs break under which conditions over a multi-day run—can be systematized enough that it doesn't require an expert to configure. Right now, that sounds like a human attention problem.

Yuki Okonkwo is the AI & Machine Learning Correspondent at Buzzrag.