Day 3
Goals and Task Breakdown
Learn how agents decompose user goals into actionable steps.
Goal decomposition is how an agent transforms a vague user request into a structured plan. Instead of attempting the entire goal in one action, the agent breaks it into smaller sub-tasks, executes them in order, and adapts as it learns from intermediate results.
Today’s Lesson
Read
Agent Loop
Bounded ReAct and reflection loops that stop cleanly.
Practice
Apply what you learned by solving these coding problems.
Review
Test yourself with these interview-style questions.
1Describe how you would break down a high-level user request into a structured plan for an agent to execute. Walk through the validation checks you would run on the plan before execution begins. Use "Write a quarterly business report for Q4 2025 using company data" as your example.+
Goal decomposition transforms a request into sub-tasks with dependencies forming a DAG. For the quarterly report, sub-tasks include: fetch revenue data (no deps), fetch expense data (no deps), calculate profit (depends on both), generate report (depends on profit). Validation checks: every dependency ID must reference an existing task (no dangling refs), the graph must be acyclic (cycle detection), and each task must have a clear objective. The plan should also map each task to an available tool via a hint field for the execution engine.
Read full answer
The decomposition workflow starts with identifying independent data-fetch operations and then ordering dependent computations. For the quarterly report example, I identify that revenue and expense data are independent and can be fetched in parallel, while profit calculation depends on both, and report generation depends on profit. The resulting DAG maximises parallelism while respecting data flow. Before execution, I validate the plan through three checks: dependency validation (every ID in a task's depends_on list must exist as another task's ID — no dangling references), cycle detection (traverse the graph looking for cycles that would cause deadlock), and objective clarity (each task must have a non-empty description and tool_hint). If validation fails, I reject the plan and re-generate with specific error feedback. The tool_hint field is critical — it tells the execution engine which tool to use for each step, bridging planning and execution. Without it, the engine would need to re-analyse each task at runtime to select a tool.
2Compare static planning (all steps upfront) with dynamic planning (re-plan after each step) for a multi-city business trip agent. What are the trade-offs in correctness, latency, and cost? When do you prefer each?+
Static planning generates the full itinerary upfront — fast and cheap but brittle if a flight is cancelled. Dynamic planning regenerates after each step — robust to changes but more LLM calls and latency. For trip planning, static works with fixed dates; dynamic is needed when adapting to real-time availability. A hybrid approach: generate a static skeleton and re-plan only the affected sub-tree on failure.
Read full answer
Static planning generates the entire DAG upfront in one LLM call — it is fast, cheap, and produces a reviewable plan. However, it fails when reality diverges, like a cancelled flight invalidating the itinerary. Dynamic planning executes one step, observes the result, then generates the next step — more robust because each decision uses current information, but costs more calls and adds latency. For a multi-city trip, I use a hybrid: a static skeleton plan with breakpoints at each city transition, then dynamic re-planning within each city based on real-time availability. The skeleton serves as a user communication tool — they approve the high-level route before the agent starts booking.
3Design a task-planning system for a 50-step data-processing pipeline with branching and error recovery. Describe the plan data structures, execution engine, and failure handling.+
The plan is represented as a DAG where each node has id, description, tool_hint, status (pending/running/succeeded/failed/skipped), and dependency IDs. The execution engine uses topological sort, processing ready tasks in parallel via a thread pool. On failure: retryable errors trigger backoff retry; non-recoverable errors mark downstream tasks as skipped and return partial results. Checkpoints persist completed outputs so re-execution resumes from the last successful step.
Read full answer
The DAG-based planning system has three components. The plan graph stores nodes with id, description, tool_hint, status enum, retry_count, max_retries, and dependency_ids. The graph is validated for cycles and dangling references on creation. The execution engine maintains a ready queue of tasks with all dependencies satisfied, processed via a thread pool. When a task completes successfully, downstream tasks with all dependencies met join the ready queue. For error recovery, I classify failures into three categories: transient (network errors) trigger exponential backoff retries up to max_retries; data errors (unexpected output format) trigger re-prompting the LLM to adjust; hard failures (permanent tool unavailability) mark the task as failed and cascade: all downstream tasks become skipped. The final output includes partial results listing which steps succeeded and which were skipped, so the user has full visibility.
Back to 30-Day Agentic AI Interview Prep Path