DesignExecute: When Straight-Line Plans Aren't Enough

PlanExecute is deliberately strict. Plans are straight lines of assignments. No loops. No if. No try. That constraint is what makes plans easy to validate, trace, and replay.

But some tasks need control flow. "Sum the nutrition for every ingredient in this recipe" isn't a straight line. The number of ingredients is only known at runtime. You need a loop. (The full working example lives in core-py/examples/recipe_book.)

That's what DesignExecute is for.

The Task That Breaks PlanExecute#

Imagine a RecipeNutrition agent. You give it: "What's the nutrition for a meal with 200g chicken breast, 150g rice, and 100g broccoli? Serves 2."

The agent has two functions it can call: get_nutrition (look up one ingredient) and add_nutrition (add two totals together). Now watch what each blueprint has to generate.

PlanExecute: straight line, hard-coded#

python

# PlanExecute: no loops, so every ingredient gets its own line.
chicken = get_nutrition(ingredient="chicken breast", grams=200)
rice    = get_nutrition(ingredient="rice", grams=150)
broc    = get_nutrition(ingredient="broccoli", grams=100)

total = add_nutrition(a=chicken, b=rice)
total = add_nutrition(a=total, b=broc)

This works for exactly three ingredients. Four ingredients? Different plan. Ten? Different plan. The LLM has to re-plan the entire unrolled sequence for every recipe. And if the task says "for each ingredient in the user's shopping list", there is no fixed N to unroll. PlanExecute cannot express it at all.

DesignExecute: the loop the task actually needs#

python

# DesignExecute: one loop over the ingredient list.
items = [("chicken breast", 200), ("rice", 150), ("broccoli", 100)]
total = zero_nutrition()

for name, grams in items:
    info  = get_nutrition(ingredient=name, grams=grams)
    total = add_nutrition(a=total, b=info)

Same functions. Same result. One plan that works for any number of ingredients. This is the kind of task DesignExecute exists for.

Loops come with one catch: DesignExecute caps every loop at 1,000 iterations, so a runaway while True becomes a clean error instead of a hung agent. You get the trace up to the point of failure and a chance to retry.

What Stays the Same#

DesignExecute is not a different system. It's PlanExecute with permission to use loops and conditionals. Everything that made PlanExecute safe still applies:

The agent can only call functions you gave it
Execution runs in a sandbox (no filesystem, no network)
Every step is traced
Write actions still pause for approval
The planner is still called just once per task

The Comparison#

	PlanExecute	DesignExecute
Shape of a plan	Straight line	Branching and looping
Loops (`for`, `while`)	Rejected	Allowed
Conditionals (`if/else`)	Rejected	Allowed
Best for	Known, fixed workflows	Variable-length or conditional workflows
Debugging difficulty	Trivial (linear)	Moderate (branches, iterations)

When to Choose Which#

Reach for PlanExecute when the workflow is a fixed shape: "search, then summarize, then save." The number of steps is known up front. Straight-line plans are cheaper to generate, impossible to infinite-loop, and trivial to read in a trace.
Reach for DesignExecute when the shape depends on runtime data: "for each item in the cart", "until the result passes validation", "if the document is a PDF, extract text differently." If unrolling by hand would require the planner to guess N, you need control flow.
Reach for neither yet if you're not sure. Write it as PlanExecute first. If a straight-line plan can express the task, you've saved yourself loops you didn't need.

PlanExecute is the default. DesignExecute is the escape hatch. Pick the smallest step up the ladder that does the job.

See the code: OpenSymbolicAI Core | Recipe Book example