A plan is a task artifact the application can inspect and update: what should happen, what has completed, what is blocked and what evidence changed the next step. It is not a request to expose a model's hidden chain-of-thought.
Engineering focus: Explicit plans, execution state and evidence-driven replanning
A plan is a task artifact the application can inspect and update: what should happen, what has completed, what is blocked and what evidence changed the next step. It is not a request to expose a model's hidden chain-of-thought.
Framework names come later. First understand what the application is doing and where its control boundaries belong.
Across the course, imagine an assistant that investigates operational problems using narrow tools. The design progressively adds plans, specialist agents, approvals, reliability controls and MCP while keeping model output separate from execution authority.
Store concise steps, dependencies, status and success criteria that the application can inspect. Avoid designs that depend on collecting or displaying a model's private chain-of-thought. The engineering artifact is the plan, not hidden reasoning.
The planner can propose the next safe step, but an executor still validates tool name, arguments, authorization and policy. A good plan does not bypass the execution boundary learned in Module 03.
A plan made before any tool runs is provisional. If the service is healthy but upstream latency is high, the next diagnostic step should change. Replanning should be triggered by new evidence, not by an unbounded urge to keep exploring.
Set maximum steps, tool-call budgets, time limits and explicit completion criteria. A plan that can grow forever is only an infinite loop written as a checklist.
plan = [
{"step": "check_service", "status": "pending"},
{"step": "inspect_recent_logs", "status": "pending"},
{"step": "summarize_evidence", "status": "pending"}
]service = healthy
latency = high
old next step: restart service
new next step: inspect upstream dependencyGoal: Watch a small investigation plan advance, record evidence, and insert a new step only when an observation justifies it.
python3 public/labs/agentic-ai/05_planning_and_execution.pyNotice pending → complete transitions and the evidence attached to each completed step.
A latency observation inserts an upstream dependency check instead of blindly restarting the service.
Production planners should expose concise task state, dependencies and evidence while keeping model-internal reasoning private. Plans are useful because operators and policy engines can inspect them before actions occur.
Open every answer only after committing to your own answer. Opening all four answers records knowledge-check activity in My Learning.
Explicit steps, status, dependencies and evidence — the application needs observable task state, not a model's hidden chain-of-thought.
Replan from the new evidence — the earlier plan is provisional and should not override observed state.
No — planning proposes work; execution still enforces the tool contract, policy and authorization boundary.
To bound cost, latency and runaway loops — a plan must have operational limits and completion criteria.
Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.
Attempt the core lab and knowledge checks before marking the module complete.