Plans and Subgoals

Goal

Use plans as revisable structures that break a goal into checkable subgoals, while keeping observations and policy constraints able to change the plan.

Longer tasks are easier to manage when the agent can name smaller pieces of work. A subgoal is one useful intermediate outcome that helps move toward the larger goal.

For “resolve order 4172,” possible subgoals might be:

1. learn the current order status
2. determine whether a refund is allowed
3. obtain approval if a refund is needed
4. execute one permitted resolution
5. report the result

This list is a plan. It is not a promise that all five steps will happen.

A plan is proposed structure

Suppose the first lookup shows the order is still shipping. The refund-related subgoals may no longer be appropriate. The agent should revise or skip them instead of blindly following the original list.

That is the key boundary: a plan organizes reasoning, but observations remain allowed to change it.

Treating a generated plan as an unquestionable script creates a new failure mode. The model may have planned from incomplete information, or a later tool result may make part of the plan unnecessary.

Make subgoals observable

A useful subgoal should have a state you can inspect, such as:

pending
active
completed
blocked
skipped

“Handle the order somehow” is too vague. “Determine refund eligibility from trusted order and policy data” is more useful because the application can tell whether the required evidence exists.

Observable subgoal states also make debugging easier. If the run failed, you can ask which subgoal was active and what evidence was missing.

Plans should not grant permission

A plan line such as “issue refund” does not authorize the refund.

The action still passes through the same permission and approval checks from Level 10. This matters because planning often happens before all trusted facts are known.

Keep policy outside the plan. The plan can say that approval must be obtained, but the application should independently enforce that requirement.

Replanning needs a reason

An agent that rewrites its plan after every small observation can spend more effort reorganizing than solving the task. Replanning should be tied to evidence.

Useful reasons include:

• a subgoal is completed;
• a required assumption became false;
• a new blocker appeared;
• a tool or permission is unavailable;
• the expected path is no longer the shortest safe route.

Record the reason for meaningful plan changes. That gives the evaluator evidence that the change responded to the environment rather than random drift.

Keep the plan small enough to inspect

Very detailed plans can create fake certainty. For many tasks, three to seven meaningful subgoals are easier to review than dozens of tiny generated steps.

The right level of detail depends on the task. The principle is that each subgoal should represent a meaningful progress point, not every token-level decision.

Predict

A plan says to request a refund, but a new order lookup shows the package is still in transit and refunds are not yet allowed. What should happen?

Revise or skip the refund subgoal because new trusted evidence changed the situationFollow the original refund step because plans should stay fixed once generatedDelete the new observation so the original plan remains internally consistent

Run the local Lab

Run:

python labs/notebooks/level-11/l11-04-plans-and-subgoals.py

The script starts with a three-subgoal plan and applies two observations.

1. Run it unchanged. After eligible=False, the eligibility subgoal is complete and the approval subgoal is skipped.
2. In the second observation, find {"eligible": False}. Before editing, predict which subgoal state should change if the trusted evidence instead says the order is eligible.
3. Change only False to True, then rerun.
4. Confirm the approval subgoal remains pending instead of becoming skipped. The plan changed because evidence changed; this still does not itself authorize a refund.

Loading lab…

Quick Check

1. What is the safest way to treat a model-generated plan?

As a revisable proposal that new evidence can changeAs a binding authorization record for every later action in the trajectoryAs a replacement for keeping explicit state because the plan already describes the future

2. Why give subgoals explicit states such as pending, completed, or blocked?

To make progress and blockers inspectable rather than hidden in proseSo the first plan is guaranteed to have the best order of stepsSo each subgoal gets exactly one separate model call

3. What should authorize a side-effect action that appears in a plan?

The same trusted permission and approval checks used for any side effectProgress, since completing earlier steps earns more authorityThe plan, because the step was written into it earlier

0 of 3 questions answered.

Explain it back

Write a three-step plan for a task you know. Then invent one new observation that makes the second step unnecessary. Explain which subgoal state changes and why the third step may also need to be revised.

Key Takeaways

• Plans break a larger goal into inspectable subgoals.
• A plan is proposed structure, not a promise or permission grant.
• Trusted observations can complete, block, skip, or replace subgoals.
• Replanning should respond to evidence rather than happen constantly.
• Small meaningful subgoals are easier to evaluate than long speculative scripts.

Next Lesson

Next, store the facts, counters, and current subgoal that the loop needs right now without turning the entire transcript into working state.

References

• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models.