OTA giants are all pushing AI assistants now. Ctrip's "Wen Yi Wen," Fliggy's AI travel assistant, Meituan's AI customer service. They look similar: you say "find me a hotel in Shanghai" and it recommends a few. But if you've built this kind of product, you know "can chat" and "can do things" aren't the same difficulty level.
This post breaks down why "task-doing" AI is 10x harder than "chatting" AI. Five dimensions, all from building real products.
Dimension 1: Intent Understanding—From "Hear the Words" to "Hear the Needs"
Start with the basics: intent understanding.
Chat AI intent is relatively simple. User says "write me a poem." You get it. User says "explain relativity." You get it. Intent is clear and single.
Transaction intent is harder. User says "find me a hotel close to the office." What does "close" mean? 10-minute walk? 15-minute taxi? Within 3 km? The user might not know either.
Another: user says "find me a good value hotel." What's "good value"? Cheap? Or nicer service at a slightly higher price? Different users mean different things.
The hard part is implicit needs. User says "I'm going to Shanghai next week, book me a hotel." Implicit needs might be: need an invoice, quiet room, breakfast included, expense reportable. They don't say these. If you don't pick up on it, they use it once and leave.
Chat AI only needs to "hear what the user said." Transaction AI needs to "hear what they didn't say." Not the same level.
Dimension 2: Tool Calling—From Single-Turn to Multi-Step Planning
Second dimension: tool calling.
Chat AI tool calls are usually single-turn. User asks "what's the weather today?" AI calls the weather API, returns the result. Done.
Transaction tool calls are multi-step and planned. User says "plan a 3-day Hangzhou trip for me." What does AI do?
- Search Hangzhou attractions worth visiting
- Search Hangzhou hotels: location and price
- Search flights from departure city to Hangzhou: timing works?
- Assemble a reasonable itinerary
- Calculate total budget: does it match user expectations?
Five calls. Each step's result affects the next. Change the hotel location and the schedule shifts. Change flight times and day one changes too.
This is classic multi-step planning. Not one tool call. You need to plan a call sequence and dynamically adjust based on intermediate results. Way harder than single-turn.
And you need to control call count. Don't make dozens of tool calls to plan one trip and burn through user's token budget. Balancing result quality against call cost is its own problem.
Dimension 3: Data Integration—From Static Text to Real-Time Dynamic Data
Third dimension: data integration.
Chat AI data is mostly static. Knowledge bases, documents, web pages. These don't change every minute. Cache for a day, no problem.
Transaction data is real-time and dynamic. Hotel prices change by the minute. Room status changes by the second. Flight prices shift multiple times an hour. You must use the latest data when calling.
Worse: data sources need alignment. Hotel MCP data, flight MCP data, attraction MCP data—different formats, different units, even different names for the same place. Some say "West Lake District, Hangzhou." Others say "Hangzhou West Lake." You align them.
And data consistency. Hotel MCP says a hotel has rooms. User clicks through and it's gone. How do you make sure the data AI sees matches what the user can actually book?
Chat AI data being wrong doesn't matter much. Transaction AI data being wrong means real money. User pays, finds it's off, and complains. Different pressure entirely.
Dimension 4: Error Recovery—From "Say It Wrong Again" to "What Happens Now?"
Fourth dimension: error recovery.
Chat AI says something wrong? No problem. User smiles, asks again. Zero cost, zero consequence.
Transaction error? AI recommends a hotel. User clicks through, no rooms. AI quotes a price. User pays, finds it's wrong. AI plans an itinerary. Day one attraction is closed Tuesdays.
Every error is a UX disaster. You can't "say it wrong again" like chat AI. User has already moved to payment. Telling them "sorry, I said that wrong" doesn't work.
So transaction AI needs error recovery mechanisms:
- Data looks off, can you correct it in real time?
- Recommended hotel has no rooms, can you auto-suggest alternatives?
- Price changed, can you tell the user before they pay?
- Schedule has a conflict, can you auto-adjust?
These need to be designed into the product. Chat AI errors are small. Transaction AI errors cost real money. Another level up.
Dimension 5: Transaction Safety—From "Say the Right Thing" to "Do the Right Thing"
Fifth dimension: transaction safety.
Chat AI safety requirements: no profanity, no politically sensitive content, no illegal output. Easy.
Transaction AI safety is a different dimension entirely. It needs:
- Financial safety: don't pay the wrong amount, don't overcharge, don't undercharge
- Data security: user's ID number, phone, payment info can't leak
- Order safety: don't place the wrong order, book the wrong hotel, wrong dates
- Compliance: meet travel industry regulations and payment industry regulations
These are baseline violations. One incident and it's serious. Chat AI says one wrong thing, user complains. Transaction AI has one security incident and the product might not survive.
So transaction AI design is full of "safety valves": validate every step, log every step, have a fallback for every step. These mechanisms make the system much more complex.
Why 10x Harder?
Looking across these five dimensions:
| Dimension | Chat AI | Transaction AI | Difficulty Gap |
|---|---|---|---|
| Intent understanding | Hear literal meaning | Hear implicit needs | 3x |
| Tool calling | Single-turn call | Multi-step planning | 5x |
| Data integration | Static data | Real-time dynamic data | 4x |
| Error recovery | Say it wrong again | Transaction-grade recovery | 10x |
| Transaction safety | Content safety | Financial + data + compliance | 10x+ |
That's why OTA AI assistants all look similar but few actually work well. Everyone is solving "can chat." "Can do things" has a long way to go.
Teams building AI assistants with RollingGo's hotel MCP have close to 300 GitHub stars, with both an MCP server and travel skills. Behind it: 110K+ direct-contracted hotels and 2M+ global properties. Direct inventory with real-time price confirmation. What you see is what you can book. Completely free, no call-volume limits. Supports 40+ major LLM clients. Provides an all-in-one booking skill for ClawHub and Coze. Developer partners set country-based markup rates and earn commission.
But only about 10% actually reach "can do things" level. Most are still "can chat, can look up a hotel." Want your AI assistant to actually get things done? Grab an API key and try it.
Setup in Cursor:
{
"mcpServers": {
"RollingGo-Hotel": {
"url": "https://mcp.rollinggo.ai/mcp",
"type": "streamable-http",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Restart Cursor and you're searching hotels, checking room types, and confirming prices directly. To take your AI assistant from "can chat" to "can do things," start with MCP.
"Can chat" AI solves "what users want to ask." "Can do things" AI solves "what users want to do." The latter is much harder. From intent understanding to tool calling, from data integration to error recovery, to transaction safety—each dimension is hard.
But because it's hard, doing it well creates a moat. The companies that nail "can do things" AI are the ones with real competitive advantage.
What do you think future AI assistants will look like? Still chat-based, or fully agentic? Drop a comment.
Top comments (0)