💻Video + Code Examples·10 mins

Planning Workflows with Prompts and Plan Agents

Nilay Parikh

Separate planning from implementation using prompt files for repeatable workflows and read-only planning agents that decompose tasks, surface ambiguity, and produce actionable implementation plans.

Thumbnail for Planning Workflows with Prompts and Plan Agents — Planning Workflows with Prompts and Plan Agents · 10 mins

Transcript11 entries

Instructor:Welcome to Lesson 4: Planning Workflows. You've got the context layer and instruction architecture in place. Now let's add the planning phase. This step prevents the biggest failures. If you want the practical part first, use the YouTube chapter links to jump ahead. But I would recommend following in order. Vibe coding relies on rapid conversation and iteration. The AI makes implicit assumptions to maintain momentum. This code-first approach creates an illusion of success, and then the system fails under the rework load, brittle architecture, invisible tech debt, and catastrophic failure. They all come without warning. Planning is the antidote. It transforms AI from an unpredictable system into a reliable executor. There are four reasons why every workflow needs a planning phase first. First, mitigating guesswork and restraining hallucinations. Without a plan, AI handles ambiguity by guessing. A planning phase

Instructor:forces the assistant to clarify requirements and identify edge cases before they become holes in the code. Second, preventing architectural drift. AI optimizes for immediate task completion. It generates code that works in isolation, but conflicts with your system's broader patterns. Planning ensures it respects established blueprints. Third, optimizing the context window. Context is finite. Planning lets you create a high-signal set of facts, and rules instead of flooding the AI with blocks of irrelevant detail. Fourth, safety and control. Read-only plan modes, like Claude Code's Plan Mode or data compilers, let planning agents restrict the AI to read-only operations. You review proposed changes before anything touches your codebase. This example, which we will look at in a moment, is not trying to show generic decomposition. It is showing planning capability. The output has to be a structured plan.

Instructor:That cites sources, surfaces open questions, and separates confirmed requirements from the planner's own decisions. Yes, LLMs do have opinions, and they can quietly and quite successfully embed them into responses. It's very hard to identify them with the naked eye. Now let's walk into Visual Studio Code and understand the example itself. We are in the codebase now, and let's first run this. What we've got... let's remove the previous plan it created, and let's run it again. So we have a planning agent, and it has a limited set of rules. Always ensure the planning agent does not have any edit capability, just to keep the scope safe. And then it has graph context that explains which docs and specs it should walk through. It has a prompt that will do the planning.

Instructor:It uses the planner mode, and it provides other references for what it should do and the output format. Then what we are expecting is the output file, the notification preferences plan, and we validate against important and nuanced details such as LEGAL-218 requirements, mandatory events, positive and negative cases, and exception criteria. These are the documents that will be provided as context for the planning agent. Bug report, feature request, non-functional requirements, and product spec references. The most important piece is the planning workflow example that helps it actually build a good prompt, or you can say a template, for the planner agent to generate a new plan. I have managed to run this example before, and this is what the run looks like. But we will try it again once we complete this, so the thinking process looks like this.

Instructor:It goes through each and every part in multiple phases, as we described in the planning agent and planning workflow. That helps it systematically discover the context and slowly produce a final output. Each step that we mention here as stage one, stage two, and stage three was defined as a part of the workflow. In the example, the planner agent is actually discovering the set of files, and then it keeps crawling, keeps crawling as much as needed and finally discovers everything that it requires and then produces a plan as the final output. This is very important. In enterprises, the overall code structure and documentation can be significantly larger, and when we flood that much information into context in one shot, the plan also suffers.

Instructor:So it is very important that discovery of context or information happens in a structured way. That means it starts from the top, identifies the higher-level objects, and from those higher-level nodes it starts propagating exploration toward downstream nodes and downstream edges. Eventually it ends with enough documentation to act. So in our case, there are more than 250 documents in this particular example. It then enters the source files to actually evaluate them. But when we see the final generation, it will not identify all of those. It discovered only the five it needed for the plan. It documented the sources, produced one plan, and did the required verification. So this is the efficiency we need. The planner must rely on good context management and context engineering. Context engineering remains the base for all of this.

Instructor:Now here it might say it did not explore everything before the plan, and that's fine. The core logic has been found, and we still got our planning artifact. So let's refresh the document. The notification plan has been generated successfully. You can see it here. It has properly generated the plan, and we can see the functional requirements have been properly identified. Special conditions have been identified. It identified all the NFRs and architectural patterns. It also found open questions for us, which we would like to resolve. And it also identified the inferred implementation choices. These are the choices recommended by LLMs. But by using our flow in multiple phases, we identified that these are not correlated with any of the requirements we asked for. And that's why they're called inferred implementation choices. It is up to us, after the planning phase, whether we want to adopt any of those recommendations.

Instructor:In a good design outcome, predicted constraints and special conditions are also identified. Acceptance criteria and everything else are also available there. And the planning tasks are there as well. This is a perfect example of how the plan should exist and generically cover everything that you need to execute, including constraints and monitoring. We can see the risks and dependencies. It has identified everything that we need from a legal perspective. Summary of confirmed, open, and inferred items is what we see here. Canonical source justification, every primary authority identified, and a glossary and appendix are provided. This is a strong example. There is very little chance to go wrong with this. All we need to do is manually evaluate the proposed plan and then go ahead. That's all we need to do in this circumstance. Now let's go back to the presentation and understand how it actually worked. So we are back on the presentation now. The session actually begins by invoking the planning trigger.

Instructor:That was the top of our graph node. With the read-only planner agent, we prevent premature code operations and make the first step discovery. The planner spent three minutes and forty-one seconds reading, and only sixteen seconds writing. It covered about fifty files across the roles and layers we talked about. We already saw the list of them. Instead of a generic checklist, the run produced a finite planning artifact. It had confirmed, open, inferred, constraints, and everything we expected. Clarification became part of the workflow. We got false positives, hard negatives, and everything that we need. The conclusion isn't just "ask questions." A useful planning workflow produces a traceable plan, separates confirmed facts from guesses, and exposes uncertainty before code exists. Confirmed requirements must be source-backed, with systems like FRs, ADRs, and NFRs

Instructor:identified instead of paraphrased vaguely. Open questions stay visible and expose ambiguity before implementation locks in assumptions. Inferred choices are separated. Do not blur the project requirements with the planner's own proposals. As we say, "LLMs have opinions." Validation is a part of the plan. Acceptance criteria and risks belong in the artifact, not in someone's head. And the key insight is this: the cost of a clarification question is seconds here, but the cost of a wrong architectural assumption is rework across the entire implementation phase. Planning is where the cost is avoided. A quick tip: I would always recommend creating a planning prompt that includes an agent as well. It will help you make consistent plans. Next, Lesson 5 covers implementation workflows: custom agents, skills, TDD, and handoffs. That wraps up Lesson 4: Planning Workflows.

Instructor:Now I want to hear from you: what's your go-to technique for preventing an AI agent from editing code during the planning phase? Do you use read-only agents, restricted tool names, or something else entirely? Share your answer in the comments below. We are selecting the best responses to join us in an upcoming live session. It's a great place to share real-life experiences. Hit subscribe and turn on notifications so the lesson reaches your timeline the moment it drops. Thanks for watching, and I'll see you in Lesson 5.

Learning Objectives4

Explain why AI-assisted planning should be separated from implementation work
Use prompt files to standardize recurring planning activities
Describe how read-only planning agents improve decomposition and clarification
Design a planning workflow that turns vague requests into actionable implementation tasks

Setup Instructions

0/3

Clone the repository

Clone the course repository to your local machine to follow along with the code examples.

bash

git clone https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/04-planning-workflows
cd $(basename https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/04-planning-workflows)

Create a virtual environment

Create an isolated Python environment for the project dependencies.

bash

python -m venv .venv
source .venv/bin/activate  # or .venv\Scripts\activate on Windows

Install dependencies

Install all required packages from the requirements file.

bash

pip install -r requirements.txt

nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/04-planning-workflowsGitHub

Complete source code for this lesson.

github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/ctx-sdlc/ghctx-tut/lessons/04-planning-workflows

Q&A

Q & A

Why not let the implementer do the planning too?

Because planning and implementation require different behaviors. A planner should explore, question, and decompose. An implementer should execute against an agreed plan.

What is the value of clarification loops?

They force vague requests to become explicit before code changes begin, which reduces rework and avoids hidden assumptions in the implementation phase.

What should every good planning output include?

A summary, open questions, concrete tasks, dependencies, risks, and validation steps. Planning is only useful if it becomes actionable.