Why plan a freight-routing agent's legs upfront but run ReAct inside each leg?

## Why hybrids exist at all The pure strategies each assume something uniform about the task. Plan-and-execute assumes the whole sequence is knowable before anything runs. ReAct assumes none of it is, and pays a reasoning call per step for that assumption. Real workflows are rarely uniform: their *skeleton* is predictable while their *joints* are not. The hybrid — a coarse upfront plan whose steps each contain a small bounded reasoning loop — matches the control strategy to the local level of uncertainty rather than picking one for the whole task. ## The freight case, concretely A multi-leg European road-freight route is a good example because the two layers are so visibly different. The **outer layer** is stable. Given an origin, a destination, a delivery window and the cargo type, the sequence of legs — which corridors, which crossings, which rest stops satisfy driving-hours rules — is derivable upfront. Writing it as a plan gives you four things at once: a price estimate before committing, a document a dispatcher or a compliance rule can inspect (does this route need a hazardous-goods permit?), the ability to prepare independent legs concurrently, and a stable identity for the route across the run. The **inner layer** is not stable at all. Booking a leg means talking to carrier systems that return stale capacity, customs endpoints that time out, document services that disagree. You cannot enumerate those calls in advance because which call you make second depends entirely on what the first returned. A ReAct loop handles this natively — and typically resolves a leg in two to five turns, which is a cheap loop, not a twelve-turn epic. ## Designing the boundary The hybrid only pays if the seam between layers is disciplined. Three rules do most of the work. **Every planned step needs a verifiable postcondition.** "Leg 4 booked" is not a postcondition; "a confirmation reference exists for leg 4 with the agreed price and pickup window" is. Without one, the outer layer cannot tell whether the inner loop actually succeeded or merely stopped, and an agent claiming success it did not achieve is a well-known failure mode. **The inner loop returns a typed result; it does not edit the plan.** If an inner ReAct loop can rewrite the outer step list, you have thrown away the determinism you bought by planning. Let it return success with data, or failure with a reason, and let the outer layer own what happens next. **The inner loop gets only the tools and context its step needs.** Scoping the toolset per step raises tool-selection accuracy and shrinks the blast radius of a confused loop. It also keeps the inner prompt small, which is where the cost saving over a single flat ReAct run comes from. ## What it costs Hybrids are not free. You now have two prompt layers, two failure modes and two places to look when something goes wrong; traces are nested rather than flat, and your evaluation harness has to score both the plan quality and the per-step execution. There is also a real risk of over-engineering: if the inner loops reliably resolve in one call, the loop is ceremony and the step should just be a direct tool call. Conversely, if the outer plan is wrong more often than it is right, you are paying for structure that keeps being discarded, and a flat adaptive loop is more honest. ## The judgement to articulate The question to ask of any workflow is: *at what granularity does my uncertainty live?* If uncertainty is coarse — you do not know the overall approach — plan nothing and run ReAct. If uncertainty is fine-grained — you know the approach but not how each piece will behave — plan the approach and loop inside the pieces. If there is no uncertainty at either level, you should not be running an agent at all. That framing is what separates a senior answer from a pattern-matching one. The hybrid is not a smarter architecture that dominates the others; it is the right answer specifically when predictability is layered, which in operational domains like logistics, claims processing and deployment automation it very often is.