In September 2025, Google Cloud ran a single-day hackathon in Bangalore called Agentic AI Day. It set the Guinness record for "Most participants in an agentic AI hackathon". Around 2,000 developers across 700+ teams in one room. Google's own announcement is here.
My job on that event was community-side mobilization. Not the venue, not the platform, not the judging. Just: how do you get 2,000 people to show up.
The answer is boring and it is a funnel. This is the teardown.
Why marketing does not fill this room
A brand channel posts an event. Some fraction of the audience sees it, a smaller fraction clicks, a smaller fraction registers, a smaller fraction shows up. That funnel exists and it works for some events. It does not work for a one-day, in-person, single-city hackathon with a hard cap.
The reason is trust. A developer will register for something on the strength of a brand post. They will travel to Bangalore, block a Saturday, and actually turn up because a person they already trust told them it would be worth it.
Community chapters and educators are that person. That is the entire play.
The funnel, as numbers
Before doing anything, I sketched the funnel and put a rate on each layer. This is the math the whole plan sat on.
| Layer | Rate I planned for | What it took to hit 2,000 in the room |
|---|---|---|
| People reached through a chapter or educator | — | ~8,000 |
| Registered | ~40% of asked | ~3,300 registrations |
| Showed up on the day | ~60% of registered | ~2,000 in the room |
These are planning rates, not measured ones. Show-up on free tech events in India runs lower than most organisers admit — usually 50–65 percent. Registration conversion from a trusted chapter ask runs higher than a cold brand ask, but still nowhere near 100 percent.
Once you have the layers, the plan becomes obvious. Do not send one big message to a hundred thousand followers. Get one specific ask into eight thousand mailboxes, through leaders the recipient trusts.
Slots, not asks
The single decision that shaped the whole rollout was this: every chapter got a slot count, not an invitation to spread the word.
"Chapter X, you have 60 confirmed slots for your members. Send them this link. Registrations close on this date." That is a different message from "please help us fill this event."
A slot allocation does three things a broadcast does not:
- It gives the chapter organiser a target. They know when they are done.
- It gives their members a reason to register now. Slots run out.
- It gives me a per-chapter conversion number, which is the only way to fix underperforming chapters before it is too late.
Who got asked, and why
The two networks that mattered were Google Developer Groups chapters and the Educators community. Both were already active. Both had leaders with a member list that trusted them.
The teams that arrived as organised cohorts almost all came through those two networks. That is not a coincidence. A team of four registers together when one of them saw the ask in a group they already belong to.
What did not work: pushing this to individual developers through official social. It converted, but at a fraction of the rate. The signal-to-noise on a brand handle is bad on any single event.
The re-forecast on day 14
Two weeks in, I pulled the per-chapter registration counts and compared to the slot allocations. About a third of chapters were on pace. A third were at half pace. A third had barely started.
The temptation is to raise the ask to the good chapters and quietly forget the rest. That is the wrong move. Good chapters have a ceiling — you cannot double their allocation and hit it in the same window. But the slow chapters can be unblocked by asking what they need. Usually it was a poster asset, a translated line, or a nudge to their organiser lead.
The re-forecast turned into a per-chapter shortlist of interventions. That is what pulled the funnel back on track by day 21.
If you have to fill a big room
- Write down the funnel with a rate on each layer. If a number is missing, guess and label the guess.
- Do not send one message. Allocate slots to trusted leaders.
- Every ask has to include a slot count and a deadline. Vague asks return vague numbers.
- Pull per-source conversion at the midpoint. That is the only useful re-forecast moment.
- Do not raise the ask on the good sources. Unblock the slow ones.
Why this is worth writing down
A Guinness record is a good headline. It is a bad framework. The record is what happens if the mobilization funnel works and the venue holds. Neither of those is guaranteed. The funnel is the thing you can actually plan.
The same shape works at a tenth of the size. A 200-developer regional hackathon needs the same layers, the same rates, and the same slot allocation. It just needs fewer chapters. Skipping the funnel and hoping a brand post carries the day is why most single-city technical events under-fill.
Related: the attribution schema I use to prove what a community programme returned, and the Apps Script automation that ran the partner side.