Planning and Replanning

Planning turns an objective into steps whose results can be checked. For an agent, the plan must change when an observation contradicts its assumptions.

#Start with dependencies

For a coding task, locate the repository and reproduce the issue before editing. For research, collect sources before writing factual conclusions. Put the hardest dependency to verify near the beginning so a blocked task fails early.

An explicit task record can be simple:

jsonCopy
{
  "objective": "Repair a local document-loading failure",
  "steps": [
    {"id": "reproduce", "state": "done", "evidence": "saved failing response"},
    {"id": "repair", "state": "in_progress", "depends_on": ["reproduce"]},
    {"id": "verify", "state": "pending", "depends_on": ["repair"]}
  ],
  "constraints": ["local only", "preserve existing URLs"],
  "max_attempts_per_step": 2
}

This is illustrative state, not a claim that those operations were executed.

#Choose the lightest reasoning pattern

A fixed workflow is suitable when the steps are known. Hierarchical planning helps split a large objective into smaller deliverables. Exploring several candidate approaches can help when there are genuine alternatives, but adds latency and usage.

Request a concise plan, assumptions and verification criteria. Do not depend on a hidden chain-of-thought transcript as an application interface. Observable actions and results are what the runtime can validate.

#Replan after evidence

If a test fails, record the error, identify which assumption changed and revise the next action. Repeating the same unsuccessful tool call without new information is not progress. Limit retries and distinguish transient failures from missing authorization or unavailable data.

Reflection is useful only when it changes an action or improves a check. A long self-critique does not prove the artifact is correct. Finish with the actual deliverable, its verification result and any unresolved constraint.

Stateful workflows