Skip to main content

When to use planning

Planning is useful when you know the starting state and the goal, but not the exact sequence of actions in between. You describe what is true now, what you want to be true later, and the actions that can move you between them.

That makes planning a good fit when one step depends on another. A deployment may need a database migration before the rollout. A logistics flow may need loading before transport and unloading after. A repair process may need inspection before the fix and verification after.

Planning is also useful when the same goal can be reached in different ways. If the starting state changes, the right sequence may change too. That is the kind of problem where you want the system to work out the steps for you.

Use planning when the question is "what sequence gets me from here to there?" If the work items are already known and the problem is fitting them into a fixed window, scheduling or constraint programming is usually the better shape.

What planning gives you​

  • an ordered list of actions
  • a way to check whether the goal is reachable from the starting state
  • a way to regenerate the plan when the starting conditions change
  • something you can show to a user, run in code, or hand off to another system

A simple test​

If you can describe the problem as "here is what is true now, here is what I want to be true later, and here are the actions I can use to get there," then planning is probably the right shape.