🧠 Planning & Task Decomposition — AI / ML Interview Guide

Agentic Systems · interactive visualization + interview prep

Open the interactive Planning & Task Decomposition visualization on PrepGrind → Step through a live animation, tune the parameters, and read the full theory, math, reference code, and interview Q&A below — free, in your browser.

What it is

For a complex goal, an agent first DECOMPOSES it into a plan — an ordered list of smaller subtasks — then executes them one by one, often using tools per step. Breaking the goal down makes each step tractable and checkable.

Mental model

A project manager turning a vague goal into a checklist, then ticking items in order — rather than attempting the whole project in one move. Crucially the checklist is a LIVING artifact: when a step's result changes things, you revise the plan instead of pushing through a stale one. "Plan" is a noun you keep editing, not a one-time act.

Theory

For complex goals, decomposing into an ordered list of subtasks beats one-shot prompting because a single generation cannot reliably hold and execute a long, multi-step task. Breaking it down lowers error per step, makes progress inspectable, lets you retry a single failed subtask without redoing everything, and gives each step a clean place to call a tool.

There is a spectrum from PLAN-AND-EXECUTE to ReAct. Plan-and-execute writes the whole plan up front then runs it — efficient and structured, with a plan you can inspect before any action. ReAct decides each step reactively from observations — adaptive but with no global view. Most robust agents are hybrids: plan up front, but RE-PLAN whenever a step's result invalidates the remaining plan.

A plan is better modeled as a DAG than a flat list. Independent subtasks can run in parallel to cut wall-clock time; dependent ones must be ordered, and later steps consume earlier results. Capturing dependencies explicitly is what enables both correctness (right order) and concurrency.

Failure handling is the difference between a demo and a real agent. When a subtask fails you catch it and either retry, or re-plan from the CURRENT state — never blindly continue a plan whose assumptions just broke. Treating the plan as revisable is the core robustness move.

The pitfalls are symmetric: over-planning trivial tasks wastes tokens and latency (not everything needs a plan), while a rigid plan that cannot adapt fails the moment reality diverges. And losing earlier results starves later steps of the context they need — carry state forward deliberately.

Concrete example

Goal: "plan a weekend trip to Paris." The agent makes a plan — book flights, reserve a hotel, build an itinerary, check the weather — then completes each, carrying results forward. One giant prompt would skip steps; an explicit plan keeps it organized and verifiable.

Key equations

• plan = decompose(goal) → [subtask₁, subtask₂, …]
• for each subtask: execute (often via a tool) → record result
• later subtasks can depend on earlier results
• optionally re-plan if a step fails or new info appears

Step by step

1. Goal — the high-level objective enters.
2. Decompose — the agent writes an ordered plan of subtasks.
3. Execute — it completes each subtask in turn, recording the result.
4. Carry forward — later steps use earlier results.
5. Done — all subtasks complete → the goal is achieved.

Interview questions & answers

Why decompose instead of one-shot prompting?

Complex goals exceed what one generation can reliably do: decomposition reduces error per step, makes progress inspectable, lets you retry a single failed subtask, and enables tool use per step.

Plan-and-execute vs ReAct?

Plan-and-execute writes the whole plan up front, then runs it (efficient, structured). ReAct decides each step reactively from observations (adaptive). Hybrids plan, then re-plan when a step’s result invalidates the plan.

How do you handle a subtask that fails?

Catch the failure, optionally retry, or re-plan from the current state. Robust agents treat the plan as revisable, not fixed.

What about subtask dependencies / parallelism?

Independent subtasks can run in parallel; dependent ones must be ordered. A DAG of subtasks (not just a list) captures this and enables concurrency.

Common pitfalls

• Over-planning trivial tasks — wasted tokens and latency.
• A rigid plan that can’t adapt when a step’s result changes things.
• Losing earlier results so later steps lack needed context.

Where it shows up

• Plan-and-execute agents (LangChain, LlamaIndex)
• Coding agents that outline then implement
• Task planners / workflow orchestration

More AI / ML interview concepts

• Neural Networks & Backpropagation
• Gradient Descent & Optimizers
• Activation Functions
• K-Means Clustering
• Self-Attention
• Multi-Head Attention
• Softmax, Temperature & Sampling
• Tokenization (Byte-Pair Encoding)
• Positional Encoding
• KV Cache
• Rotary Position Embedding (RoPE)
• The Transformer Block
• Normalization (LayerNorm / RMSNorm)
• Multi-Query & Grouped-Query Attention
• Flash Attention
• Decoding: Beam Search & Speculative Decoding
• Embeddings & Cosine Similarity
• RAG (Retrieval-Augmented Generation) Pipeline
• Vector Search (HNSW)
• Chunking & Reranking
• ReAct Agent Loop
• Tool / Function Calling
• Multi-Agent Orchestration
• Agent Memory
• Model Context Protocol (MCP)
• Quantization
• LoRA / PEFT Fine-Tuning
• Mixture of Experts (MoE)
• RLHF / DPO Alignment
• Evals & LLM-as-Judge
• Prompt Injection & Guardrails
• Knowledge Distillation

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…