Vedar

Posted on Nov 3 Edited on Nov 3

Our AI agent doesn't know the price of a tour. That's the main feature

#ai #llm #mcp #travel

TL;DR. Ask an LLM about a tour in Kamchatka and it will confidently give you a price, dates and available spots. The trouble is that all of it may be made up. We build Vedar (https://vedarai.ru), a travel portal for Kamchatka, Russia, and it has an AI agent at its core. This post explains why we forbid that agent from inventing prices, why no booking request is ever confirmed by a bot, why it reads emergency and volcano alerts, and why we opened the site to third-party AI agents via MCP and A2A.

Context: Kamchatka is a bad place for "roughly"

Kamchatka is not a typical destination. Tours are sold by local operators, guides, drivers and lodging owners. Schedules depend on weather, the sea and volcanoes. A park can close, a volcano's alert code can change, a storm warning can hit the coast. A mistake is expensive for a traveler: lost airfare, lost vacation days, and sometimes their safety.

Vedar puts all of this in one place: tours, routes, places, fishing, lodging, car rental. There is also a safety overview. The home page shows current warnings from the Kamchatka branch of EMERCOM (Russia's Ministry of Emergency Situations) and a volcano board based on KVERT and the Kamchatka branch of the Geophysical Survey, with a source on every line. Vedar itself is neither a tour operator nor a travel agency. Tours are run by local operators under their own names, and the portal is free for travelers.

At the center of the portal is Vedar's AI agent. You can talk to it on the website, in Telegram and in MAX (a Russian messenger).

What the AI agent does

Its job is simple: help a person plan a trip and get them to a request that a real operator will handle. To do that, the agent:

asks about season, dates, group composition and preferred physical difficulty;
suggests matching tours, routes, lodging and transport;
shows prices and availability pulled from the database at request time;
warns about anything that may change the plan right now: volcanic activity, park closures, weather;
creates a request, which a human then confirms.

What it doesn't do: instant booking or payments. Vedar currently doesn't process payments at all. Tours are paid directly to the operator.

Here's why it works this way.

Principle 1. The AI is not allowed to generate commercial facts

A language model is good at writing text and bad at knowing current prices. Worse, it can't say "I don't know" exactly when that matters most. Ask it how much an August climb of Avachinsky volcano costs and you'll get a plausible number. Fine for prose, a disaster for commerce. The traveler shows up at the operator with "the bot's price", the real price is different, and everyone loses trust.

So we drew a hard line:

Prices, dates and availability are never generated by the model. The agent receives them as live data from the operators' database and only restates them.
If there's no data, the bot says so. No "estimated cost", no "tours usually cost around...".
Every commercial fact needs a source: a specific offer from a specific operator on Vedar.

We wrote the same policy for external models in our public llms-en.txt: use only real operator offers with a link to the source for prices, and if data is unavailable, say explicitly that it has to be checked on Vedar.

The split is: the model handles dialogue, clarifying questions and explanations; facts come from data. As a result the agent sometimes looks less "smart" than a general-purpose chatbot. But everything it states can be verified.

Principle 2. Human-in-the-loop: the operator has the final say

We could have built "the bot accepted your request, the spot is yours". It's technically simpler and demos better. But it doesn't work in Kamchatka:

the operator knows best whether a trip will happen; weather, sea and helicopters can't be relied on in advance;
for demanding tours it matters whether the group fits: age, fitness, health;
small operators and guides often have no system that keeps accurate real-time availability.

So the agent creates a request, not a booking. A human operator always confirms it. The traveler knows from the start that it's a request, not a guarantee, and doesn't expect what isn't there.

There is a cost: the answer comes when the operator gives it, not instantly. We think that's an honest trade-off. An instant booking that later gets cancelled is worse than a confirmation you had to wait for.

Principle 3. Operators need a chat, not a dashboard

For the human in the loop not to become a bottleneck, confirming a request has to be easy. We talked to local operators and the conclusion was predictable: they won't open a web dashboard with a login. They live in messengers.

So operators, guides, drivers and lodging owners get a CRM right inside Telegram and MAX:

Requests: incoming requests from the AI agent and the website, confirm or decline;
"Today": what's happening on the current day;
Clients: history of conversations with travelers;
Reports and prices: we're currently finishing the ability to view reports and change prices directly from the chat.

That last item closes the loop. If an operator can fix a price in the same chat where the request arrived, the data in the database stays current, and that's exactly the data the agent shows travelers. "Don't invent prices" only works with live data, and data stays live only if updating it is easy.

Principle 4. Safety is part of the product, not a disclaimer

In a typical travel bot, safety is a "be careful" line at the bottom. In Kamchatka that's not enough. So the agent:

takes volcanic hazards near the destination into account;
reports park and area closures;
reminds travelers to register their group with EMERCOM;
gives the emergency number, 112.

On the website this is visible immediately: an EMERCOM warnings feed with sources, a volcano board with color codes for ash and seismicity, and an SOS section. We explicitly label the board to say the code describes volcanic activity and is not permission to go. A bot must not turn monitoring data into "you're good to go".

Same principle as with prices: the model doesn't invent conditions; it restates data with a source.

Principle 5. Open up to other people's AI agents

More and more people plan trips in a conversation with an assistant rather than on websites. So it matters that the assistant can take our data instead of inventing its own. Vedar is open to external agents:

MCP server at https://vedarai.ru/api/mcp (Model Context Protocol, no auth). Its description lives at /.well-known/mcp.json, and the developer page is https://vedarai.ru/mcp. Through it an agent gets data on current conditions and the safety of places, tours and their actual availability, lodging, gear, transfers, car rental and weather. It can also create requests: a whole trip, a matching request, a tour on a specific date, a chartered vehicle, lodging for dates, and a self-drive rental. A human confirms all of them as well.
Prefilled links: an agent can hand the user a link with the date and number of guests already filled in. The person just checks the details and submits.
llms-en.txt (also in Russian and Chinese), describing what Vedar is, which pages to cite and how to treat commercial data.
A2A (Agent-to-Agent): Vedar publishes an agent card at /.well-known/agent-card.json, so another agent can discover what Vedar can do and talk to it directly.

The key point: an external agent follows the same rules as ours. Prices and spots come from live data, and everything goes through human confirmation. We don't give a third-party model an instant-booking right that our own agent doesn't have.

Lessons

The model/data boundary matters more than the choice of model. Most of the trust in a bot comes not from the quality of its prose but from it not lying about numbers.
"I don't know" is a fine answer. Users forgive it far more easily than a made-up price.
Human-in-the-loop only works if it's convenient for the human. Without a CRM in the messenger, requests would just pile up unanswered.
Safety should live in the same data as tours. Then the bot can factor it into recommendations instead of appending a disclaimer.
An open protocol beats a closed widget. If a user asks someone else's assistant about Kamchatka, we want it to use our verified data, not make things up.
Honest positioning saves headaches. We state plainly that Vedar is not a travel agency, doesn't take payments, and that a human confirms requests. Fewer broken expectations.

What's next

We're finishing operator reports and in-chat price changes and onboarding new partners. The site is updated daily.

Try Vedar and its AI agent at https://vedarai.ru. If you're building a travel AI agent, plug in MCP or A2A.

Questions welcome in the comments, especially on how you deal with hallucinations in commercial data.

Top comments (2)

Hiten Sethiya • Nov 3

forbidding the model from making up prices is the right call. a confident wrong number does more damage than an honest i dont know. we think about the same thing at searchspot, a trip plan is only useful if you can check what its saying

Paul Irolla • Nov 3

The price should come from a lookup, not from the model's memory. Put the tour's price and dates behind a tool call the agent reads when it answers, and it has nothing to guess. Without that call, the agent answers from memory, and that's how a price gets invented.

DEV Community