Re-Imagining Planning With Planr: Turning AI Into a Planning System

Most AI planning tools start with a simple idea: tell the AI what you want to accomplish, and let it generate a plan.

That works surprisingly well until you try to build an actual product around it.

A useful plan isn't just a list of tasks generated from a prompt. It requires understanding what someone is trying to accomplish, learning about their circumstances, researching the problem, deciding which parts of a typical approach actually apply to them, determining whether the plan is realistic, and then continuing to make decisions as they move through it.

That's the problem Planr is designed around.

Instead of treating an LLM as a single brain that should handle an entire workflow from beginning to end, Planr uses multiple AI steps, structured application data, research, specialized roadmap patterns, and continuous updates to turn an initial idea into something that can actually be executed.

It starts with the person, not the plan

When someone comes to Planr, they don't necessarily have a perfectly defined goal. They might have a vague idea, an article they found online, a business they want to start, a project they want to build, or something they've been thinking about for months.

The first job, therefore, isn't to generate a roadmap. It's to understand what the person is actually trying to do.

Planr uses an AI conversation to gather the information needed to understand both the goal and the context surrounding it. It asks about things such as available time, commitments, constraints, previous attempts, priorities, and motivation. This information gives the system a much better foundation for deciding what a realistic path might look like.

That context matters because the same goal can require completely different plans depending on who is trying to achieve it. Someone trying to start a business while working full-time and supporting a family needs a different approach from someone who can dedicate their entire day to it. The destination might be identical, but the path doesn't have to be.

The conversation isn't the database

One of the first problems that appears when you try to turn an AI conversation into a real workflow is memory.

An LLM can work with a large amount of conversation history, but that doesn't mean it should be trusted to reliably retrieve every important piece of information from that history. As conversations grow, important details can become buried among other messages, and the model may not consistently prioritize the same information every time.

Planr therefore doesn't treat the conversation itself as the source of truth.

Important information is extracted into structured data and stored separately in the application. Things such as the user's goals, available time, constraints, decisions, and other important pieces of context can exist as actual application data rather than being buried somewhere inside a conversation.

When the AI needs that information, Planr can explicitly provide it.

This creates a much shorter path between the information the model needs and the information it receives. Instead of relying on an LLM to remember that something important was mentioned dozens of messages ago, the application can provide the relevant structured information directly.

This distinction is important to how Planr is built. The AI is responsible for reasoning about information, while the application is responsible for maintaining important state. Keeping those responsibilities separate makes the overall workflow considerably more reliable.

A complex planning problem needs more than one AI call

A roadmap is not something that should be produced by one enormous prompt.

Before a useful roadmap can exist, the system needs to understand the goal, collect personal context, research relevant information, analyze the situation, determine what matters, compare different approaches, and decide how everything should fit together.

Trying to make a single AI call perform all of those jobs creates another problem: context.

As more information enters a conversation, the model has more information to process. The amount and composition of that context can affect how effectively it reasons about what it has been given. An LLM might perform very well at one point in a long workflow and less reliably later, even though the overall goal hasn't changed.

Rather than asking one model invocation to carry the entire process, Planr divides the internal planning process into multiple stages. Each stage has a specific responsibility and receives the relevant information produced by the stages before it.

The process involves several kinds of work, including understanding the goal, understanding the person, researching the problem, analyzing the situation, determining an appropriate roadmap structure, personalizing that structure, evaluating its achievability, and finally producing the structured roadmap.

This doesn't make the LLM deterministic. It does something more practical: it keeps each individual reasoning problem within a context that is appropriate for that problem and gives each stage the information it actually needs.

Personalization goes deeper than changing a few words

A common approach to AI personalization is to take a generic response and add the user's name, situation, or a few pieces of personal information.

That's not particularly useful for planning.

If two people want to build the same type of business, they can still need completely different roadmaps because they have different amounts of time, different levels of experience, different resources, and different constraints.

Planr therefore uses personalization before the roadmap is finalized. The information gathered during the preparation process influences the actual structure of the roadmap, rather than simply changing the wording of an otherwise generic plan.

For example, someone with only five hours a week available may need a different sequence of milestones from someone with twenty hours. Someone who has already attempted the goal several times may need an initial milestone focused on fixing a known weakness rather than repeating the standard starting steps.

The point is not to take a generic roadmap and make it sound personal. The point is to determine what the roadmap should actually look like given the person who will be executing it.

AI is probabilistic, so the roadmap needs some structure around it

There is another problem that becomes important when using an LLM to generate structured plans: the same requirements can produce slightly different roadmaps.

That's a natural property of probabilistic models. For a conversation, variation is often desirable. For a roadmap, too much variation can be problematic.

If someone wants to start a SaaS business, there are certain broad stages that will usually be relevant regardless of who is asking. The exact implementation should be personalized, but the underlying milestone structure shouldn't randomly change every time the roadmap is generated.

To address this, Planr uses specialized roadmap patterns alongside the model's reasoning.

These roadmap presets are embedded and used as a form of retrieval. When the system understands the user's context, it can identify relevant patterns and use them as a structural reference when constructing the roadmap. The LLM still handles the personalization and reasoning, but it isn't starting with a completely blank page every time.

This creates an important balance. The roadmap retains the flexibility of an AI-generated plan while being guided toward a more consistent underlying structure.

There is also a generic fallback for cases where a specialized roadmap isn't available. The purpose isn't to remove the probabilistic nature of the model, but to give that probability useful boundaries.

This is one of the broader lessons behind Planr: you don't necessarily need to make an LLM deterministic to make its output more consistent. You can design the system around it so that its probabilistic behavior is constrained by structured information, retrieval, and predefined patterns where consistency matters.

Research needs current information

A planning system can also run into a much simpler limitation: an LLM's knowledge is not necessarily current.

That matters whenever the plan depends on information that changes over time. Regulations, pricing, available services, tools, market information, technical documentation, and other external facts can all change after a model's training data was created.

For those situations, Planr can use web search to ground its research in current information instead of relying exclusively on what the model already knows.

This research can then become part of the structured planning process, rather than being treated as an isolated answer that disappears once the conversation moves on.

The preparation phase and execution phase are connected

Creating a roadmap and helping someone execute it are two different problems.

During preparation, Planr may have gathered a significant amount of information about the person's circumstances and made a number of decisions about what the plan should look like. When execution begins, simply starting a new AI conversation would risk losing that context.

Planr handles this by reinitializing the same system behavior for the execution phase and injecting the live roadmap state along with the important answers and decisions collected during preparation.

This means the execution experience doesn't really start from zero. The AI receives the information it needs to understand who the person is, what they're trying to accomplish, why the roadmap looks the way it does, and what has already happened.

The result is a more continuous experience between planning and execution, even though the internal AI calls are separate.

A roadmap can't remain frozen while life changes

Even a well-designed roadmap can become outdated.

A plan created today is based on the information available today. Two months later, circumstances may be completely different. The user's available time may have changed, a milestone may have taken longer than expected, new information may have been discovered, or an external dependency may no longer exist.

An LLM's original output is static unless something causes it to be reconsidered.

Planr therefore treats the roadmap as something that can be updated rather than something that is generated once and then frozen.

When the user provides new information, or when relevant information is discovered through research, the plan can be updated around the new reality. The goal is to preserve the overall direction while changing the parts that no longer make sense.

This is an important difference between a generated plan and a planning system. A generated plan answers the question, "What should I do based on what I know right now?" A planning system also needs to answer, "Given what has happened since then, what should I do now?"

Achievability isn't a permanent number

The same principle applies to Planr's achievability analysis.

A plan can look achievable when it is created and become much harder later. It can also look difficult at first and become easier as the person makes progress, develops skills, resolves constraints, or completes important milestones.

For that reason, the initial achievability analysis isn't treated as a permanent verdict.

After completing milestones, the user can refresh the analysis and receive an updated assessment based on the current state of the plan and the progress that has actually been made. The estimated completion timeframe can change, weaknesses can become strengths, and new risks can appear.

This makes the analysis useful as a moving picture of the plan rather than a one-time score generated before execution begins.

The AI is not the source of truth

There is a broader principle behind all of these decisions.

LLMs are powerful, but their output shouldn't automatically be treated as truth simply because it sounds convincing.

For a product like Planr, that matters even more because the output isn't just a paragraph of text. It can determine what someone spends their time doing for weeks or months.

That's why important information in Planr is represented as structured application data wherever possible. The user's plan, milestones, tasks, decisions, analysis, and other important information aren't supposed to exist only inside an LLM's context.

The model can reason about that information, transform it, research around it, and help the user interact with it, but the application maintains the underlying state.

This also makes it possible to introduce multiple points where the user can review, adjust, or influence the process rather than blindly accepting whatever the model produces.

The result is not an attempt to eliminate the uncertainty inherent in AI. It is an attempt to build a useful product despite that uncertainty.

From an idea to an ongoing planning system

Taken together, these pieces change what Planr actually is.

It isn't simply a chatbot that generates a roadmap from a prompt. It isn't a static project-management template with an AI layer on top. And it isn't trying to replace the person making the decisions.

Instead, it is a system that uses AI for the parts where reasoning and adaptation are useful, while using structured application data, retrieval, research, and explicit workflow stages to provide consistency and continuity.

The process starts with an idea and gradually builds the context needed to understand it. That context is used to research, analyze, personalize, and construct a roadmap. The roadmap then becomes the basis for execution, while the information produced during execution can feed back into the plan and change what happens next.

The result is a loop rather than a single generation:

Understand → Plan → Execute → Learn → Adapt → Continue.

That loop is what makes Planr different from simply asking an AI, "How do I do this?"

See Planr in action

The easiest way to understand the difference is to see the entire process happen.

The demo below shows Planr starting with a real goal, gathering the information needed to understand it, personalizing the approach, analyzing its achievability, generating the roadmap, and then turning that roadmap into something that can actually be executed and adapted over time.

Watch the video

If you want to try the workflow yourself, you can get started at myplanr.co.