Set Up Your Event Agenda by Asking, and Check What It Removes

You have a programme somewhere that is more true than the official one.

It is a spreadsheet. Or a doc called “agenda FINAL v3”. Or a WhatsApp thread with the speaker who has moved her slot twice.

The website shows one version. The app shows another. The printed insert in the lanyard shows a third, and that is the one people believe, because it is laminated.

The agenda is the most edited thing in your event. It changes until the morning of. That is exactly why setting it up by asking is useful. It is also why there is one trap worth knowing about before you start.

What does “set up your agenda by asking” mean?

It means you type what you want in plain words, and the agenda changes.

Presso Events has an MCP event app for organisers. MCP (Model Context Protocol) is the open standard that lets Claude or ChatGPT use outside tools. You connect the event app once, then you talk to your event.

So instead of hunting for the right screen, you write:

Add a 40-minute panel at 14:00 on day one, on the Main Stage. The two speakers from this morning’s email are panellists. I’m moderating.

Behind that sentence, the agenda holds four things:

• Sessions. A title, a description, a start and end time, and optionally a track and a room.
• Speakers. Name, headline, company, bio, photo and links. Written once, attached to as many sessions as you like.
• Roles. Each speaker on a session is a speaker, moderator, panellist or host.
• Stages. On a multi-track event, these become the columns of the timetable, in the order you set.

Every session also has a status. Only published sessions reach attendees. So you can pencil in the 16:30 slot you have not confirmed yet, and nobody sees it until you say so.

What do attendees see?

A link. Nothing to download.

The attendee side is a Progressive Event App: the event runs in the browser on whatever phone they already have. A ticket holder opens it and sees the agenda by day, in the event’s own time zone, with speakers on each session and stages laid out side by side. They can mark the sessions they plan to attend.

The agenda is for ticket holders. Someone without a ticket cannot browse your programme by guessing the address.

When you change a session by asking, the attendee view changes too. There is no second copy to update. Which is the whole point of the laminated-insert problem: three versions exist because three places hold their own copy.

What is the trap with bulk agenda updates?

Here is the pattern. Once you see it, you will see it everywhere.

The replace-all that looks like an append.

Some updates work by saying “make it look exactly like this”. That is the right design for an agenda. You paste in the whole programme from your spreadsheet, and the event matches it. Nothing stale is left over from last week.

Now picture someone, or something, that thinks it is adding one session. It sends one session. The tool makes the event match.

Your programme is now one session long.

We built it that way first. Our agenda tool is called set_agenda, and in its first version a removed session was gone for good. It was a very obedient tool. That was the problem.

You have this somewhere, I would bet on it. The import button that overwrites the list instead of adding to it. The “sync” that faithfully copies a deletion from the wrong file. The shared sheet where someone pasted over the master. Each one does what it was told, at a speed no human could match.

Setting things up by asking makes this sharper, not softer. A language model reading “set” as “add” will be completely confident about it.

How do you make a bulk update safe?

Three fixes, all copyable, whatever tool you use.

1. Preview before you write. Ask for a dry run first. Ours returns what would be added, updated and removed, with every removal listed one by one. Nothing is written. If your tool has a preview, use it. If it does not, export first.

2. Make the confirmation a number, not a yes. Our tool refuses to remove sessions unless the request states exactly how many will go. Not “yes, I’m sure”. The number.

Here is why. Anything that misread “set” as “add” will tick a confirm box with the same confidence it made the mistake. It cannot invent “37” by accident. So the count catches the error the yes would wave through.

When a person asks you to approve a bulk change, ask them the same question: how many will this remove?

3. Delete softly. Removed sessions stay in the database, hidden. Send the session again and it comes back, with its speakers attached and every attendee’s pick intact. A mistake becomes an undo, not a rebuild from the spreadsheet you hoped you still had.

The MCP specification has its own version of this idea. A tool can mark itself as destructive, so the app running it knows to take more care before calling it (MCP specification, tools). The spec also tells clients to treat those markings as untrusted unless the server itself is trusted. That is the right instinct. A label on the tool is not a substitute for a check inside it.

Quick answers

Can I set up a whole conference agenda in one go? Yes. Paste or describe the full programme, with speakers and stages, and it is written in one request. Preview it first.

Can I change one session without touching the rest? Yes. Single-session and single-speaker changes are separate requests, so a late swap does not resend the whole programme.

Do attendees need an app? No. They open a link in their browser.

Will attendees see a session I have not confirmed? No. Only published sessions reach them.

The rule to keep

Before any bulk change to anything that matters, your agenda, your attendee list, your mailing list, ask one question:

What will this remove?

Then make the answer a number, and check it.