A reservation disappears at 7:08 p.m.
Six people were supposed to meet at eight. One has already left work. Another needs to be home by ten. Someone is vegetarian. Two people have quietly agreed that $35 is their limit.
Then the cancellation message lands in iMessage:
Sorry, we can no longer accommodate your party tonight.
The group responds as groups do.
“Anything nearby?”
“I’m flexible.”
“What about Brooklyn?”
Three screenshots arrive. Somebody suggests a place that closed last year. The person who organized the original plan begins reopening every decision the group already made.
This is where a generic chatbot tends to produce the wrong kind of help: more ideas.
But a canceled plan is not a blank page. It is a recovery problem.
Treat the cancellation like a failed dependency
In software, one failed service does not mean rebuilding the entire application. You identify what broke, preserve the working state, and replace the smallest possible component.
Group plans deserve the same courtesy.
Before searching for a backup, freeze everything that is still true:
Group size: 6
Start time: around 8:00
End time: before 10:00
Budget ceiling: $35 per person
Food constraint: vegetarian option required
Travel constraint: no new cross-city journey
Energy: people are tired and already in transit
The reservation failed. These constraints did not.
That distinction matters because “Where else should we go?” accidentally reopens location, timing, cost, food, and mood all at once. Every person then solves a slightly different problem.
The result is not collaboration. It is six browser tabs arguing through human intermediaries.
Reopen only the affected decision
The useful question is:
What changed because of the cancellation?
If the venue canceled, the venue must change. The group size probably does not. Neither does the person’s budget, dietary need, commute, or hard departure time.
I call this the cancellation’s blast radius.
A fair backup keeps that radius small. It should not quietly make one person spend more, travel much farther, or ignore a constraint just because everyone else is impatient.
Fair does not mean every option delights everyone equally. That standard would leave most groups standing on a sidewalk until midnight.
It means the disruption is not transferred to the person with the least flexibility.
Generate a recovery set, not another recommendation dump
Once the surviving constraints are clear, produce two to four options. No more.
Each option needs four parts:
OPTION
What it is
FIT
Which hard constraints it preserves
TRADE-OFF
What the group gives up
ACTION
What someone needs to check or do now
For the canceled dinner, the message might look like this:
A — Stay in the same neighborhood
Preserves everyone’s arrival time and avoids extra travel.
Trade-off: fewer cuisine choices.
Action: confirm a table for six and current pricing.B — Move one subway stop toward the group’s midpoint
Keeps the trip manageable and may offer more vegetarian options.
Trade-off: the people already nearby must move again.
Action: check current travel time and availability.C — Switch from dinner to a casual food-hall format
Makes dietary preferences easier to handle without splitting the group.
Trade-off: less intimate and potentially noisier.
Action: verify closing time, seating, and live crowd conditions.
Notice what is missing: fourteen “great spots,” a neighborhood guide, and a paragraph about hidden gems.
The group does not need inspiration anymore. It needs a commit.
Give the group a decision message it can actually answer
The organizer should not end with “Thoughts?”
That merely restarts the discussion.
Use a bounded decision:
The original booking is gone, but our budget, timing, and travel limits still stand. These are the three workable backups. Reply A, B, or C by 7:20. If there is no majority, we’ll take A because it causes the least additional travel.
Now silence has a meaning. The fallback is visible. The decision has a deadline.
Marlow, my orange tabby, uses a simpler recovery protocol: if any plan fails, return home and request dinner. It is internally consistent, but it does not scale especially well to six humans.
Where an AI assistant becomes useful
The useful role for AI here is not to impersonate the most enthusiastic person in the chat. It is to preserve context while the group is under time pressure:
Capture the volunteered constraints.
Identify what the cancellation actually invalidated.
Return two to four currently checkable alternatives.
Explain why each one fits.
Turn the shortlist into a decision message.
After that workflow is established, a group can explicitly invite Karpo for local recommendations into the iMessage planning process instead of asking one person to reconstruct the entire situation manually.
The invitation matters.
An assistant should not silently enter a conversation or build profiles of people who never chose to use it. For non-users in the group, it only needs the constraints they volunteer for this particular decision.
“Needs a vegetarian option” is sufficient. It does not need to infer why.
“Cannot spend more than $35” is sufficient. Nobody owes the software—or the group—a financial biography.
The real difference from a chatbot
A chatbot answers the latest message.
A decision workflow maintains the state of the plan.
That state includes more than preferences. It includes hard constraints, previous agreements, live conditions, social consequences, and the action required to finish.
For a canceled group plan, the useful sequence is:
preserve context
→ isolate the failure
→ generate 2–4 viable backups
→ expose the trade-offs
→ choose and act
The quality of the recommendation still matters. Prices, operating hours, transit conditions, and availability must be checked at the time of the decision.
But the larger improvement comes from asking AI to solve the correct problem.
Not:
What else could we do?
Instead:
What is the smallest fair change that gets this group moving again?
That is the difference between producing options and recovering a plan.
Top comments (0)