A marathon follows a fixed route: plan, build, verify, done. Expedition doesn't have a route. It looks at where it is, picks its own next move, research, redesign, build, or diagnose, and keeps looping until the thing is done or it hits a wall only you can clear. When it gets stuck, it works out why and changes approach instead of retrying into the same wall.
Marathons are the right tool for work you can specify up front. But the moment reality contradicts the plan, a fixed pipeline can only retry the same step. Expedition is built for the opposite case: goals where the plan has to change as you learn.
We studied the field before designing this. It splits cleanly in two, and the split is the opening. Research agents produce a report and stop. Coding agents plan then build, but only ever research the repo in front of them, and charge ahead when the goal is ambiguous or impossible.
Nobody fuses the two. The research agents can't build. The build agents don't research the world or check feasibility, they assume, then thrash. And across the board, agents recognize an impossible task only 37 to 45 percent of the time, while a study of 1,023 API endpoints found every integration failure traced to a spec that lied. One adaptive loop that researches the world, gates on feasibility, and can circle back mid-build is the whole opening.
One controller sits at the center. Each turn it reads the current state, decides the single best next move, dispatches that capability, and folds the result back in. The traveling mark is the loop running. It exits down and right: shipped, or blocked on something only you can decide.
These aren't phases in a line. Each turn the controller picks whichever one the situation needs. It might research three times before building, or build, hit a wall, and jump straight to redesign.
Naive agents loop forever, calling the same failing tool with the same arguments. Expedition watches for that and treats it as a signal to think differently, not try harder.
The controller tracks every move and its outcome. Stuck means the same action, the same failure, twice, or no forward progress across a few turns.
It stops, writes a short critique of what actually went wrong, and forces a different move: maybe the build needs research, maybe the design was the bug.
Every piece below is a documented weakness in the systems above. Expedition's bet is to fix all six inside one loop. It starts before the loop even runs, with the move nobody makes: a feasibility gate.
Your examples, as loop traces. Notice none of them run the moves in the same order, and one of them gets stuck and recovers.
The loop, the recovery, the research fan-out, the design phase. We're assembling known patterns, not betting on a new idea.
The moves reuse what's in the codebase: research tools on every worker, the marathon engine for Build, the verify gate. The new thing is the controller that decides between them and recovers when stuck.