When Plans Talk Back: Conversational AI Meets Classical Planning

Schedule three people, one car, two children, five afternoon activities, and several goals that quietly hate each other. Then ask a normal person to find the best plan.

That is already a planning problem.

Now ask the same person to understand why a plan failed, which goals caused the failure, what could be added without breaking the plan, and what must be sacrificed if one more constraint is enforced.

That is no longer just planning. That is negotiation with a machine that speaks in conflicts, corrections, and formal goal properties. Charming, in the way airport delay codes are charming.

The paper Exploring Plan Space through Conversation: An Agentic Framework for LLM-Mediated Explanations in Planning studies exactly this gap.¹ Its argument is not that large language models should replace classical planners. The authors are unusually explicit about the opposite: LLMs are not reliable enough to perform complex planning on their own. Their role is more modest and, for business systems, more interesting.

The LLM is not the planner.

The LLM is the conversational tissue around the planner.

That distinction is the whole article.

The useful boundary: planners compute, LLMs mediate

The easiest way to misunderstand this paper is to read it as another “LLM agents solve planning” story. It is not. The architecture is deliberately conservative. Formal planning and formal explanation remain the source of truth. LLM agents sit around that core and perform the language-heavy jobs humans actually need: suggesting questions, translating questions into formal queries, translating new goal descriptions, and turning formal conflict explanations back into readable answers.

The paper’s mechanism can be summarized as a division of labor:

This is a more serious product pattern than “add a chatbot to your planning software.” The chatbot is not being asked to hallucinate operational advice. It is being constrained to translate between a human user and a formal system that already knows which combinations of goals are possible.

In business terms, this is the difference between an AI assistant that says, “I think this schedule might work,” and a planning interface that says, “Here is the specific conflict set that prevents this schedule, and here is the minimal set of goals you would need to relax.”

One is vibes with a calendar.

The other is decision support.

The paper starts from plan-space explanation, not generic chat

The technical center of the paper is goal-conflict explanation. In oversubscription planning, not every desired goal can be satisfied. A logistics team may want every delivery made early, every truck lightly loaded, and every driver kept within preferred shifts. A hospital may want staff preferences, certification requirements, legal rest periods, and cost limits satisfied at once. Reality, as usual, fails to read the requirements document.

The paper uses two formal constructs:

This matters because explanations are not merely decorative. If a plan fails, the user does not just need reassurance. They need to know which goals collide and which trade-offs would restore feasibility.

A template interface can expose this information, but it forces users to ask questions in the system’s terms. The paper’s bet is that an LLM-mediated interface can preserve the formal grounding while allowing the user to ask in ordinary language.

The mechanism is simple enough to be practical:

1. The user asks a natural-language question.
2. A question translator classifies the question and extracts the relevant goal references.
3. If the question refers to known goals, the system bypasses goal translation and queries the formal explanation framework directly.
4. If the question introduces a new goal, the goal translator may convert it into a formal temporal goal.
5. The explanation framework computes the formal answer using conflicts and corrections.
6. The explanation translator turns that formal answer into a conversational response.

The key is that the formal computation remains outside the LLM. The LLM does not decide that two goals conflict. It helps the user ask about the conflict and understand the answer.

That is a healthy amount of ambition. Almost suspiciously healthy, by current AI product standards.

The architecture has four conversational jobs

The paper’s LLM layer is multi-agent, but not in the theatrical sense of agents arguing in a digital boardroom. The agents are specialized translators with separate roles.

The question suggester reduces “blank input box” failure

A blank chat box looks flexible, but flexibility can become cognitive burden. Many users do not know what to ask a planning system. The authors observed in a pilot study that lay users struggled to formulate useful questions and tended to ask only a narrow range.

The question suggester addresses this directly. For each planning iteration, it proposes one to three relevant natural-language questions. These appear as clickable options. This is not a minor UI flourish. It changes the user’s exploration strategy by giving them starting points.

For enterprise software, this is the part many teams underbuild. They add a chat interface and assume users will magically become good interrogators of complex systems. They will not. They need suggested probes.

The question translator maps ordinary speech to formal explanation types

The question translator is the routing layer. It decides whether a user question is a direct question, a follow-up, or a question that needs a formal explanation. It also extracts the goal arguments.

For example, a user might ask, “Can I enforce more goals?” The system can interpret that as a set of formal “can” queries over currently unenforced goals. A single human sentence may trigger multiple formal calls to the explanation framework.

This is where the design becomes more subtle than a menu-based interface. The user does not need to know the internal question type. The translator does.

The goal translator is conceptually important, but not validated in the study

The goal translator maps new natural-language goal descriptions into formal temporal logic formulas. In principle, this is extremely important. A planner cannot reason over “avoid sending the kids shopping” unless that phrase becomes a formal goal.

But in the user study, the goal translator was disabled so all participants solved the same fixed task. That was a sensible experimental control. It also means we should not treat the goal translator as empirically validated by the paper’s user results.

This distinction matters for product interpretation. The paper supports the conversational explanation layer more directly than it supports free-form goal authoring.

The explanation translator makes formal conflicts readable

The explanation translator receives formal explanations, including conflicts and corrections, and generates a natural-language response. The authors also feed it richer information than the immediate answer alone, anticipating follow-up questions. For example, after a “why” question, the user may naturally ask a “how” question.

This is the most human-facing part of the system and also one of the hardest to evaluate. The authors explicitly state that measuring correctness of summarized explanations is out of scope. That is not a small limitation. If an explanation translator summarizes a conflict set incorrectly, the formal grounding becomes decorative wallpaper.

Still, the mechanism is correct: compute formally first, summarize second.

The question set expands planning explanation beyond “why not?”

A useful contribution of the paper is that it broadens goal-conflict explanations beyond a narrow “why is this goal not satisfied?” interface. The supported question types cover both unsolvable and solvable planning states.

This is more than taxonomy. It changes the planning interface from a post-mortem tool into an exploration tool.

A user is not merely asking why a plan failed. They are asking how the plan space behaves.

That is the business-relevant move. In operations, users rarely want a single explanation. They want to test alternatives: What if we insist on this delivery window? Can we add another customer visit? How do we make this staff preference work? Which requirement is poisoning the schedule?

Template systems can support these questions, but they expose the structure too visibly. Conversational mediation hides the formal machinery without removing it.

What the user study actually shows

The evaluation compares an LLM-based conversational interface against a template-based explanation interface. The task is a “parent’s afternoon” planning scenario: activities have utilities, constraints limit what can be done, and participants try to maximize the utility of the selected goals.

The setup matters. The evaluated task had 19 goals, 224 conflicts, and 313 corrections. Participants had 15 minutes. After filtering, there were 131 fluent English participants recruited through Prolific: 65 in the template group and 66 in the LLM group.

The goal utility was hidden from the planner, explainer, and LLM agents. This is important because the system could not directly optimize the user’s score. It could explain solvability, conflicts, and corrections, but users still had to reason about trade-offs.

The headline results are mixed in the right way:

The strongest evidence is not that the LLM interface made users dramatically better at maximizing utility. It did not.

The stronger evidence is subjective usefulness and interaction behavior. The LLM group had higher mean questionnaire scores across all questions. Two usefulness questions were statistically significant: whether questions reduced the level of difficulty, and whether questions helped improve a plan. A third, whether the possibility to ask questions helped, had a p-value of 0.07, which is suggestive but not conventionally significant.

So the fair reading is:

• The LLM interface made the system feel more useful.
• It changed how users asked questions.
• It may have helped users converge in fewer planning iterations.
• It did not prove a large objective performance gain on utility score.

This is not disappointing. It is actually more credible than the usual “AI assistant revolutionizes X” graph where the confidence interval is politely escorted offstage.

The appendix results are mostly boundary checks, not a second thesis

The paper includes additional evidence that is useful but easy to overread.

The “utility over time” result is especially important. If the LLM interface helps users reach higher utility per planning iteration but users spend more time conversing within each iteration, then wall-clock time may not improve. The authors observe no significant difference over time. They suggest that fewer iterations can still matter in real-world settings where replanning is costly.

That is a reasonable inference, but it is still an inference. The study precomputed conflicts and corrections to keep the interface responsive. In industrial settings, each explanation call may have a real compute cost. The architecture is promising, but the performance envelope depends on caching, precomputation, solver latency, and the density of conflicts.

The paper knows this. Product teams should know it too.

The business value is cheaper diagnosis, not magical planning

For business use, the main implication is not “LLMs improve planners.” The planner is not improved. The user’s ability to interrogate the planner is improved.

That points to a specific design pattern for enterprise systems:

Formal optimization engine
        ↓
Formal explanation service
        ↓
LLM translation and conversation layer
        ↓
User decision loop

The planning engine remains auditable. The explanation service remains grounded. The LLM layer makes the interaction usable.

This pattern is especially relevant where plans are not simply accepted after generation:

• workforce scheduling;
• maintenance planning;
• logistics routing;
• production sequencing;
• project portfolio selection;
• compliance-constrained operations;
• resource allocation under policy constraints.

In these domains, users often reject plans not because the plan is invalid, but because the plan violates unstated preferences or because the trade-off is not understood. A conversational explanation layer can reduce the number of blind iterations: generate plan, reject plan, tweak constraint, repeat, suffer quietly.

A better system lets the user ask:

• “Why can’t this requirement be included?”
• “What if I enforce it anyway?”
• “Can I add any other goals without breaking the current plan?”
• “Which goal would I need to give up?”
• “Is the problem unsolvable because of one conflict or several?”

The key ROI pathway is not that the LLM invents a better answer. It reduces the cost of finding the right question.

What the paper shows, what Cognaptus infers, and what remains uncertain

A disciplined business reading should separate the evidence from the extrapolation.

This is where the paper becomes more useful than a typical benchmark. It does not offer a single leaderboard number. It offers a system pattern.

For companies building planning or optimization software, the pattern is straightforward:

1. Keep the solver deterministic or formally controlled.
2. Compute conflicts and corrections using an explainable backend.
3. Use LLMs for natural-language mediation, not plan validity.
4. Provide suggested questions instead of relying on a blank chat box.
5. Scope memory to the current planning iteration to reduce drift.
6. Show users how their question was understood before returning the answer.
7. Treat explanation summarization as a safety-critical component, not a copywriting task.

The last point deserves emphasis. Summarizing formal explanations is not the same as writing a friendly paragraph. If the explanation translator leaves out a necessary trade-off, the user may make a worse decision with greater confidence. That is the most dangerous kind of UX improvement: smoother misunderstanding.

The architecture is conservative because planning is unforgiving

Many LLM product designs fail by assigning language models the one job they are least suited for: exact reasoning over combinatorial constraints. This paper avoids that trap. The LLMs classify, translate, suggest, and explain. The planner and explanation framework compute.

The authors also use scoped context memory. Each agent has its own input and output history, and contexts are maintained separately by iteration step. That is a practical anti-hallucination choice. In planning, old context can be actively harmful. A constraint from a previous iteration may no longer apply. A prior conflict may not exist after goals change. A chat memory that “remembers everything” is not always a feature. Sometimes it is just a bug with a personality.

This scoped-memory design should be studied by teams building business copilots. Enterprise workflows often have state boundaries: one ticket, one shipment, one planning run, one audit case, one scenario. Memory should usually respect those boundaries.

The limitations are not footnotes; they define the product boundary

The study used a single moderate-difficulty planning instance with lay users. That is enough to test usability signals. It is not enough to claim industrial generality.

The goal translator was disabled. Therefore, the study does not validate full open-ended goal creation.

The explanation translator’s summarization correctness was not fully evaluated. Therefore, the paper does not prove that LLM-generated explanation summaries are reliable in all cases.

The comparison also mixes interface style with reasoning support. The LLM group used a chat-based interface with suggestions; the template group used a more traditional interface. Some benefit may come from UI design rather than language modeling alone. The authors acknowledge this. Good. UI is not a nuisance variable in enterprise software; it is often the product.

Finally, the study precomputed conflicts and corrections to keep the user experience responsive. In real deployments, explanation latency and solver cost may matter. A system that feels intelligent in a controlled demo can feel like a committee meeting if each query waits on expensive recomputation.

These limitations do not weaken the architectural contribution. They prevent over-selling it.

A rare and welcome outcome.

What this changes for planning software

The most important lesson is that explainability should be part of the planning loop, not a report generated after the plan is done.

A static explanation answers one question.

A conversational explanation helps the user discover which question should be asked next.

That is the mechanism behind the paper’s value. The question suggester helps users probe the plan space. The question translator maps ordinary language into formal queries. The explanation framework computes grounded answers. The explanation translator makes those answers usable in conversation. The user then revises goals and continues.

In other words, the system does not merely explain a plan.

It helps the user explore the plan space.

For business planning systems, that is a better target than “fully autonomous planning.” Most organizations do not actually want a black-box planner that silently optimizes their operations. They want a system that can expose trade-offs, support negotiation, and let accountable humans revise preferences without needing a PhD in temporal logic.

The paper points toward that future: not a planner replaced by a chatbot, but a planner made conversational through carefully bounded LLM agents.

Plans do not need to talk.

But when they fail, collide, or demand sacrifice, users need something better than a red error message.

They need the plan to talk back.

Cognaptus: Automate the Present, Incubate the Future.