The Invisible User Flow
What changes when the user no longer has to walk the flow themselves
A case study in trip planning, told twice. Once the old way. Once with an agent.
Before we start
Every product designer has drawn the same picture at some point. A box. An arrow. Another box.
We call it a user flow, and for twenty years it has been an honest description of what actually happens. The user has an intention. We break that intention into steps. We design the steps. Then something changed. Not gradually, and not quietly. The user still has the intention. The steps still exist. But the user is no longer the one walking through them.
This case study is about that gap. I am going to use one sentence as the spine of the whole thing:
"I want a Kerala trip."
Same sentence, two worlds. In the first world, the user says it to themselves and then spends four evenings turning it into a trip. In the second world, the user says it to an agent, and the agent turns it into a trip.
What happens in between is the most interesting design problem of the moment.
Part 1. The old world: how Anushka booked Kerala the long way
Anushka is 23. She works in Mumbai. It is a Tuesday night in September. She has ₹30,000, five days of leave in October, and one very simple thought:
"I want a Kerala trip. Backwaters, tea plantations, something green. And I am not sitting in an overnight bus."
That is the entire intention. It took her four seconds to think it. It will take her the next eleven days to make it real.
Night one: research
- She opens Instagram. Someone she followed three years ago posted a reel from Munnar. She saves it. She opens Google. "Kerala trip 5 days." She gets nineteen blogs, all written in the same voice, all recommending the same six places. She opens three of them in tabs. She does not close those tabs for a week.
- She learns that Munnar has the tea plantations. She learns that Alleppey has the backwaters. She learns that Wayanad also has both, sort of. She now has a new problem she did not have an hour ago: she has to choose.
- She has not searched a single flight yet.
Night two: the shape of the trip
- She opens a note on her phone. She types dates. She deletes them. She checks her leave calendar. She types them again. October 12 to 17.
- Then she has to decide how many places. Two destinations means more travel time. One destination means she might miss the thing she actually wanted. She does not have the information to make this decision well, so she makes it badly and moves on. Munnar and Alleppey.
- She has not searched a single flight yet.
Night three: transport, and the first collision
- Mumbai to Kochi. She opens three apps. She compares. She finds a flight for ₹5,400 one way, which is fine, but it lands at 11:40 pm, which is not fine, because now she needs a place to sleep in Kochi before driving to Munnar in the morning. That is one extra night she did not budget for.
- She goes back. She finds a morning flight for ₹7,900. It is ₹2,500 more, but it saves a hotel night and half a day. She does the arithmetic in her head, badly, twice.
- Somewhere in here she looks at a bus. It is ₹1,800. It is an overnight bus. She rejects it. She will reject an overnight bus roughly nine more times over the next week, in nine different tabs, because no filter anywhere remembers that she does not want one.
This is the first thing worth noticing. Her constraint existed from the first second. The system made her re-apply it manually, every single time.
Nights four to seven: the middle, where trips die
- Hotels in Munnar. Filter by price. Filter by rating. Realise the good ones are 14 km outside town. Realise she does not have a car. Realise a cab there and back is ₹1,600 a day. Go back. Filter again.
- Hotels in Alleppey. Same loop. A houseboat is ₹8,000 a night, which she wants, and which eats a quarter of her budget in one line item.
- Activities. She finds a tea estate tour. It runs at 9 am. Her Munnar to Alleppey drive is five hours. If she does the tour on day three she arrives in Alleppey at 8 pm and loses the evening. If she does it on day two she has to move the hotel booking. She moves the hotel booking.
- She has now made a change to a decision she thought was finished, because a decision she made later contradicted it.
This is the second thing worth noticing. Nothing she booked knew about anything else she booked. She was the only integration layer.
Night eight: the budget
- She adds it all up in the Notes app.
- She is ₹4,900 over. She now has to work out what to remove, and no system will help her, because no system knows what she was optimising for. Only she knows that the backwaters mattered more than the private cab. Only she knows that she would rather have a worse hotel than fewer days.
- She removes the houseboat. Then she puts it back, because it was the actual reason for the trip, and takes out the private transport instead. She re-checks four hotels. She re-checks the drive time. She re-checks the total.
₹34,900 → ₹29,720
Night eleven: booking
- Five separate checkouts. Five separate confirmation emails. Two of them go to spam. One hotel price has changed by ₹400 since she last looked. She books anyway.
- She has a trip.
- She also has a week of her life she does not get back.
The flow she actually walked
Count the boxes. Anushka walked every one of them.
Part 2. What was really happening in that flow
Here is the uncomfortable read on the diagram above.
Anushka was not following a flow. Anushka was the orchestrator.
She was doing seven distinct jobs, and no product had ever named any of them:
1. She was the interpreter. She turned "something green" into "Munnar, because tea plantations." No search box accepts "something green."
2. She was the constraint keeper. "No overnight buses" and "₹30,000" lived only in her head. She re-applied them by hand in every tool, every session.
3. She was the parallel coordinator. Transport, hotels and activities are three independent searches with one shared answer. She held all three in working memory at once.
4. She was the validator. She checked whether the plan was physically possible. Can I actually drive Munnar to Alleppey and still make a 4 pm check-in? Nothing told her. She worked it out.
5. She was the budget allocator. She spread ₹30,000 across five categories, continuously, and rebalanced whenever one moved.
6. She was the re-planner. When one thing broke, she worked out which other things needed to change. This is the expensive part. This is where trips get abandoned.
7. She was the tradeoff resolver. She was the only one who knew that backwaters beat private transport. That is the one job on this list that genuinely belonged to her.
Six of these seven jobs were coordination work. Only the seventh was actually about what she wanted.
That is the design insight the entire case study rests on:
The traditional user flow was not a path. It was a coordination burden that we dressed up as a path.
And once you see it that way, the obvious question is not "how do we design a better search screen." It is: which of those seven jobs does the user actually want to keep?
Part 3. The new world: the same sentence, given to an agent
Move to now. Anushka opens something with a text field, and types the same sentence she thought to herself the last time. She types a bit more this time, because she has learned that saying more gets her more.
"Book me a Kerala trip under ₹30K with good backwaters, tea plantations, no overnight buses, and lush green surroundings."
Thirty seconds later, roughly this comes back:
"I need two things before I can check real availability: your travel dates and your starting city."
She replies: "From Mumbai, October 12 to 17. Two people."
Then, after a pause that feels short but is not:
"I found one plan that fits everything you asked for. Six days, Munnar and Alleppey, ₹29,720 total.
I made two tradeoffs to stay under ₹30K: shared daytime transport between Munnar and Alleppey instead of a private cab, and mid-range hotels instead of premium. I kept the houseboat night in Alleppey because backwaters were your first stated priority. No overnight buses anywhere in the plan.
Want me to book it, or would you rather see the alternative where you keep the private cab and drop Alleppey?"
Two messages. One decision.
Here is what did not happen: the flow did not disappear.
Every step Anushka walked the long way still happened. Destinations were still compared. Flights were still filtered. Hotels were still cross-checked against drive times. The budget was still balanced and rebalanced. The plan was still validated and revised.
The flow got bigger, not smaller. It just moved.
The fundamental shift is not from screens to chat. It is from user-orchestrated flows to system-orchestrated flows.
That distinction matters more than anything else in this document. "Screens to chat" is a surface observation and it leads designers to the wrong work, which is redesigning interfaces as conversations. The real change is a transfer of responsibility, and it leads to completely different work: deciding what the system is allowed to decide.
Part 4. The agent's flow, step by step
This is the part that is normally invisible. I am going to make all of it visible, because you cannot design something you cannot see.
Here is the whole thing first, then I will walk each stage.
Now the walkthrough.
Step 1. Understand intent
The first invisible decision is not search. It is interpretation.
The agent does not run a query. It converts a sentence into a structured internal state:
GOAL Kerala trip
DESIRED OUTCOME a feasible, bookable, confirmed itinerary
BUDGET <= 30,000
EXCLUSIONS no overnight buses
PREFERENCES backwaters, tea plantations, lush surroundings
UNKNOWN dates, origin, travellers, duration, hotel tier
Notice the second line. Desired outcome is not the same as goal. The goal is "Kerala trip." The outcome is "a trip that actually exists, is bookable, and is confirmed." Products that only model the goal produce beautiful itineraries containing hotels that are full.
Design note: this internal state should be inspectable by the user. Not as JSON, but as a readable summary they can correct. The single most common agent failure I see is not bad search. It is a confident plan built on a quietly wrong interpretation.
Step 2. Classify constraints
Not everything the user said carries the same weight. This is the step that decides how good the product is when things go wrong.
| Type | Example | Behaviour when the plan breaks |
|---|---|---|
| Hard constraint | ₹30,000 maximum | Never violated. Everything else bends first. |
| Hard exclusion | No overnight buses | Filter applied at every search, permanently. |
| Strong preference | Backwaters, tea plantations | Protected. Sacrificed only after negotiation. |
| Soft preference | Lush green surroundings | An optimisation signal, not a rule. |
| Assumption | Mid-range hotels | Made silently, but stated when presented. |
Anushka's whole problem the long way was that this hierarchy existed only in her head. She re-applied it manually, and inconsistently, across eleven days.
Principle: hard constraints must survive re-planning unless the user explicitly changes them. Preferences are optimisation signals, not equal-weight rules.
If your agent drops the ₹30K ceiling while trying to keep the houseboat, you have not built a planner. You have built a suggestion engine with a confidence problem.
Step 3. Gather context
Before asking anything, the agent checks what it already has permission to see. Prior conversations. Past bookings. Calendar. Stated preferences from before.
This changes the question the designer is asking. It is no longer "what fields are empty?" It is "what do I actually not know?"
That reframe kills the single worst pattern in AI product design: the chatbot that is secretly a form.
Step 4. Identify what is genuinely missing
Three questions, in order:
- What blocks progress? (dates and origin block real availability checks)
- What can be inferred? (five days plus October probably means a long weekend extension)
- What can wait? (hotel tier does not need answering until a budget conflict appears)
Only category one earns an interruption.
Step 5. Clarification
"I need two things before I can check real availability: your travel dates and your starting city."
One message. Two fields. Both genuinely blocking.
Compare that to the bad version, which every team builds first:
"Great! What are your dates? How many travellers? What's your budget? Do you prefer hotels or homestays? Any dietary requirements? Preferred airline?"
That is a form wearing a conversation's clothes. It is worse than a form, because a form at least lets you see all the fields at once and answer them in any order.
Principle: ask when ambiguity materially changes the outcome, not because a field is empty.
Step 6. Build the destination model
Here is where the agent does something a search box structurally cannot.
"tea plantations" → Munnar, Vagamon, Wayanad
"backwaters" → Alleppey, Kumarakom, Kollam
"lush green surroundings" → hill and nature destinations, weights the above
"no overnight buses" → constrains which pairs are even connectable
This is not keyword matching. It is translating an experience preference into a destination hypothesis, then testing whether that hypothesis survives the constraints.
Anushka did this herself, over two evenings, using nineteen blog posts.
Step 7. Compose the trip structure
One destination or two? The answer is not a preference, it is a calculation.
Option A Munnar only
more time in one place, less travel, cheaper
but loses backwaters, which was a stated strong preference
Option B Munnar + Alleppey
satisfies both strong preferences
costs one travel day and roughly 5K more
Option C Munnar + Alleppey + Wayanad
more coverage, but three moves in five days
fails on travel time, and likely on budget
Option C is discarded before the user ever sees it. That is a design decision, not a technical one. Someone decided that showing an infeasible option is worse than not showing it. I agree with that, and I would defend it, but it needs to be a decision rather than an accident.
Step 8. Parallel search, one shared state
Transport, hotels and activities run at the same time. This is the step people point at when they say agents are "faster."
Speed is the least interesting part of it.
The interesting part is that parallel does not mean independent. All three feed one shared itinerary state. The hotel result changes what transport is viable. The transport arrival time changes which activities fit on which day. Anushka held that in her head. The agent holds it in a data structure.
Also worth noting: the overnight bus is rejected automatically, once, permanently, at the search layer. Anushka rejected it nine times manually.
Step 9. Budget allocation, propagated
The ₹30,000 is not a number checked at the end. It is a live constraint that shapes every search.
flights 12,000
hotels 8,000
local travel 5,000
activities 3,000
buffer 4,000
------
32,000 → over. Rebalance before searching further.
If flights come back at ₹15,000 instead of ₹12,000, the agent does not proceed and fail at checkout. It immediately reduces the hotel band and re-searches within the new envelope.
Contrast with the traditional flow, where budget lives in a Notes app and only announces itself on night eight, after every other decision has already been made and become expensive to undo.
Step 10. Orchestrate time and geography
This is the least visible and most valuable work in the whole system.
Day 1 Mumbai → Kochi (morning flight, lands 09:40)
Kochi → Munnar (4h drive, arrive 14:30)
Check in 15:00
Day 2 Tea estate tour 09:00–12:00
Afternoon free, viewpoint 16:00
Day 3 Munnar → Alleppey (5h, depart 08:00, arrive 13:00)
Houseboat check-in 14:00
Day 4 Backwaters, full day
Day 5 Alleppey → Kochi (1.5h)
Evening flight home
Every line has an invisible check behind it. Does the flight land early enough for a same-day drive? Does the drive get her there before check-in closes? Does the tour start after breakfast and end before the drive? Is the houseboat check-in compatible with a 13:00 arrival?
This is not attraction generation. It is constraint satisfaction across time and geography. It is also the exact work that made Anushka move a hotel booking on night six.
Step 11. Validate, then re-plan selectively
The candidate itinerary comes back at ₹31,700.
A weaker system shows this to the user and asks them to fix it. That is just a worse version of the long way with extra steps.
What should happen instead:
Two things to hold onto here.
One: re-planning is selective. When the transport option changes, only transport, budget and dependent timings recalculate. Hotels that were not affected stay booked to the plan. Restarting from zero every time a variable moves is the agentic equivalent of a page reload, and users feel it as instability.
Two: re-planning is a first-class state, not an error. The traditional flow treated "over budget" as a failure that bounced the user back to the start. The agentic flow treats it as a normal step in the loop.
Step 12. Determine intervention
Now the most important design question in the entire system:
What is the agent allowed to decide on its own?
The agent chose shared transport over private. Should it just do that, or should it ask?
The test I would use has three parts:
| Question | If yes |
|---|---|
| Is the action consequential? (money moves, something becomes non-refundable) | Ask |
| Is the action irreversible? (non-refundable booking, gone inventory) | Ask |
| Is the ambiguity material? (two valid options, and only the user knows which they value) | Ask |
Shared vs private transport passes the third test. Two people can hear "shared daytime transport" completely differently. So the flow surfaces:
"I can keep both Munnar and Alleppey within ₹30K if we use shared daytime transport and mid-range hotels. Or I can keep private transport if we drop Alleppey. Which matters more?"
This is the moment the invisible flow becomes visible. Not because the system is showing off its work, but because it genuinely cannot make this call. That is the correct trigger for visibility, and it is the only one I would accept.
Step 13. Present the curated outcome
The agent has run dozens of searches. It should not show dozens of searches.
There is a real distinction that most teams collapse:
- Process transparency: "I searched 47 hotels."
- Decision transparency: "I chose these three because they meet your budget, are within 2 km of the backwaters, and have free cancellation."
The first is noise dressed as honesty. The second is the thing that actually earns trust.
MORE INVISIBLE
─────────────────────────────
searching
comparing
ranking
calculating
retrying
coordinating
re-planning
─────────────────────────────
intent understood
assumptions made
tradeoffs taken
permissions requested
consequential actions
failures
final outcome
─────────────────────────────
MORE VISIBLE
Principle: hide operational work, not meaningful decisions.
Step 14. Conversation and UI are not rivals
Here is where I will push back on a popular idea.
Chat is not the destination. Chat is the entry point. The moment the agent has narrowed to three viable trips, prose becomes the worst possible way to compare them. You cannot scan a paragraph.
So the agent generates a surface:
┌────────────────┬─────────────┬─────────────┬─────────────┐
│ KERALA TRIP │ OPTION A │ OPTION B │ OPTION C │
├────────────────┼─────────────┼─────────────┼─────────────┤
│ Cost │ ₹26,800 │ ₹28,400 │ ₹29,700 │
│ Duration │ 5 days │ 5 days │ 6 days │
│ Destinations │ Munnar + │ Munnar + │ Munnar + │
│ │ Alleppey │ Alleppey │ Wayanad │
│ Transport │ Shared │ Private │ Shared │
│ Preferences │ 4 of 4 │ 4 of 4 │ 3 of 4 │
├────────────────┼─────────────┼─────────────┼─────────────┤
│ │ [ Book A ] │ [ Book B ] │ [ Book C ] │
└────────────────┴─────────────┴─────────────┴─────────────┘
The conversation established intent. The system did the research. The UI appears at the exact moment structured comparison beats prose, and disappears afterwards.
This is a genuinely new design primitive, and it is worth naming: UI as a temporary control surface, summoned by the conversation when structure adds value. The MCP specification's Apps extension is one place this is being formalised, where a tool can return an interactive component directly into the conversation rather than only text.
Principle: conversation can determine when UI is necessary.
Step 15. The booking boundary
The user says "book it."
The agent moves from research into execution, and the rules change completely. Before anything irreversible:
- Re-check live availability (the plan is minutes old, inventory is not)
- Re-check final price (₹29,720 may now be ₹29,940)
- Re-check cancellation policy
- Confirm the exact payment amount
- Request explicit approval
That fifth line is not a legal formality. It is the single strongest trust signal in the product, and the industry data in Part 7 says users will not proceed without it.
Execution is itself a flow, not a magic button:
Step 16. Failure and recovery
The Alleppey houseboat becomes unavailable between recommendation and booking. This will happen. It is not an edge case, it is Tuesday.
Traditional product response:
"Sorry, this property is no longer available."
The user is returned to the start of the flow holding a dead end.
Agentic response:
"The houseboat got booked while we were finalising. I found two alternatives that still meet everything you asked for. One is ₹300 more but has free cancellation. The other is ₹500 cheaper but sits 2 km further from the main backwater route. Everything else in your plan is unchanged and still within budget."
The difference is not politeness. It is direction. The traditional error terminates the flow. The agentic recovery moves toward the original outcome.
Principle: when reality breaks the plan, recover toward the outcome instead of returning a dead end.
This is the highest-leverage, least-designed surface in every agentic product I have looked at. Teams spend eight weeks on the happy path and forty minutes on what happens when a hotel disappears. It is backwards. The happy path is where users form an impression. Recovery is where they decide whether to trust you again.
Part 5. Side by side
| Traditional | Agentic | |
|---|---|---|
| What the user gives | A series of specific inputs | An intention with boundaries |
| Who interprets | The user | The system |
| Who holds constraints | The user's memory | The system's state |
| Who coordinates | The user | The system |
| Who validates feasibility | The user | The system |
| Who re-plans | The user, from scratch | The system, selectively |
| Who decides tradeoffs | The user | The user, when it matters |
| Who approves money | The user | The user, always |
| Where errors go | Dead end | Recovery loop |
| What is measured | Screens completed | Outcome achieved |
| Time to a plan | Days | Minutes |
| Steps the user walks | ~40 | ~3 |
| Steps the system walks | ~0 | ~40+ |
That last pair is the entire thesis in two rows.
The flow did not get simpler. It got moved.
Part 6. The two-flow model
Once you accept that, you stop designing one flow and start designing two, plus the seams between them.
The dotted lines are the product. Not the boxes. The boxes are engineering. The dotted lines are where design lives, because each one is a decision about how much responsibility to transfer and when to hand it back.
There are exactly five of them worth naming:
- Intent handoff. How much can the user say, and how much does the system infer?
- Clarification. When is an interruption earned?
- Negotiation. Which tradeoffs are the system's to make?
- Approval. What requires a human, always?
- Correction. How does a user change their mind without restarting?
Get those five right and the product works. Get the screens beautiful and those five wrong and it does not.
Part 7. This is already happening: what the industry data says
This is not a thought experiment. The travel industry is where agentic commerce is being tested in public, and the numbers are specific enough to design against.
Adoption is real and moving fast
Phocuswright's survey data, reported in July 2026, shows 56% of US travellers used AI for planning or booking in the previous twelve months, up from 43% in the second half of 2025 and 33% in the first half of 2025. That is a near-doubling inside a year.
A Marriott Bonvoy survey of over 22,000 travellers across EMEA (October 2025) found 50% had used AI to research or plan a trip, a nine-point year-on-year rise and 24 points up from 2023, with 14% saying they use AI "all the time."
But adoption collapses at the transaction
This is the single most useful chart for anyone designing an agentic product, and it comes from BTIG research reported in July 2026:
| Task | Travellers willing to use AI |
|---|---|
| Research | 80% |
| Inspiration | 76% |
| Itinerary building | 65% |
| Room reservations | 42% |
| Flight booking | 38% |
Read that gradient carefully. Willingness falls off a cliff exactly where money and irreversibility enter. Not where complexity enters. Not where AI gets harder. Where consequence enters.
That is not a technology gap. That is users telling you precisely where the intervention boundary belongs, and it maps almost perfectly onto the three-part test in Step 12.
The Marriott data adds a second dimension: comfort with AI booking accommodation splits sharply by region (35% of European travellers comfortable versus 70% in the Middle East) and collapses with age (among 55 to 64 year olds, 29% use AI but only 35% are comfortable letting it book; that falls to 18% for over-65s). Your intervention boundary is not one setting. It is a segment-dependent one.
What is actually shipping
Google AI Mode, hotel booking (August 27, 2026). Users can chat to find and compare rooms, make a selection, review cancellation terms, and pay with Google Pay in one place. Launch partners include Booking.com, Expedia, Hilton, IHG, Marriott, Priceline and Trip.com. The detail that matters for this case study: the AI does not book autonomously. The hotel or OTA remains merchant of record, charges the card, sends the confirmation and handles support. Flight booking had not shipped as of that date.
Booking.com's app in ChatGPT (May 2026). A user describes what they want in natural language and browses relevant options, then is redirected to Booking.com to complete the reservation. The agent owns discovery and selection. The transaction goes home.
Ixigo's TARA (May 2026). Conversational booking by voice, text or tap in English, Hindi and Hinglish, plus "Agentic Travel Flows" that run after booking: sending boarding passes over WhatsApp, monitoring flights for delays. Note where the autonomy is placed. Not on the payment. On the post-booking coordination, where consequence is low and the tedium is high.
Airlines (August 2026). Southwest and Alaska Airlines are applying agentic AI to operations, overbooking management and policy-grounded support rather than consumer booking.
The disintermediation story is more subtle than the headlines
Booking Holdings' CFO said in August 2026 that traffic from LLMs accounts for less than 1% of the company's room nights, with no material change over recent quarters. BTIG's estimate is that AI platforms account for roughly 0.4% of OTA traffic, against roughly 40% from paid search.
Meanwhile the CEO noted that their brands show up "an awful lot" within LLM answers, which he called an interesting difference from actual referral volume.
My read: the visibility has moved before the transaction has. Users are already letting agents do the seven coordination jobs from Part 2. They are not yet letting agents do the seventh one, which was always theirs. That is not a temporary state waiting for better models. That is where the line should be.
Part 8. The design decisions I would defend
If this were my product, these are the calls I would make and the reasoning I would give for each.
1. The delegation contract is a design artefact, not a settings page
A delegated agent needs more than a task. It needs an explicit statement of what it may decide and do. I would design this as a first-class, visible, editable object:
DELEGATION CONTRACT: Kerala trip
GOAL
Plan and book a Kerala trip
HARD CONSTRAINTS
Budget <= ₹30,000
No overnight buses
PREFERENCES (ranked)
1. Backwaters
2. Tea plantations
3. Lush surroundings
DECISION AUTHORITY
Choose route and destination order
Choose hotels within the agreed price band
Choose activity timings
EXECUTION AUTHORITY
Search and compare freely
Hold refundable reservations
APPROVAL REQUIRED
Any payment
Any non-refundable booking
Any exception to a hard constraint
RECOVERY AUTHORITY
Replace an unavailable hotel with an equivalent
Re-plan transport
Never sacrifice a hard constraint to recover
ESCALATE
Hard constraints conflict
High-consequence action
Material ambiguity between two valid options
Why this and not a settings screen: settings are configuration, and users abandon them. A contract is scoped to one job, produced in context, reviewable in ten seconds, and reusable next time. It also gives you something to show the user after the fact when they ask why the agent did something.
Delegation is authority, not automation. That is the sentence I would put on the wall.
2. Tool granularity is a product decision, not an API decision
Compare:
ONE COARSE TOOL GRANULAR TOOLS
───────────── ──────────────
book_trip() search_hotels()
compare_hotels()
check_availability()
hold_reservation()
confirm_reservation()
search_transport()
cancel_reservation()
With one coarse tool, the agent either does everything or nothing. You cannot put an approval step in the middle of a black box. You cannot recover halfway through. You cannot show the user what stage they are at.
With granular tools, every boundary between them is a place you can insert a permission, a checkpoint, a progress state, or a rollback.
Tool architecture is flow architecture. The capabilities you expose determine the control points you can design.
The MCP specification supports this thinking directly: tools carry optional behavioural annotations, and the spec is explicit that clients must treat annotations from untrusted servers as untrusted, and that there should always be a human in the loop able to deny a tool invocation, with clear visual indicators when tools are invoked. That is not a technical footnote. That is a design requirement written into a protocol.
3. Transparency is about decisions, not operations
Covered in Step 13, restated here because it is the one teams get wrong most often. Showing a scrolling log of forty-seven tool calls does not build trust. It builds anxiety and it hides the three things that mattered.
Show: what I understood, what I assumed, what I traded away, what I need permission for, what failed. Hide: everything else, but keep it retrievable on request.
4. Recovery gets designed before the happy path
I would genuinely run it in this order. Design the failure states first, because they define the authority model, and the authority model defines everything else. If the agent may replace an unavailable hotel without asking, that tells you what "hotel choice" means in your product. If it may not, that tells you something different, and both are defensible, but you have to pick.
5. The outcome is the metric, not the response
An agent can complete every internal step and still fail the user. A beautiful itinerary with an unavailable hotel, an impossible drive time, or a broken budget is not a success just because it rendered.
The final state should be scored against the original intent:
OUTCOME CHECK
Total ₹29,720 within ₹30,000 hard limit ✓
6 days / 5 nights ✓
Munnar + Alleppey ✓
Tea plantations included strong preference met ✓
Backwaters included strong preference met ✓
Lush surroundings soft preference met ✓
No overnight buses hard exclusion respected ✓
Availability verified all bookings confirmed ✓
Tradeoffs surfaced transport change disclosed ✓
Consequential actions user approved payment ✓
The endpoint is not "response generated." It is "intention successfully converted into a feasible and trustworthy reality."
Part 9. The Invisible Flow framework
Seven questions. I use these in order on any agentic product, travel or otherwise.
Applied to the Kerala trip:
| Question | Answer | |
|---|---|---|
| 1 | Intent | A real, bookable, affordable Kerala trip matching four experience preferences |
| 2 | Boundaries | Hard: ₹30K, no overnight buses. Strong: backwaters, tea plantations. Soft: lush surroundings |
| 3 | Agency | User owns tradeoff priority and payment. Agent owns route, sequencing, comparison, hotel choice within band |
| 4 | Orchestration | Parallel search across three domains into one shared itinerary state, validated against time, geography and budget |
| 5 | Intervention | Two blocking unknowns, one unresolvable tradeoff, one payment approval. Four touchpoints total |
| 6 | Recovery | Replace equivalent hotel within authority. Escalate anything that touches a hard constraint |
| 7 | Outcome | Ten-point check against the original sentence, not against internal completion |
Notice that answering these seven questions produces a product spec. It does not produce a screen. That is the point.
Part 10. What product designers design now
TRADITIONAL SURFACE EXPANDED SURFACE
─────────────────── ────────────────
Screens Intent models
Flows Context and permissions
States Constraint hierarchies
Actions Capability and tool boundaries
Agency and decision authority
Intervention points
Recovery and escalation paths
Transparency thresholds
Delegation contracts
Outcome definitions
Screens
Flows
States
Actions
The screen did not go away. It stopped being the whole product.
The questions I now ask before drawing anything:
- What does the system need to understand?
- What should it infer, and what must it never assume?
- What can it decide? What can it execute?
- What should stay invisible? What must become visible?
- What happens when the plan meets reality and loses?
- What can the user undo?
- Did the intention actually become real?
None of those are answered in Figma. All of them determine what goes into Figma.
This is a shift from designing interaction to designing human-system collaboration.
Part 11. How you would test any of this
Frameworks are cheap. Here is how I would validate the design decisions above, because a case study without a research plan is a nice essay.
The core uncertainty is not "do users want this." Adoption data already answers that. The uncertainty is: where exactly does each user segment want the boundary, and what breaks trust when you get it wrong?
Three studies, in order:
1. Boundary elicitation (qualitative, 8 to 10 participants, 60 min). Give participants a completed agent plan and a delegation contract. Ask them to edit the contract until they are comfortable pressing "let it run." What they add to approval required is your intervention boundary. What they leave in decision authority is your permission to act. Run it across two age bands, because the Marriott data says age moves this variable hard.
Why this method: you cannot survey your way to a boundary. People misreport comfort with autonomy. Watching what they actually restrict is behavioural, not stated.
2. Recovery trust test (qualitative, same participants, second session). Break the plan mid-flow. Hotel unavailable. Price up ₹900. Flight delayed by two hours. Show three recovery treatments: silent fix within authority, fix with disclosure after, ask before fixing. Measure willingness to continue and willingness to use again.
Hypothesis worth testing: silent recovery is preferred for low-consequence failures and is trust-destroying for anything touching money, even when the outcome is identical.
3. Transparency threshold test (comparative, larger n). Same plan, three transparency treatments: full process log, decision-only summary, outcome only. Measure comprehension of what the agent actually did, confidence in the plan, and error detection rate when you deliberately plant a wrong assumption.
What I expect and would want to be wrong about: full process logs will score highest on perceived transparency and lowest on actual error detection, because volume hides the mistake.
Metrics that matter for a live agentic product:
| Metric | Why |
|---|---|
| Intent-to-outcome rate | Did the stated intention become a confirmed reality? |
| Interventions per completed task | Too high means the agent is a form. Too low means it is overreaching. |
| Constraint violation rate | Did any hard constraint survive to the outcome broken? Should be zero. |
| Recovery success rate | Of plans that broke, how many reached the original outcome anyway? |
| Correction depth | When a user changes their mind, how much of the plan had to be rebuilt? |
| Approval abandonment | Where in the approval step do users stop? That is your trust leak. |
Note what is missing: screens per session, time on task, funnel completion. Those measure a flow the user is no longer walking.
Closing
Anushka's sentence never changed.
"I want a Kerala trip."
Four seconds to think, in both worlds. The long way, it cost her eleven evenings, forty-odd steps, five checkouts and one abandoned houseboat. Now it costs her three messages and one real decision, which happens to be the only decision that was ever genuinely hers: what she is willing to give up.
Everything else was coordination. We spent two decades getting very good at designing coordination burdens and calling them user flows.
The flow did not disappear. The user stopped being responsible for traversing it. As the system takes over orchestration, the visible flow gets shorter and the invisible flow gets enormous, and the designer's job moves to the seams: which complexity the machine absorbs, which decisions the human keeps, which actions need permission, what stays hidden, what must be shown, and how the system finds its way back when reality breaks the plan.
We used to design the path a user would take. Increasingly, we design the system that finds the path.
Appendix: sources and honest limits
Verified sources used in Part 7:
| Claim | Source | Publisher | Date |
|---|---|---|---|
| 56% of US travellers used AI for planning/booking in past 12 months, up from 43% (H2 2025) and 33% (H1 2025) | OTA AI margin pressure and disintermediation | PhocusWire, citing Phocuswright | Jul 17, 2026 |
| Willingness by task: research 80%, inspiration 76%, itinerary 65%, rooms 42%, flights 38% | OTA AI margin pressure and disintermediation | PhocusWire, citing BTIG | Jul 17, 2026 |
| 50% of EMEA travellers used AI to research or plan a trip; 14% use it "all the time"; comfort splits 35% Europe vs 70% Middle East; 55-64 age band 29% usage / 35% comfort | More EMEA travelers trust AI vacation planning | PhocusWire, survey by Marriott Bonvoy, 22,000+ respondents | Oct 31, 2025 |
| Google AI Mode hotel booking: chat to compare, select, review cancellation terms, pay with Google Pay; AI does not book autonomously; partner remains merchant of record; flights not yet shipped | Google's agentic hotel booking tool comes to AI Mode and Google AI Mode hotel booking | Skift; PhocusWire | Aug 27, 2026 |
| Booking.com app in ChatGPT: describe, browse options, redirect to Booking.com to complete reservation | Booking.com is making car rentals easier with app in ChatGPT | Booking.com press | May 20, 2026 |
| Ixigo TARA: voice/text/tap in English, Hindi, Hinglish; "Agentic Travel Flows" automate post-booking tasks | Ixigo launches travel app with conversational booking and agentic AI | PhocusWire | May 14, 2026 |
| Airlines applying agentic AI to operations and support rather than consumer booking | Airlines look to agentic AI for help with efficiency | PhocusWire | Aug 25, 2026 |
| LLM traffic under 1% of Booking Holdings room nights; brands visible in LLMs far more than referral volume suggests | Booking Holdings Q2 2026 earnings | PhocusWire | Aug 4, 2026 |
| AI platforms roughly 0.4% of OTA traffic vs ~40% from paid search | OTA AI margin pressure and disintermediation | PhocusWire, citing BTIG | Jul 17, 2026 |
| MCP primitives (resources, prompts, tools); user consent and control principles; tool annotations untrusted unless from trusted servers; human in the loop should be able to deny tool invocations | MCP specification 2025-06-18 and MCP tools | Model Context Protocol | 2025-06-18 revision |
What is illustrative, not sourced:
Anushka is a composite persona, not a research participant. The Kerala prices, routes, drive times, hotel rates and the ₹29,720 total are worked examples chosen to make the constraint arithmetic legible. They are not live inventory and should not be read as market rates. The step-by-step agent flow is an architectural design proposal grounded in current agentic travel implementations and the MCP specification; it is not a claim that any named product performs these exact steps in this exact order.
What I tried to verify and could not:
Google's own primary-source announcement page for AI Mode hotel booking could not be reached; those facts rest on two independent trade-press reports rather than Google's own publication. No verified evidence was found on Kayak or Tripadvisor AI assistants, so their absence here means no evidence found, not no product. No named, shipped Expedia-branded consumer booking agent was verified beyond the Alexa+ integration. Percentages attributed jointly to Mindtrip, Sabre, Sojern and MMGY were reported without stated methodology and are therefore excluded from Part 7.