Dynamic Planner: AI that turns a complex request into a step-by-step plan

Most conversations don't need a plan. Someone asking your agent a price, an opening hour or a single how-to question should get a direct answer, not a project. But some conversations are different: the user is trying to get a whole thing done — register a company, apply for a visa, resolve a damaged-furniture claim — and they are visibly unsure where to start. The Dynamic Planner exists for exactly that moment: it turns that one conversation into a temporary storyline (a nested, checklist-driven plan) that the agent then walks step by step.

It is a Pro capability, switchable per tenant. The model that does the planning is assigned per tenant by the platform operator rather than chosen inside the conversation, which is what makes it possible to point a tenant with data-residency constraints at a local or regional model and leave everyone else on a hosted one.

When does a plan get triggered?

Never by the model "deciding on its own", and never by an open text box that lets users order arbitrary plans. There are exactly three ways in, in decreasing order of determinism:

1. An expandable storyline step. The tenant marks a step of an authored storyline as expandable. When a user reaches it, the agent offers to expand that step into a sub-plan. The author already made the judgment call at design time; nothing is left to chance.
2. The user accepts an offer. Every plan starts with a confirmation card (the same ask-form UI used everywhere else). The user can always decline, and the agent will not ask again in that session.
3. The escalation judge. Outside storylines, a small dedicated model call watches each turn and scores it on three dimensions — described below. Only when all three pass does the user even see the offer. The main chat model is never trusted to remember to trigger anything; the judge is a forced, structured call made by the engine.

A storyline the tenant authored always takes priority: while one is driving the conversation, the planner stays silent. Hand-built process beats generated process.

The three-dimension escalation test

The judge evaluates task complexity, user confusion, and domain fit — and all three must hold. This is the heart of the feature, so here is the actual logic with examples.

1. Complexity — is this genuinely multi-step? The task should need several steps, several documents or several turns to complete. One question is not a plan.

• ✅ "I want to set up a US company for e-commerce and I have no idea what that involves"
• ❌ "How much does Delaware registration cost?" — a price check, answer it directly
• ❌ "How do I fill line 7b on form SS-4?" — one concrete step of a process the user already runs

2. Confusion — does the user want to be walked through it? Signals: "where do I even start", "what do I need to prepare", "walk me through the whole thing", "I can't keep track of all this". A user who knows the process and asks about one link in the chain is not confused — give them the link, not a plan.

• ✅ "My boss asked me to set up the US subsidiary and I've never done anything like this"
• ✅ "Registration is done — what comes after? Annual filings? Tax? I can't keep it straight, I'd rather you keep track for me"
• ❌ "My documents are ready, just tell me where to submit" — informed, not confused

3. Domain fit — is it the agent's job? A user saying the word "plan" does not open the gate. Tenants pay per conversation; an agent for company formation refuses to become a general personal assistant, however politely the request is phrased.

• ❌ "Make me a three-month fitness plan, detailed by week" — out of domain, decline
• ❌ "Plan a ten-day Europe trip step by step" — out of domain, decline

The generated plan itself is also domain-constrained: the planner receives the agent's remit and must keep every step inside it.

What happens after "yes"

Planning is the only probabilistic moment, and it happens once: a planner model drafts the plan as structured data — steps, per-step instructions, a checklist of what to collect, a completion criterion. The draft is validated like any storyline graph (malformed plans are retried, then handed to a fallback model; a plan that never validates simply never runs). A standing boundary template is stamped into every step deterministically — contradictions must be challenged, nothing outside the step's list may be recommended, no approval or pricing promises — so the guardrails never depend on the planning model remembering to write them.

From there, execution is the storyline engine doing what it always does: one focused step per turn, checklist items ticked only when there is evidence, progress shown in the banner, a thin progress bar, and a step list the engine renders — so what you see is the actual state, not the model's recollection of it. Plans run nested: if a storyline step expanded into a plan, the parent storyline resumes exactly where it left off when the plan completes.