The first request in a travel-planning conversation is rarely the final one.
Consider a synthetic conversation. A traveler begins with ten days in Portugal, then asks to spend longer in Porto, replace a rental car with trains, keep a booked night in Lisbon, and make the last two days easier. Each message changes part of the plan. None of them should erase the parts the traveler still expects us to remember.
That makes correction handling a state problem, not merely another prompt.
The transcript is not the plan
Sending an entire conversation back to a language model can look like the simplest way to retain context. It also leaves important questions unanswered.
Which statement is current when two messages disagree? Was a hotel stay a fixed booking or an early idea? Does “make it slower” apply to the whole trip or only the day being discussed? Should a new route replace the existing trip or become a separate version?
A transcript records what was said. A planning system needs a canonical representation of what is currently true.
At Platix, that representation is a versioned trip brief. It separates destinations, route order, duration, dates, travelers, transport, constraints, and planning preferences. A follow-up turn proposes a change to that structure rather than asking the system to reinterpret the trip from nothing.
A correction needs scope
Not every edit deserves a complete replan.
“Move the museum to the afternoon” is a narrow day edit. “Spend three nights in Porto instead of two” changes overnight allocation and may affect several days. “Replace Portugal with northern Spain” changes the trip's route and most of its planning assumptions.
A useful revision system first identifies the smallest truthful scope:
- Stop-level changes can preserve the rest of the day.
- Day-level changes can preserve unrelated days.
- Route changes may preserve days whose geographic base remains compatible.
- Whole-trip changes should create and review a complete candidate before replacing anything.
This classification matters for both quality and trust. Rebuilding everything for a small correction wastes time and can introduce unrelated changes. Treating a structural change as a small edit can leave the itinerary internally inconsistent.
Facts need different authority
Travel requirements are not all equally negotiable.
Consider a synthetic trip with a confirmed train on Friday afternoon, a preference for quiet hotels, and an inferred suggestion to spend two nights in a coastal town. The train is fixed. The hotel preference should influence choices but can admit tradeoffs. The two-night stay is a reversible planning assumption.
When a revision cannot satisfy everything, the system should preserve the facts with the strongest authority and surface the conflict. It should not silently move a confirmed train because a newly generated route reads more smoothly.
This is why provenance belongs in the planning model. A value should carry whether it came from the traveler, a confirmed booking, a prior accepted decision, or the planner's own recommendation. Confidence alone is not enough. A model can be highly confident about a change it was never authorized to make.
Build the candidate before changing the trip
Large revisions should be staged.
Platix can plan a candidate route and its affected days while leaving the current trip untouched. The traveler can inspect what changed, keep the current version, preserve the candidate separately, or explicitly apply it when the trip is eligible for replacement.
That boundary gives the product several protections:
- Planning failure does not damage the working itinerary.
- A refresh does not turn an unfinished candidate into the live trip.
- The traveler sees the consequence before confirming it.
- Protected trips can use copy-only behavior instead of destructive replacement.
- A concurrent edit can make the candidate stale rather than allowing it to overwrite newer work.
The model helps construct the proposal. It does not grant itself permission to execute it.
Continuity must survive the browser
Conversation state cannot live only in a component or a background task's memory.
A traveler may refresh, close a tab, return from a link, or answer a clarification later. The product should resume from durable state: the active brief revision, the pending question, the planning attempt, and any candidate waiting for confirmation.
Idempotency is part of the same experience. A repeated click or network retry should converge on the existing operation instead of creating a second trip. A late background result should not apply after the traveler has cancelled it. A stale answer should not attach itself to a newer brief revision.
These sound like backend concerns, but users experience them as something simpler: “The planner remembered where we were.”
Test the conversation, not only the first turn
Single-turn evaluations are useful for checking extraction and route shape. They cannot prove that correction behavior works.
A multi-turn synthetic case should verify that:
- New information updates the intended field.
- Unchanged fixed facts survive.
- Explicit corrections outrank earlier assumptions.
- Ambiguous scope produces one useful question.
- A clarification continues the same planning session.
- Repeated submission does not create duplicate work.
- A stale revision cannot overwrite the current one.
The expected result should describe the state transition, not demand one exact sentence from the model.
The durable lesson
An AI planner becomes useful over time only when the traveler can disagree with it safely.
That requires more than remembering a transcript. It requires versioned requirements, scoped changes, authority and provenance, staged candidates, explicit confirmation, and durable recovery. The conversation feels natural because the system underneath it is precise about what changed and what did not.
Loading comments...