The Job of Event Technology is to Disappear

Guest post by Michael Lockett, Co-Founder & CTO at Symbiometry, an EventsAir technology partner.

The events industry is in the middle of an AI arms race. Every platform wants to announce the next assistant, the next co-pilot, the next thing that looks impressive in a demo. It’s an understandable instinct. It’s also, mostly, the wrong question.

The right question isn’t what a piece of software can do. It’s whose day actually gets easier because of it.

I’m the CTO at Symbiometry. We build the complex end of EventsAir implementations, the ones that need more than standard configuration will give them. So, when I say “we” in this piece, I mean the people building the thing. Not the people using it.

And here’s who we’re building for.

A planner who’s been awake since five. Who has a venue asking about final numbers, a speaker who’s gone quiet, an inbox with two hundred unread, and a delegate on the phone who cannot eat any of the three menu options. They don’t need a clever tool. They have plenty of clever tools. Most of them are open in tabs they haven’t looked at since last Tuesday.

They need something that took one thing off them, properly, and didn’t ask them to learn a new system to get it.

That distinction matters more than anything else in the current AI conversation. And it leads somewhere slightly uncomfortable for those of us who build this stuff.

Complexity doesn’t go away, it goes somewhere

Mehdi Khalili wrote here in April that EventsAir isn’t interested in building AI for AI’s sake. I’d go further. Building AI for AI’s sake isn’t just uninteresting. It’s expensive, and the bill lands on people who are already tired.

Events are complex. Genuinely, irreducibly complex. A medical congress has abstract review, multi-track programmes, speaker travel, dietary requirements, accessibility needs, badge printing, room turnarounds, three currencies and at least one committee. That complexity isn’t a design flaw. It’s the actual shape of the thing.

You can’t delete it.

You can only decide who carries it.

That’s the whole job, really. Every technology decision, every integration, every workflow, is a decision about where the difficulty ends up. And difficulty behaves like water. Left alone it flows downhill; towards whoever has the least power to refuse it.

Which is usually the delegate. And after them, the planner.

A confusing registration flow, a badge that’s wrong, a session nobody can find, an assistant that must be learned before it helps with anything. These are all just complexity that someone upstream declined to own.

The job is to carry it, not to perform it

I want to be clear that complexity isn’t the enemy. I quite like it. Most good technical people do.

Sitting with a tangled registration flow and working out why it breaks for one attendee type in one currency is satisfying work. Building the integration that makes three systems behave like one is satisfying work. The complexity is where the craft is.

So let it live with us. The builders.

Let it live in the schema, in the integration layer, in the configuration nobody sees, in the careful decisions made months before anyone registers. That’s where it belongs, because that’s where there’s time to think it through properly, and people who chose this.

What it must never do is arrive at the delegate.

A delegate should experience a registration form that makes sense, an email that says the right thing, a badge that’s correct, and a session they can find. That’s it. They should never encounter our architecture. The moment a delegate must think about how the underlying system works, something has already gone wrong upstream.

The same applies to planners, one level up. A planner’s attention should go to the complexity of their event. The programme, the speakers, the room. Not to the complexity of the software that’s meant to be holding it.

Where AI actually fits

Here’s what I think is genuinely new, and it isn’t “AI saves time.”

AI raises the amount of complexity a provider can absorb on someone else’s behalf.

That’s the real shift. Work that used to be too fiddly to justify, the edge case affecting a handful of delegates, the report nobody had two hours to build, the personalisation that would have needed a team most organisers don’t have. Mehdi puts the personalisation version of this well. A planner would happily match every attendee to the right session, but it doesn’t scale, because time doesn’t scale. AI doesn’t have that problem.

So, the ceiling moves. We can carry more, which means they carry less.

But only if we point it in that direction.

Because there’s a version of this that goes the other way, and nobody building software is immune to it, us included. AI gets added because the market expects it. The interface gets busier. The planner ends up with an assistant to learn on top of a platform they’d finally got comfortable with. The difficulty didn’t move downhill from us to the machine. It moved sideways, onto them, dressed up as innovation.

That’s AI for AI’s sake, and you can spot it by asking one question. After this feature shipped, is somebody’s job actually smaller?

If the honest answer is no, it wasn’t intelligence. It was decoration.

Wrong is fine. Confident is the problem.

I wrote about this on LinkedIn a fortnight ago and I’m not finished with it, because I think it’s the part of the AI conversation this industry is least ready for.

A number that looks wrong is survivable. Somebody catches it. A query that fails announces itself, a broken report doesn’t render, a total that’s obviously mad gets challenged long before it reaches a board pack.

Prose doesn’t behave that way. A well-formed paragraph looks identical to a correct one. It arrives in the same typeface as the truth, near midnight, in front of someone who has been awake since five and has no practical way to check it.

So, the question I care about isn’t whether an assistant is clever. It’s whether the person relying on it can audit it.

What that looks like when somebody builds it properly

I should say plainly that Symbiometry is an EventsAir partner, and that I had early access to Planner Assistant while it was still in testing (now available as a Public Beta feature – click here to read more). Read what follows knowing both.

I asked it how many contacts were in an event. It told me 56, and it showed me the two steps it took to get there. Discovering the schema, then running the query.

Opening that up gives you the actual working. Which tables it touched, the SQL it ran, the rows returned, and, more usefully than any of those, the assumptions it made. Every row in the contacts table. No grouping, no filtering, no date logic. Each row treated as one contact record. Current event only. Nothing excluded. Completed in 17.4 seconds.

That’s already more than most tools will give you. But it isn’t the part that convinced me.

I then asked how many of those contacts had uploaded files. And it told me it couldn’t say.

Not a number. Not a confident-sounding approximation. It said the information isn’t held on the contacts table, so it couldn’t answer from there, and offered to go and look at the file records instead.

That refusal is worth more than any correct answer in the thread.

An assistant that will guess is a liability dressed as a productivity gain. An assistant that says “not from here, but I know where to look” is something you can actually work with. When I told it to go and check, it read eight related schemas, worked out the relationships between them, ran the query, and came back with 32 contacts, 57.1 percent of the 56.

Then it added a line I hadn’t asked for. It had counted each contact once, even where someone had uploaded more than one file.

That last sentence is the whole argument in miniature. Double counting is precisely how a report quietly becomes fiction, and nobody notices until a decision has been made on it. The system volunteered which way it had gone.

There’s a toggle in the settings for showing tool calls in the chat, which means a planner who doesn’t want to see any of this doesn’t have to, and one who does can. That’s the correct default. The provenance is always there, the choice about whether to look at it belongs to the user.

None of that is glamorous. None of it demos especially well. It’s the difference between an answer and an answer you can stand behind, and it lives entirely upstream of the person reading it.

Owning the jagged edges too

None of this makes any of it finished, and I’d be doing the argument a disservice if I pretended otherwise.

Mehdi names the problem in his own piece, on his own company’s blog, which is not a common thing for a vendor to do. Jagged intelligence. AI doing something remarkable, then surprising you with a basic mistake. His conclusion is that it’s a reason to stay alert and never treat AI output as automatically trustworthy.

I’d underline that last part and put it on the wall. There’s a line under the chat box saying much the same thing, which I notice they haven’t buried.

Because jaggedness is exactly why the responsibility must stay with the provider rather than travel to the planner along with the tool. An AI-shaped tool can feel effortless while quietly handing the hardest part of the job to the person least equipped to catch it. It gives a confident answer. The planner, reasonably, believes it. Nobody told them that this particular tool is brilliant at nine things and unreliable at the tenth, or which one the tenth is.

That’s not their failure. It’s ours, for building something that looked simple on the surface while leaving the risk out in the open.

Showing the working is how a provider carries that risk instead of passing it on. It’s also worth saying that Mehdi mentions a single AI feature taking more than a month of dedicated security work before it went in front of customers. That’s the least glamorous sentence in his article and one of the most important. Nobody demos a month of security work.

Real simplicity was never the absence of complexity. It’s complexity that somebody competent has taken responsibility for and been honest about. There’s a version of “easy to use” that’s genuinely engineered, and a version that’s just difficulty nobody has been told about yet.

The difference usually shows during the event.

A few positions I’d hold

Some of this is philosophical. Most of it isn’t. If you’re making decisions about AI in your event stack this year, here’s what I’d hold to.

Judge every tool by whose day got easier. Not by what it can do in a demo. If nobody’s workload went down, it was decoration.

Ask what the answer is based on. If a system can’t show you where a number came from, you don’t have an insight. You have a sentence.

Prefer a tool that will tell you it doesn’t know. Willingness to refuse is a design decision, and it’s the one that protects you at two in the morning.

Protect the delegate absolutely. They’re the one person in this whole chain with no obligation to understand any of it. Their experience is the score.

Take the boring foundational work seriously. Clean data, clear ownership, well-structured systems. It isn’t glamorous and it doesn’t demo well, but it’s the only thing that makes the clever stuff safe.

Why it matters

Mehdi ends his piece on the line that events exist to bring people together.

I’d have written the same sentence. Every piece of technology in this industry is ultimately in service of a room where something worthwhile happens.

Nobody in that room should be thinking about the platform behind it. The delegate should be thinking about the talk. The planner should be watching the room, not the dashboard, because the thing they spent nine months building is finally happening in front of them.

That’s what all of this complexity is for. Somebody to carry it. Not to show off, and not to feature in a demo.

AI just means we can carry considerably more of it than we used to.

Which is a genuinely good thing, as long as we remember it’s meant to end up on our side of the wall.

If you would like to learn more about Michael, Symbiometry or Air Intelligence from this article, click the links below:

Michael Lockett | Symbiometry | Air Intelligence