The Internal AI Hackathon Playbook

Here is a pattern we have seen enough times to bet on it. A leadership team spends weeks deciding which AI project to fund, picks something strategic and client-facing, and pours three months into it. Meanwhile, two floors down, an accounts clerk has quietly built a little agent that drafts the weekly debtor chase emails and saved herself a full day a week. Nobody in the strategy meeting knew it existed.

The best AI use case in a mid-market business is almost never the one the leadership team guessed. It is a workaround someone built to survive their own workload, and it is invisible from the top. An internal AI hackathon is the cheapest, fastest way to drag that knowledge into the open. This is how to run one so the ideas that surface actually turn into something, instead of dying as a demo everyone applauds and forgets.

Why a Hackathon Beats a Committee

A committee reasons about where AI should help. A hackathon finds out. The difference is that the committee is guessing from the outside, and the hackathon is asking the people who feel the pain to show you where it hurts.

There is a second thing a hackathon does that a committee cannot: it builds capability while it runs. Every person who spends two days getting an agent to do something real comes out more AI-enabled than any training course would make them. You are running a discovery exercise and an enablement programme at the same time, and the enablement half might be worth more than the ideas. The progression from AI-literate to AI-first that this kicks off is worth reading alongside this: AI literate, AI enabled, AI first.

It also surfaces the enthusiasts. After a hackathon you know exactly who your AI champions are, because they are the ones who could not stop building. Those people become the core of everything that follows.

Who Should Be in the Room?

Mix the people who know the problems with the people who can build. The most common way a hackathon underdelivers is stacking it with technical people who build clever things nobody needed, or stacking it with operators who have great problems and no way to prototype. Neither group finds the good ideas alone.

So pair them deliberately. Put the estimator who hates the quoting process next to someone who can wire up an agent. Give the admin team a builder for the day. The magic is in the conversation between someone who understands a process in their bones and someone who can turn it into a prototype in an afternoon. That pairing is where a vague "this is annoying" becomes a working thing.

Keep it small and keep it real. A dozen people from across the business beats fifty, and problems drawn from your actual audit findings beat abstract brainstorming. If you have run the AI audit, you already have a backlog of candidate problems to seed the room with.

Setting the Rules So the Prototypes Are Usable

Two rules do most of the work. First, every team solves a real problem the business actually has, ideally one they feel personally. No toy demos, no "wouldn't it be cool if". Second, every team has to run their prototype on real messy inputs before they present, not the one clean example that happens to work.

That second rule matters more than it sounds. The whole failure mode of hackathons is the demo that works on the happy path and falls over the moment it meets a real client's rambling email or a spreadsheet with merged cells. Forcing teams to test on the ugly inputs turns a magic trick into an honest signal of whether the thing is real.

Give them guardrails, not a blank cheque. Read-only access to real systems, a sandbox for anything that writes, and a clear line they cannot cross with client data. You want people building freely inside a fence, and the fence is what lets you say yes to speed. The governance model for exactly this is freedom inside guardrails.

Judging: What Separates a Demo From a Build?

Judge on whether it can survive contact with real work, not on how slick the demo was. The most polished presentation is often the least production-ready, because the polish went into the pitch instead of the plumbing.

The questions that actually predict which prototypes graduate are unglamorous. Does it hold up on the ugly inputs, or only the clean one? What is the cost of it being wrong, and does it fail loudly or silently? Who would own it if it shipped? Is the data behind it reachable without a six-month project? A modest tool that reconciles invoices and flags the ones it is unsure about will earn its keep for years. A dazzling demo that summarises client calls but has no owner and no error handling will be dead in a fortnight.

Score it like you would any agent, on accuracy, completeness, and safety, rather than on applause. The full rubric for that is in how to evaluate AI agents. The demo and the build are rarely the same project, and a good judging round is where you tell them apart.

From Prototype to Production Without Losing the Momentum

This is where almost all the value is won or lost. Everyone goes back to their day job on Monday, the energy fades, and by Friday the winning prototype is a fond memory. The single thing that prevents this: before anyone leaves the room, every winning idea gets a named owner and a defined next step, with time actually carved out of that person's week to do it.

Not every winner should go to production, and that is fine. Leadership's job at level ten is to look at the prototypes and decide which two or three are worth hardening, securing, and scaling, and to say a clear no to the rest. Three prototypes taken properly to production beats ten that linger as half-finished experiments cluttering everyone's mental load.

The path from here is a loop, not a launch: the winners you pick become your pipeline, and the next problem identification, the next prototype, the next hardening pass all draw on what this hackathon taught you. Choosing which one to ship first has its own logic, covered in how to choose your first AI project.

What Usually Goes Wrong

Three failure modes, all avoidable. The room is all technical, so the prototypes are clever and useless. The demos are judged on polish, so the wrong ones win. And nobody owns the follow-through, so the whole thing evaporates. Notice that none of these is about the technology. A hackathon fails on the human logistics around it, not on the models, which is oddly reassuring, because the logistics are entirely in your control.

Where to Start

You can run a useful version of this with a dozen people, two days, and a backlog of real problems from your audit. Block the dates, pair your operators with your builders, insist on real inputs, and reserve the last hour for assigning owners to the winners. That is a hackathon that pays for itself.

If you want help designing and facilitating it, and turning the winners into production systems that hold up, that is exactly the kind of engagement our Deep Dive leads into: we help you find the work worth doing, then build the two or three that matter most.