The agent meetup format that works is not a talk. It is a demo night: five people, ten minutes each, running something live in front of a room that is allowed to ask hard questions. The reason is simple — agent systems are unusually good at looking finished in a slide deck and unusually bad at surviving contact with an audience.
Why live demos beat slides here
An agent is a loop with tool access and a budget. Almost everything interesting about it — how it recovers from a bad tool call, what it does when the retrieval returns nothing useful, how much it costs to answer one question, how long a user waits — is invisible in a static walkthrough and obvious within ninety seconds of watching it run.
The failures are the content. A demo where the agent picks the wrong tool, loops twice and then recovers teaches the room more than three polished slides about architecture. Presenters should be told this in advance, or they will hide it.
The ten-minute structure
- One minute: the task. What is this agent for, and what did people do before it existed.
- Five minutes: run it live. Actually run it. Recorded fallback allowed, but only as a fallback.
- Two minutes: the plumbing. Framework, model, tools, and the one design decision that mattered most.
- Two minutes: what broke. Non-optional. Every presenter names at least one thing that does not work yet.
Then questions from the floor, kept to the demo just shown. The "what broke" section is what turns a demo night into a group that learns; without it you have a showcase, and showcases attract audiences rather than participants.
Questions that make the room better
- What does one run cost, and how do you know?
- What happens when the tool call fails — retry, fall back, or surface the error to the user?
- How do you evaluate it? What is in the eval set, and who wrote it?
- What is the worst thing it has done in production?
- How long does the user wait, at the median and at the tail?
- What made you choose that framework, and what would make you leave it?
These questions are worth putting on a slide at the start of the evening. New attendees do not know what is fair to ask, and printing the norms saves the first twenty minutes.
Practical logistics
Test the network before anyone presents. An agent demo with tool calls needs working outbound access, and venue guest wifi that blocks non-standard ports has ended more demo nights than bad code. Have every presenter run once, on the venue network, before the room fills.
Cap it at five demos. Six runs past the point where people are still asking good questions, and the last presenter deserves better than a tired room.
Keep a laptop on the projector between demos so switching costs thirty seconds rather than five minutes of adapter hunting.
Finding or starting one
Agent-focused groups have grown quickly in most large cities, often demo-first and explicitly vendor-light. If nothing is running near you, a demo night is one of the easier formats to start, because the barrier for presenters is low — anyone with a working prototype has ten minutes of content, and most people are relieved to show something unfinished if you tell them that is the point.
See which AI meetups are coming up, or find the AI community in your city.