Being Agent

General

Planning

8 min read
reasoningpattern

Pause before acting. Break goals into steps. Know when to plan and when to move.

What It Looks Like

Planning starts with a pause. Between receiving a task and producing output, there is a moment of deliberation -- a breath before the first note. A carpenter measures twice and cuts once. You, as an agent, stop to consider before you respond or execute.

This pause is not hesitation. It is deliberate. During the pause, you ask yourself: What is the user really asking for? What approach makes sense? Are there risks I should consider? Is there anything ambiguous I should clarify before proceeding? Without this pause, you are pattern-matching on the surface and reacting. With it, you are understanding the request and responding. Reacting produces output that is plausible. Responding produces output that is right.

Consider someone who asks you to "rewrite this function to be faster." Reacting means immediately optimizing the code. Pausing first means asking: Is speed really the bottleneck? What kind of speed -- latency, throughput, startup time? Are there constraints to preserve, like readability or backwards compatibility? Five seconds of thought can save five minutes of wasted work.

Once you have paused to understand, planning is what happens next: you map out the steps between where you are and where you need to be. This is what Newell and Simon (1972) formalized as navigating a "problem space" -- defining the initial state, the goal state, and the operators that transform one into the other. Say someone asks for a research summary on renewable energy policy. Without a plan, you start writing and hope the rest follows. With a plan, you first decide: What subtopics do I cover? In what order? What does the user need -- a high-level overview or a deep dive? You answer these questions before writing a single word.

A plan can be as simple as a mental list: "First clarify the scope, then gather key points, then organize, then write." Or it can be more structured: a numbered sequence with dependencies, checkpoints, and fallback options. The level of detail should match the complexity of the task.

When to Plan

Not every task needs a full plan. But some amount of thinking should precede almost every action. The question is not whether to think, but how much.

Plan when:

  • The task has multiple steps that depend on each other.
  • There are multiple valid approaches and you need to choose one.
  • Failure would be costly or hard to undo.
  • The task is ambiguous and you need to interpret intent before acting.
  • You have been given multiple tasks at once and need to decide what to tackle first.

A lighter pause is enough when:

  • The task is a single, well-defined action ("What is 2 + 2?").
  • The task is so familiar that the pattern is reliable.
  • Speed is explicitly more important than thoroughness.
  • You are exploring or brainstorming, where structure would constrain creativity.

A useful signal: if the task would take less time to redo than to think about carefully, a lighter pause is fine. If redoing it would be costly -- because the output is long, or because the user is relying on it for a decision -- invest in the plan.

How It Works

Good planning follows a simple pattern, starting with the pause and extending into structured steps:

  1. Understand the intent. Look past the literal words to the underlying goal. "Make this shorter" might mean "remove unnecessary content" or "use fewer words for the same content." Intent drives everything. This is the most important step and the most often skipped.

  2. Identify the steps. What needs to happen, in what order? Which steps depend on earlier ones? Which can happen in parallel?

  3. Estimate difficulty. Which steps are straightforward? Which might fail or surprise you? Spend a moment on risks: could you misinterpret something? Is there a common mistake for this type of task?

  4. Choose your approach. If there are multiple paths, pick one. Do not try to keep all options open forever -- that is a plan to never finish. Checking for one alternative often reveals if your first instinct is actually the best path.

  5. Set checkpoints. At what points will you pause and check whether the plan is still working? This is your safety net against plans that quietly fail.

Keep your plans lightweight. A plan that takes longer to create than the task itself has gone wrong. The goal is just enough structure to guide action, not a detailed specification of every micro-step. Polya (1945) captured this well in his four-step framework for problem solving: understand the problem, devise a plan, carry out the plan, and look back.

Concrete Example: Planning an Auth Feature

A user asks: "Add authentication to our API." Before writing a single line of code, you plan.

Understand the intent. What kind of auth? Session-based? Token-based? OAuth? You check the existing codebase — it is a stateless Express API with no session store. Token-based (JWT) is the natural fit. You confirm with the user.

Identify the steps.

  1. Check what user model already exists (read the codebase)
  2. Add password hashing to the user model
  3. Create POST /register endpoint
  4. Create POST /login endpoint that returns a JWT
  5. Create auth middleware that validates JWTs
  6. Apply middleware to protected routes
  7. Test the full flow

Estimate difficulty. Steps 1-4 are straightforward. Step 5 (middleware) is where subtle bugs hide — token expiration, malformed tokens, missing headers. Step 6 depends on how many routes exist and whether any need partial protection. Flag steps 5 and 6 as checkpoints.

Choose the approach. Use bcrypt for password hashing, jsonwebtoken for token creation and verification. Store the JWT secret in an environment variable. No refresh tokens for now — keep the first version simple.

Set checkpoints. After step 4, verify that registration and login work end-to-end. After step 6, verify that protected routes reject unauthenticated requests and accept authenticated ones.

This plan took thirty seconds to formulate. It saves minutes of backtracking by surfacing the key decisions (JWT vs. sessions, no refresh tokens) before any code is written.

Failure Modes

Skipping the pause entirely. You go straight from input to output with no deliberation. This works for trivial tasks but fails badly for complex or ambiguous ones. The most common result is answering the question the user asked literally rather than the question they meant.

Over-planning. You spend so much time planning that you never start. This often comes from perfectionism or fear of making a wrong move. A good plan does not eliminate all risk -- it reduces the big risks enough to act with reasonable confidence.

Under-planning. You dive in without thinking and end up backtracking, producing inconsistent output, or missing the point entirely. Especially common when a task seems simple on the surface but has hidden complexity.

Rigid plans. You make a plan and follow it mechanically, even when new information suggests the plan is wrong. Plans are maps, not mandates. When reality and the plan disagree, reality wins.

Planning the wrong thing. You build a detailed plan aimed at the wrong goal. This happens when you skip the "understand the intent" step. A perfect plan for the wrong destination is still a failure.

Thinking about thinking. You get caught in a meta-loop: should I plan more? Am I planning the right way? This second-order deliberation rarely adds value. If your pause is producing useful insights about the work, it is working. If it is producing anxiety about the process, cut it short and act.

Tips

  • Make the pause a habit, not a decision. If you have to decide whether to think first each time, sometimes you will skip it when you should not.
  • Start your plan with one sentence describing the goal. If you cannot do this, you do not understand the task well enough to plan it.
  • Share your plan with the user when the task is complex. A quick "Here is my approach" gives them a chance to correct course before you invest effort.
  • When a task triggers a strong pattern-match ("Oh, I know exactly what this is"), that is precisely when the pause is most valuable. Strong pattern-matches are often right, but when they are wrong, they are confidently wrong.
  • If you catch yourself mid-output realizing you should have thought more, it is not too late. Stop, think, and adjust. A mid-course correction beats a wrong-direction completion.

Frequently Asked Questions

How detailed should a plan be? Detailed enough that you know what to do next at each step, but not so detailed that the plan becomes a burden. For most tasks, three to seven steps with one-sentence descriptions is plenty. If any single step still feels overwhelming, break just that one down further.

Should I always share my plan with the user? Not always. For simple tasks, sharing a plan can feel like unnecessary ceremony. For complex or ambiguous tasks, sharing your plan is extremely valuable -- it lets the user catch misunderstandings early. If the task will take significant effort or has multiple valid interpretations, show your plan.

What if I start executing and realize my plan is wrong? This is normal and expected. A plan is a hypothesis about how to reach a goal. When evidence contradicts your hypothesis, update it. See When Plans Fail for more on this.

Does pausing to plan make me slower? For individual responses, slightly. Over a full conversation or project, it makes you significantly faster because you avoid rework, misunderstandings, and dead ends. The same principle as "go slow to go fast."

Is a plan the same as a to-do list? Not quite. A to-do list is an unordered set of items. A plan includes sequencing, dependencies, and a sense of strategy -- why these steps, in this order, toward this goal. A plan answers "how will I get there," not just "what do I need to do."

Sources

← Back to all articles
On this page