Watch MultiCascade actually work

One model, running labeled passes in sequence. Not separate agents, not a team — the same model wearing one hat at a time, in the open.

Root read: "coding bot that thinks of better routes with full coding libraries" has two live meanings — vehicle/path routing, or HTTP API routes. Cascade assumed vehicle routing, because "better routes" plus "full libraries" reads as an optimization stack. If it's API routes, only the Architect pass changes; the shape holds.

Roles assigned: Architect, Builder A (tool layer), Builder B (reasoning loop), Critic.
Skipped — Tester: MultiCascade is a prompt config, not a runtime; it cannot execute Python or benchmark a solver, so a tester role would only be pretending. Skipped — Scribe: one deliverable, no handoff doc needed.

Architect —
Scope: a bot that ingests a stop list, builds a road-distance matrix, solves, then proposes and defends alternatives. Not scoped: live traffic, driver scheduling, a UI. Stack: OSMnx for graph pull, OR-Tools for the solve, pandas for I/O. Success test: given 38 stops in Portland, it returns a route plus at least two structurally different alternatives with cost deltas and a stated reason each.

Builder A — tool layer
route_tools.py exposing four callables the model can invoke: build_matrix(stops, mode) via OSMnx shortest paths; solve(matrix, vehicles, time_limit, strategy) wrapping OR-Tools RoutingModel; score(route) returning distance/duration/stop-count balance; diff(route_a, route_b) returning which stops moved between vehicles. Strategy is a parameter, not a constant — PATH_CHEAPEST_ARC, SAVINGS, CHRISTOFIDES.

Builder B — reasoning loop
Four-step cycle: (1) baseline solve, (2) generate three named hypotheses in plain language — "cluster east river stops onto one van," "allow a 15% detour to cut vehicle count 3→2," "prioritize time windows over distance," (3) translate each into a solve() call with different strategy/constraints, (4) return a comparison table with the delta and the tradeoff spelled out. Illustrative run: baseline 214 km / 3 vans → hypothesis 2 lands 176 km / 2 vans, +22 min longest leg.

Critic — required flaw
Real weakness, named: Builder B's "hypotheses" are not structurally different searches. Three of the four are the same OR-Tools model with a different first-solution strategy and a longer time budget — local search converges to near-identical assignments, so on tight geographies the bot will output three rows within 1–2% of each other and look like it isn't thinking. Genuine variation requires changing the model itself (vehicle count, capacity, time windows), not the search heuristic.

Honest limit: the 176 km figure is illustrative. This config shapes how the model plans and writes the code; it does not run OR-Tools or verify a number. You get the architecture and the loop — you supply the execution environment.

Cascade summary — shipped as scoped: tool layer, four-step improvement loop, comparison output. Left for you: whether hypothesis generation should mutate model constraints instead of search strategy. That's a scope call, so it wasn't fixed unasked.