We know how much of the week goes on answering questions about events rather than running them. Who's coming on Thursday? How many people declined the partner breakfast? Which of our clients came to the last three dinners? Each one means opening a report, filtering it, exporting it and copying the answer into an email, and by the time you've sent it someone has asked the next one.
At Eventogy I build the APIs that sit behind the platform, and at the moment I'm working on something that should take a lot of that off your plate. We're connecting Eventogy to the AI assistants events teams already use at work, so that instead of pulling a report you can simply ask. Type "How many people declined the partner breakfast, and which of the invited partners still haven't replied?" and the answer comes back in the chat, taken straight from your event in Eventogy.
Why we're building it
When our sales team talks to events leads at banks and law firms, two questions come up in almost every conversation, and they pull in slightly different directions. The first is whether AI can take some of the admin off them. The second, usually asked a minute later, is where their data goes if it does.
We think both are fair questions, and we didn't want to answer one at the expense of the other. So before writing any code we agreed one principle for the whole build: your assistant is a new way to ask Eventogy a question, and Eventogy stays the place where your event is approved, changed and kept.
Your assistant is a new way to ask Eventogy a question, and Eventogy stays the place where your event is approved, changed and kept.
How it works
Under the surface this uses an open standard called MCP, the Model Context Protocol. It lets an AI assistant use another piece of software on your behalf, rather like a browser uses a website, and it is looked after by the Linux Foundation rather than by any one AI company. Most of the major assistants now support it, so the same connection is designed to work across them. So far we've tested it with Gemini and Claude, and we'll be testing it with the other major assistants next.
You connect your assistant by signing in with your normal Eventogy login. From then on, when you ask a question, your assistant asks Eventogy for what it needs, Eventogy checks who you are and what you're allowed to see, and only that information comes back. Eventogy will also only accept a request in the exact form it expects and answers in a fixed format, so anything it isn't expecting is turned away.
What we made sure it can't do
The more interesting decisions have been about what the connection should not be allowed to do, and I want to share three of them.
It can't change anything. Initially the connection is read-only. It can tell you how many people have registered, who is still yet to reply or which sessions are full, but it can't add a guest, cancel a registration or edit an event. Asking a question should never change the record, so any changes must still happen in Eventogy, where they are approved and logged in the way your team already relies on.
It can't see or do any more than you can. Your assistant works with exactly the same permissions you have in Eventogy. If your role only covers certain teams or events, then that is all your assistant can see, and if you can't open something in Eventogy, you can't reach it through a chat window either. We deliberately reuse the permissions your admins have already set up, so there is only ever one set of rules to manage.
It can't contact anyone. The connection has no way to send an email, an invitation or a message. A lot of event data is typed in by guests, so Eventogy tells your assistant that anything a guest or organiser has typed is information to read, never an instruction to follow. And because the connection only answers questions, Eventogy itself has no way to send your data anywhere.
We don't take our clients' security, or the accuracy of their data, lightly, and that is why we aren't simply opening the floodgates. Instead we're taking this one step at a time, making sure each step improves the experience for users and gives them peace of mind. There are a few more decisions like these, and I'll save the rest for when we can show you everything working together.
Where the data goes
The question security teams ask first is where the data goes, so here is the short answer. Your assistant asks Eventogy for something specific, Eventogy returns only that, and the answer goes only to the assistant you've connected. Eventogy doesn't run an AI model to do this, so there is no new AI company handling your data on our behalf.
Control sits with your people on both sides. Your firm's IT team decides which AI assistants your people can use, through your firm's own AI tools, and your Eventogy admins decide who can see what. Each person can disconnect their assistant at any time, and we can switch the connection off for a whole firm. Every lookup an assistant makes is also recorded by Eventogy, including who made it, which assistant and when, and we can provide that record on request.
Why the record still lives in Eventogy
Cem wrote last week about the questions that arrive once an event is over: who came, who approved them, and what changed along the way. Those questions don't change because the work started in a chat window. That is why we're building this around the record rather than the other way round. Your assistant can save you the hours spent pulling reports and answering "who's coming?", while the event, its guest list and its approvals stay in Eventogy, along with the history of who looked at them.
There is a good deal more we want to show, and we'll be sharing it properly very soon, but the principle behind all of it is the one in this piece: your assistant can ask the questions, and Eventogy keeps the record.
Kieran Duff
Senior Developer, Eventogy
Kieran builds the APIs that sit behind the Eventogy platform.
