The Event Agent That Never Books Anything

Why conference travel admin is worth automating in the first place

Business conferences in our part of Europe do not arrive evenly. There is a batch around May, then a long summer of nothing, then a second batch across September and October, and almost nothing at all between November and March. Inside a batch it can get intense — one event a week, sometimes more.

That shape is the whole reason this piece of automation exists. A workload that arrives in bursts is the worst kind to staff. It is too repetitive to be interesting and too bursty to hire for. And it lands on exactly the people who are already busiest during those weeks, because the people going to the conferences are the same ones running everything else. So we built an AI agent for corporate travel booking – an event organising module of VIS Solutions' corporate assistant – and used it through the May batch.

What corporate travel research looked like before the agent

Before the agent, this was a job for our student assistants, and the process was well understood. Somebody would send them a conference link. They would research accommodation and flights, put together a shortlist, and email it to the person travelling. That person would check the options against what they actually needed, pick one, and finish the booking themselves.

Sometimes it was trivial. The hotel is the venue, the flight is short and direct, the whole thing takes minutes. But the exceptions were frequent enough to matter: searches dominated by itineraries with two or three connections, or a flight with a wait that runs into the next day. Or the venue hotel is sold out, so you need the second-best alternative that is still close enough to walk.

When we built the agent, we did not redesign that process. We gave the agent the student's job description, unchanged.

Why our travel agent proposes options and never books

You send the agent a link to a conference. It works out where and when the event is, finds accommodation and, if you are flying, flights, and emails you back a ranked shortlist with the links you need. Then it stops. It does not book anything, and there is no approval step after which it books anything.

That is a deliberate line, not a place where the build ran out of time, and there are two reasons behind it.

The first is the obvious one, and we have drawn it before. An agent that can spend money is a different category of risk from an agent that can send an email. In our accounting automation the agent prepares everything and never touches e-banking. Booking a hotel and a flight is spending money. Same line, different system — and when the same line shows up twice in two unrelated builds, it stops being a preference and becomes a principle.

The second reason is the more interesting one, and it is about quality rather than about money. The brief a traveller gives is never complete. Something important is always missing from it — and with an incomplete brief, a student and an agent will make exactly the same mistake and confidently reserve the wrong thing. The person travelling is the only one who can look at three options and notice what nobody wrote down.

The travel requirements nobody writes down — and how the agent applies them

Ask anybody in our company what their travel requirements are and you will get the destination and the dates. What you will not get is the set of constraints that everybody holds and nobody states:

Two connections is where we stop. Three to four hours of waiting between flights is the line. Nobody wants to spend a night somewhere in the middle of nowhere just because they are flying. And a hotel two hours from the venue is not accommodation — it is a second trip every morning.

These are universal constraints. They apply to everyone in the company, on every trip, and they are the reason an incomplete brief produces a bad booking.

“So why aren't these hard rules in the agent?

That is the direction this is going. Today you state your preferences in the conversation, and that has an upside of its own. I have a hotel in Barcelona I always stay in for MWC. It is further from the venue than the ranking rules would like, but everything closer is either sold out or absurdly priced during the event. And I know that hotel — I know how to get there from the airport, and how to get from there to the venue. So I tell the agent, and it puts that hotel first. The next version should remember that instead of asking every time, because the same people travel to the same events with the same requirements year after year.

What a booking session with the agent actually looks like

The conversation is short and it is in Croatian, because we are a Croatian company and the assistant talks to us in our own language. Field names and internal plumbing are in English, the way our software has always been written, but nothing an employee reads is.

You paste the link. The agent asks one question at a time, and only the ones it still needs: are you driving or flying, which city are you leaving from, and the dates if it could not work them out from the conference page itself. While it is asking, it is already reading the event page in the background. So by the time you have answered, it usually knows the venue, the city and the dates. It then shows you what it understood and asks you to confirm. If your answer is a correction rather than a yes, it takes the correction and re-summarises. You never have to start again.

Then it searches accommodation and flights at the same time and emails you the result. You get the event summary, then up to three ranked options per category, each with a price and a label — your preferred hotel, the venue hotel, the cheapest option, a direct flight — and the link to complete the booking. If a source cannot be read on the day, that section degrades to a pre-filled search rather than taking the whole session down with it.

Which decisions we give the model, and which we keep in deterministic code

There is one design point in there worth pulling out, because it applies to every agent of this kind. The reading of a web page is done by the model, which is very good at it. The decision about which option is best is not: the ranking is ordinary, deterministic code. We do not ask a language model which hotel is cheapest. Getting the split right between what the model judges and what the code decides is most of the work in a system like this. This is the kind of architectural judgment that separates a working system from one that fails silently—and it is exactly the pattern we have applied across multiple agentic AI implementations.

Dates are where we learned that lesson the hard way. Working out whether a date in a sentence is when the event starts or when you personally leave is exactly the kind of thing a model gets subtly wrong. It took several passes over a single day to make it reliable. And the answer was not a better prompt. It was putting a deterministic layer in front of the model, and letting that layer win whenever the two disagree.

How the same agent builds a conference attendee list for lead generation

Nine days after the organiser, we added a second capability that was not in the original plan at all, and it may be the better half.

Here is the context. When we go to an event, we try to get the maximum out of it. If there is a speaking or exhibiting opportunity we take it, but more often we are simply visitors — and we still need to generate leads. At the largest events there is an app for requesting meetings. At most events there is not.

So we used to ask the student assistants for something else: a list of interesting people, compiled from public sources — the conference programme, the organiser's posts welcoming attendees. Picture, name, position, company. Nothing more. The purpose is as simple as the format: if you get a chance to talk to this person in the coffee break or at the afterparty, take it.

That is what the second module does now. You give it a conference URL — or upload the attendee list if the organiser sent one — and it produces that document, photos included, in the same layout a person used to prepare by hand. We built it to reproduce a real list a colleague had made for a Croatian industry conference. That is a good way to specify this kind of thing: here is what a human produced, make me that.

I want to be honest about how it is used in the field, because the fantasy version of this is misleading. Hunting down a specific named person at a large conference is extremely difficult, and chasing people around is not how we want to behave. The real value is different and smaller: when you are already standing in a group, you know immediately who the important person is. That changes the conversation you are already in. And cold approach at an event remains a genuinely good channel — far less saturated than cold email or cold calling.

The filter rule: when in doubt, keep the person on the list

The list is filtered, and the filtering rule is the part of this system I would defend hardest, because it is a business rule rather than a technical one.

It removes only unambiguous frontline sales roles — the people whose job at that event is to sell to me. Everybody else stays, without exception, including sales managers and commercial directors. And the last instruction in the rule is: when in doubt, keep.

The reasoning is that sales is more complicated than a job title. A sales manager at another company might subcontract us when they are short on resources or need a specialty they do not have. A marketing manager is a potential client for our content generation solutions. And the asymmetry is what matters: dropping somebody useful costs far more than keeping somebody who will try to sell me something. The human reading the list dismisses the second case in one second. Any agent that filters should be built around which of its two possible errors is the expensive one.

There is a joke available here and I will make it myself: a B2B company built a machine to filter out other companies' salespeople.

One conference trip, three modules of the corporate assistant

The event organiser is not a standalone product. It is a module of the corporate assistant, and one conference trip passes through three of them: the organiser finds the trip, the people list prepares the networking, and the travel expense module closes the loop afterwards with the report, the border crossings and the per diems.

That is a far better argument for modular orchestration than any architecture diagram, because it is one trip, three agents, and no human carrying data between them.

What it costs to run and what state the solution is in

We track model spend as a single total rather than per solution, and the total has been remarkably small. There have been months where the corporate assistant and the accounting automation together came in under one euro of API spend. Two honest caveats belong with that: not every month has events to organise, and a large enterprise running this across thousands of travellers will consume far more. We now run enough solutions that per-solution monitoring is something we will need to introduce.

We used it across at least three events in the May batch — Unlock Rab among them — for both the booking shortlist and the attendee list, and we intend to use it through the autumn batch. It took perhaps half a dozen conference sites of testing before it could read all of them. It runs on an office machine that acts as our assistant server rather than on my laptop, for the obvious reason: it has to be available to other people when I am away. It is a web application, so my phone is just another client. Which is the whole point of the scenario I actually wanted — organising the next trip during the breaks of the current one.

I'd call it a functional prototype that is production-ready at our scale, and a capability showcase. Proven on our own operations, which is where we prove a pattern first. This is how VIS Solutions validates every capability we build—on our own books, before we bring it to enterprise clients.

The harder problem next: automating sponsorship and exhibition decisions

Attending an event is the easy half. Exhibiting at one is where the friction lives, and it is the capability I am waiting for.

The failure mode there is a handover problem, and every company has it. A senior knows exactly what they want out of the event but has no time. An administrative assistant has the time but does not hold the requirements. So "check the sponsorship options and tell me what we get" comes back as a summary that still does not answer the two questions the senior asked: do we get a branded stand, and do we get a speaking slot?

What is needed is structured extraction from a pile of unstructured material — sponsorship brochures, conference sites, PDFs. The fields that actually decide it are stand dimensions, the dimensions of the branded sections, the required graphics formats, prices and the payment schedule, whether sponsors receive the attendee list, and whether there is a screen and therefore whether we need to produce a video. That is a task AI is genuinely good at and inexperienced humans are genuinely bad at, even with written instructions.

And that is only after you have chosen the event. Choosing between several candidates is its own structured comparison: topic fit with what we sell, geography, attendee structure, and whether the dates collide with something else we have already committed to.

None of that is built today. The task list the assistant works from has a defined place for it, and it is the next thing I want. The long-run version of this ambition is organising our own events — we run our own conference, CRED — but that is a journey, and what we have today is the first leg of it.

Manual conference travel research versus the event agent

How this pattern transfers to enterprise travel policy and approval chains

A large enterprise arrives at this problem with a travel policy, a booking tool, an agency contract and an approval chain already in place. The adaptation work is to those: the company's own rules and procedures become the constraints the agent applies, and the existing approval chain becomes the human step our design already assumes. The propose-and-hand-over shape transfers unchanged, because it is the shape every enterprise travel process already has. What changes is whose rules the shortlist is filtered against.

The thing I am proudest of is not technically impressive at all:

“I can now organise my next trip while I am on the previous one, without having to wait for anybody or depend on anybody.

That is what this class of automation is actually for. Not removing people from the process — the person travelling is still the one who decides — but removing the queue in front of the decision.

If you have a team that spends weeks every spring and autumn scrambling to organise conference trips while running their day jobs, you almost certainly have a queue problem that looks exactly like this one. The next hard problem—and the one we are building next—is automating the sponsorship decision itself: extracting the terms from a pile of brochures and PDFs so that a sponsor brief actually answers the questions the decision maker asked. Subscribe to the newsletter, and you will see it when it lands.