Autonomous Humans: running an events program end to end

A program to teach AI, and no software to run it

Autonomous Humans is an initiative with a simple goal: help people who don’t write code learn to use AI in their work. The teaching happens three ways: courses you can take, cohorts that move through the material together, and a rolling slate of online events. A session for finance folks one week, one for People & HR the next, a briefing for executives after that, and every one of them is supposed to clear the same quality bar.

Running that slate turns out to be its own job. A dozen sessions are in flight at any moment, each at a different stage, several live in the same week, none allowed to slip. Plenty of platforms will host one event well: a page, a registration form, a reminder sequence. Luma’s help center, where these sessions already take registrations, documents event pages, ticketing, check-in, and blasts in depth, and offers only workarounds for multi-session programs; planning stages, speaker approvals, and cohorts appear nowhere. The operator’s actual day is triage across the slate, and the thing they manage survives in a spreadsheet and their memory. That gap is what we prototyped against, and the position it argues is the title of the next section: the program, not the event, is the unit you operate.

The prototype came out of one of our design sprints, and it’s an exploration rather than a shipped product, so read it as “here’s the problem, and here’s what a better version might do.” The screens are real; the company, people, and numbers inside them are placeholder data, which is worth saying now because I’ll be quoting those screens as we go. First the home screen, then the route every session walks, then how a decision arrives with its paperwork attached.

The home screen is the program

The obvious thing to build is a beautiful single-event page plus a list that links out to each one. The prototype does the opposite. The home screen, labelled All events, lays the entire program out as one table: one row per event, ordered by date, the whole slate visible at once. An operator’s day is triage across that slate: which sessions are healthy, which are behind, what goes live this week. A tool that makes you open ten pages to answer “how are we doing?” doesn’t survive that day.

The vocabulary on the screen carries the cohort model. A Series is a theme that travels: AI Skills, AI in Action, Tool Briefings, each a format that can run for finance one month and HR the next without losing its shape. Cohorts say who each session is for, by function (Accounting, Manufacturing, Sales, People & HR) or by seniority (Executives). A row reading “AI Skills: spring kickoff for finance” tells you what it is, who it’s for, and how it fits the rhythm, without opening anything. The tabs across the top finish the scan: All 10, Published 2, Confirming 1, Planning 5, Past 2, all placeholder counts. Before you’ve clicked, you know half the program is still upstream.

Every session walks the same route

With one session, quality is whether it went well. With ten, quality is whether the tenth is as good as the first, and that’s where programs quietly rot. The prototype’s answer is structural: the Progress column tracks every event along an identical route: planned, platform set, speakers confirmed, published, live. The app’s own description of a cohort compresses the intent into four words:

Different rooms, one high bar.

One program, one route (placeholder data). Because every session walks the same path, one glance down the column shows which rooms are on track and which are stalling.

Because every session walks the same path, one glance down the column tells the operator which rooms are on track and which are stalling, whatever cohort they serve. Registration rides alongside as a separate health signal (360 of 500 for one session, 388 of 400 for another, 0 of 250 for one not yet open), synced in from Luma with a small “Luma · synced 2m ago” line, so sign-up pace never gets confused with operational progress. The palette stays muted, green only for done, because this is a screen someone lives in all day.

A decision arrives with its paperwork attached

The bar you can see in the Progress column gets defended in one concrete place: approvals. Speakers, organizers, and behind them co-hosts and member companies all pass through the same review before they touch a room. Opening a speaker shows their headline, their areas of expertise, whether they’re actually shipping the thing they want to talk about, a short vibe-check note, and whether they’ve accepted the Code of Conduct. You read it, then Approve or Deny. The product’s own reason for vetting this way, the talk earns the room because the work is real, is the quality bar in a sentence. The queue sits on the nav with a live count, so the step most likely to stall an event stays in sight until it’s cleared.

The other half is what happens the instant you decide. Approving a speaker doesn’t hand you a blank email: the app drafts the confirmation, fills in the event, cohort, date, and organizer, and either sends it or holds it for a glance first. The decision and its downstream labor arrive as one object. Every routine message around a session works the same way (the call for speakers, the confirm-or-decline, the ask to a co-host, the attendee reminder), each one set once to send automatically, draft for review, or stay off.

The operator keeps the judgment calls

Run this program on the tools that exist and the operator does everything: approve the speaker, then write the confirmation, update the page, chase the co-host, send the reminder. The software records the decision and leaves all the labor with the person, which is where the afternoons go. This prototype splits the job the other way. The operator keeps the judgment calls (does this speaker earn the room, is this session ready to publish), approvals are where the bar is defended, and agents carry the paperwork between those calls. That is the same split our whole prototype gallery draws: the person supervises the work instead of performing it. There’s no “enable AI” switch; delegation is set per message type, in the units of the actual job, the way a manager decides which tasks a capable report can run alone. That division is what lets one person hold ten events to the same bar without the afternoons disappearing into email.

Luma stays the front door

If the program is the unit, one consequence follows immediately: don’t rebuild what already works at the event level. Attendees discover sessions and RSVP on Luma, which handles pages, ticketing, and reminders well, and those registrations sync back into the program view as the “360 / 500” beside each event. Rebuilding a sign-up flow that already works would add surface without adding value; the prototype’s job is to be the one place that sees every event, and it leaves the front door to the tool attendees already know.

Vibes feeds the next session

The second consequence is that a program can improve in a way a single event can’t. After a session, attendees flag what mattered in a surface called Vibes: who to invite next, what to schedule and where, which parts of the material earned a follow-up. Those signals route into planning for the next event in the series, so a good night becomes an input to the planning screen instead of a memory in the operator’s head, and the bar can rise from one session to the next instead of merely holding.

What we’d validate next

The initiative keeps teaching: more cohorts, more functions, the same bar. The prototype’s job was to find the shape of the software before anyone commits to building it, and the shape it found is specific: the program as the unit, an identical route every session walks, approvals where the bar gets defended, and agents carrying the routine work between an operator’s decisions. What we’d validate next is the operator’s actual Tuesday: whether triage across the All events table really retires the spreadsheet, and which message types earn “send automatically” first. It’s also a working example of how we think about software generally: design around one team’s actual job, then build and run it for them like a product. Open the prototype at the top of this post and walk the All events table; if your program lives in an events tool plus a spreadsheet today, the comparison takes five minutes.