This is Build Club. We’ve been running it for two months. It is the single highest-signal hour of our week, and it is genuinely easy to copy.
Every Friday afternoon, twenty-something DataRobot employees pile into a Google Meet. Someone shares their screen. They start typing. There are no slides, no demo script, no agenda beyond the first ten minutes. There is, occasionally, a three-minute timer with no music that scares everyone the first time it goes off.
This post is the playbook. If you’ve thought about running something like this at your org and never quite started, the friction is lower than you think. The whole thing fits inside a recurring calendar invite, a Slack channel, and a Google Doc.
What is an agent Build Club?
Build Club is a weekly drop-in session where one person shares their screen and builds something live on your platform of choice, while everyone else watches, suggests, heckles, and helps. The driver doesn’t prepare. The audience picks the use case in the first ten minutes. The build does not have to work by the end. None of that is a bug. All of it is the design.
The closest analog is a Twitch stream, except the chat is full of your coworkers and they have product opinions. The closest internal analog is a lunch-and-learn, except nobody is presenting and the lights stay on.
It works because it inverts the default for technical knowledge-sharing inside a company. Most internal demos are polished, scripted, and one-directional. Build Club is unpolished, improvised, and adversarial in the friendly sense. The driver is exposed in real time. The audience is implicated. Everyone leaves having seen the platform, the friction, and the workarounds at the same fidelity that a customer would see them.
Why this format works for agents
Three reasons, in order of importance.
Building beats watching. The best way to build conviction in any product is to use it yourself against a problem you care about. Documentation, demos, and training videos are weak substitutes for forty-five minutes of hands-on-keyboard with someone next to you. If your org sells, supports, or markets a developer-facing product, the people doing that work need to build with the product regularly. Build Club is the cheapest way to make that happen.
The cross-functional effect is real and unforced. Engineers, PMs, sales engineers, marketers, and security in the same session means immediate product feedback, faster “why does it work this way?” conversations, and fewer dropped handoffs. You do not have to schedule it. You schedule the build, and the conversation falls out.
Live builds surface what specs hide. Watching someone deploy a PII guardrail to their personal Slack bot, in real time, while three other engineers narrate the missing UX, is a richer artifact than any usability study. The bar to surfacing a paper cut is “did the driver struggle with it?” That bar is easier to clear than a Jira ticket.
The agent Build Club format, in detail
60 minutes, broken into three segments.
Minutes 0–10: setup and vote. The host opens. If there’s a driver lined up, they introduce themselves. The host puts a shared Google Doc on screen with a list of build ideas — some seeded ahead of time, some added live during the meeting. The audience votes with plus signs, emoji reactions, or whatever your tooling supports. The idea with the most votes wins. We use a literal three-minute timer for this. It’s mildly stressful and it works.
Minutes 10–55: build. The driver shares their screen and starts building. The audience asks questions, suggests next steps, spots bugs, and goes off on tangents. Tangents are usually fine. The driver narrates loosely as they work. When they get stuck, they say so out loud and the audience helps. There is no expectation that the build finishes. There is an expectation that something interesting happens.
Minutes 55–60: debrief and handoff. The driver summarizes what they built, what broke, what surprised them. The host announces the next driver if one is lined up, or asks for volunteers if not. Someone updates the Google Doc with the recording link and a one-line “what we built” entry. The meeting ends.
That’s it. There is no slide deck. There is no template. There is no post-meeting writeup beyond what gets pasted into the doc.
How to start an agent Build Club
If you’re going to run this at your org, here is the order of operations.
Pick a day and time and hold it. Consistency matters more than attendance. The first session will be small. The second will be smaller. The fourth will start to find an audience. The eighth will feel inevitable. If you cancel because only six people RSVP’d, you are killing the program. Run it with six people. Run it with three. The slot is the asset.
We run Friday afternoons, which is a deliberately low-energy slot. Nobody on our team is doing their best deep work on Friday at 3 PM. They are, however, willing to watch someone else build something weird while they finish their afternoon coffee. Pick the slot in your org’s week where focused work has already collapsed.
Name it something you’d promote. This sounds trivial. It is not. The first rule of Build Club is tell everyone about Build Club, and you cannot enforce that rule if the name is “AI Hour” or “Platform Tinkering Time.” The name needs to be specific, slightly cheeky, and memorable enough that someone hearing it in a hallway conversation can find the Slack channel. Build Club works because it has a name people repeat.
Open a Slack channel. Channel does double duty. Before the meeting, it’s where ideas get dropped. During the meeting, it’s where the chat overflow goes (your videoconferencing chat will not be enough). After, it’s where the recording and the debriefs live. Pin the channel description with the calendar invite, the doc, and the rules. Keep the rules to three.
Ours is #build-club in our internal Slack, but we also have a similar channel in the DataRobot Community Slack. If you’d rather brainstorm before you start your own, that’s the place. The channel is the connective tissue between the weekly hour and the rest of the week, and it’s worth setting up before your first session, not after.
Seed the first few sessions with ideas. A use case that’s relevant to someone in the room. Not a hypothetical, not a stretch demo — something where the driver actually wants the output. Our first session was Carson, an engineering leader at DataRobot, building a digital-twin Slack bot to triage his own unread DMs. The use case was real for him.
“I have Slack problems. Let me see how many unread DMs I have right now. 284 unread DMs on Slack and group channels and thread mentions. It’s a problem.”
Real-for-someone is the bar. If you don’t have a real-for-someone idea, you do not have a Build Club yet; you have a slot.
Pick the first driver. Recruiting a stranger to drive a brand-new program over your back is hard. Find someone on your team who builds for fun anyway and tell them they’re driving the first one. They will say yes if you frame it correctly. The frame is: “you build weird things on the platform, you should keep doing that, but with an audience.” Carson built Carson-as-a-Service (CaaS) without anyone asking him to; the only thing we did was give him an hour of an audience.
Decide what people are allowed to build on. We require that the build use the DataRobot platform. This is a deliberate constraint, and it is the second of our three rules. If you don’t pin it to your platform, drift is inevitable: someone will spend a session on a side project that has nothing to do with the work, and the cross-functional learning effect will dilute. The constraint protects the program. Pick yours.
The three rules
We keep the rules short on purpose. Anything longer than three becomes a policy document.
Tell everyone about Build Club.
Build the thing on the platform.
It does not have to work by the end.
Rule one is the marketing function. Rule two is the constraint that keeps the program useful to the business. Rule three is the permission slip that makes the driver willing to show up. Most internal demo programs die because the implicit fourth rule is “the demo has to work,” and the cost of preparing a demo that works is higher than the value the audience gets from watching it. Removing that rule is the unlock.
Common failure modes
A few patterns we’ve watched almost happen, and how we caught them.
Polishing the format. Someone will suggest a pre-meeting prep doc, a post-meeting writeup, a structured retrospective, a Notion database of outcomes, a points system for drivers. None of these things help. The format is dead simple on purpose. Every layer of process you add reduces the number of people willing to drive, because the lift to drive goes up. Resist the urge to add infrastructure.
Pre-recording the build. Someone will, in good faith, propose that the driver prepare and rehearse so the session goes more smoothly. This is the same thing as canceling Build Club. The whole point is the unpolish. A driver who has rehearsed is doing a demo, and demos are exactly what your org already has too many of.
Letting the audience get passive. If the chat goes quiet, the host has to fish. Ask the driver out loud why they made a choice. Ask the room if anyone has hit the same friction before. Ping a specific person who knows something the driver doesn’t. The audience-as-help is the format’s value, and it doesn’t sustain itself without a host who’s willing to be slightly annoying about it.
Theming too tightly. We rotate themes loosely (productivity, security, enablement, engineering tooling, and back around) so the series builds a thread. We do not enforce themes. If the audience votes for a use case that has nothing to do with the announced theme, the audience wins. The theme is a serving suggestion, not a constraint.
Letting drivers self-select for skill. The temptation is to recruit your best builders every week, because their sessions are the most impressive. This is a trap. Your audience needs to see normal people stumble through the platform too, because that’s what your customers are actually doing. We’ve had drivers admit on camera that they have no idea how to navigate parts of our product. Those sessions surface more useful product feedback than the polished ones.
What you should expect
The first session will be rough. The driver will get stuck on something random, the audience will be tentative, and at least one tool will fail in a way nobody anticipated. This is good. It validates the format. The polished version of the first session is the version where nobody learns anything.
By the fourth or fifth session, you’ll start to see the second-order effects. Product requests will get filed without anyone formally filing them. Engineers in different parts of the org will start collaborating on side projects that came out of a Build Club tangent. New hires will start volunteering to drive, because they want the exposure.
By month two, the program runs itself. The driver queue is full. The Slack channel has its own culture. The Google Doc has a section for next week’s ideas that fills up without anyone prompting it. You will spend more energy choosing which idea to vote on than you spend organizing the meeting.
A note on what to build with
We use DataRobot because we work at DataRobot, and the constraint that the build uses our platform is the constraint that keeps Build Club aligned with the business. Whatever platform you pick, the criterion is the same: it needs to be a thing your org actually uses, and it needs to have enough surface area that a person can do something interesting with it in 45 minutes. Agent frameworks, MCP servers, the LLM gateway, eval tooling, observability — anything that an engineer can wire together against a real problem qualifies.
The next four posts
The rest of this series is the proof of concept. Four recaps, one per theme, each anchored to a session that actually happened.
Productivity, where Carson built a Slack-listening digital twin and we deployed a PII guardrail to it live, on camera, after someone sent it a fake password. Enablement, where Zach started building a Confluence hygiene bot to triage the kind of stale internal docs every enterprise has too many of. Engineering tooling, where Luke and Madeleine pointed an agent at our monorepo to audit code ownership without a single hand-written tool. And security, where Shreya and Brian spent an hour stress-testing what a VPN troubleshooting agent should and should not be allowed to do.
None of those sessions had a prep doc. All of them produced something we’re still using. That is the entire pitch.
The first rule of Build Club is tell everyone about Build Club. If you start one, we’d like to hear how it goes — drop into #build-club in the DataRobot Community Slack and tell us what you’re building. If you want to watch ours before you run your own, the recordings and idea pool live in the same channel.
Build Club, not Fight Club.
The post A playbook to run an agent Build Club appeared first on DataRobot.