Nobody knew exactly what they were walking into. The epics were teased. The teams were formed. And then, at 3PM on a Thursday, 18 teams sat down — in many cases, for the very first time — to build something real with multi-agent AI.

Teams had four hours to turn a starter framework into a functioning multi-agent application built around a real-world business workflow. No extensions. No theoretical submissions. A valid entry needed at least two agents with distinct roles, real decision logic between them, and a working demo.

That’s the whole point of a hackathon. You can read about agent orchestration all day. You learn something different when you actually have to build it.

What is a multi-agent system, anyway?

Before we get into how it went, it’s worth explaining what teams were actually building — because “multi-agent AI” isn’t just a fancy way of saying “a chatbot.”

A multi-agent system is exactly what it sounds like: multiple AI agents, each with a defined role, working together to complete a task. One agent might analyze an invoice and extract the fields. A second validates the numbers and flags anomalies. A third decides whether it needs human approval. Each one has a job. They pass information between each other. There are real decision points — not just “ask Claude a question and see what it says.”

Teams that tried to dress up a single LLM call as a “workflow” quickly realised that wasn’t going to cut it.

The epics – 10 real-world workflows to automate

Teams chose one of 10 predefined problem statements each designed around a genuine business workflow that’s painful to do manually today. Everything from screening CVs to triaging bugs to processing invoices. Every epic was tackled.

This wasn’t a room full of AI specialists. Engineers, QA leads, product owners, data team leads, tech leads a real cross-section of Gapstars. Nearly half the room had never built a multi-agent system before. Average familiarity was barely above “I’ve heard of this.”

What teams built

LangGraph dominated as the orchestration layer of choice. Claude was the most-used model. And almost everyone went beyond the minimum — building actual UIs, adding risk scoring, wiring up mock integrations. The builds were not simple.

Nobody pretended it was easy. The challenges were genuinely technical: getting agents to pass state correctly, prompt engineering that didn’t collapse under edge cases, LLMs confidently ignoring rules you explicitly told them to follow.

“The hardest part was making the AI work with the rule engine rather than against it, the LLM kept ignoring the severity we set in the Decision Gate and producing its own. We had to be very explicit that certain fields are mandated, not suggestions.” — Thilini Rathnayake, Tech Lead · Bug Triage team

“Pausing a LangGraph run for human approval without bringing in a Postgres checkpointer — we landed on a hard-stop sink node and a force_pass_gate flag re-injected via session state. Took a few iterations to get right.” — Aadhil Rushdy, Data Team Lead · Recruitment Screening team

These aren’t beginner problems. These are the kinds of decisions real engineering teams wrestle with in production. The fact that people were solving them in hour three of a hackathon says something about the level in the room.

What surprised us

Every single team had something working by the time the build phase ended. That’s the number worth sitting with.

 Before the event, average self-rated familiarity with multi-agent AI sat at 2.6 out of 5. After the hackathon, the numbers moved significantly — and in one direction. That’s not a small shift. Confidence here isn’t abstract — it’s people knowing they can sit down on a real project and actually build something.

Cross-functional teams — engineers pairing with QA leads, product owners jumping into architecture decisions — seemed to gel particularly well under pressure. When nobody is the “AI person,” everyone has to figure it out together.

The results also showed a clear difference between teams that had engaged with the preparation and those that started cold — a useful lesson for future enablement initiatives.

What this means for our clients

The ability to build AI-native products does not come from adding a single AI specialist to a conventional team. It comes from creating engineering teams that understand how to design workflows, validate outputs, manage exceptions, and embed human decision-making where it matters.

This directly supports the Gapstars proposition. 79% of participants either have a specific workflow in mind or can see the potential for real client applications. Some of the ideas that came out were directly tied to client delivery — automated QA pipelines, project health monitoring agents, CV screening tools that teams could actually deploy. One participant built the hackathon solution they’d want to pitch to their own client the next week.

What happens next

The appetite is clear. People want to keep building. What they need is the infrastructure to make that possible — better tooling, more practice, a community to learn alongside.

That’s exactly what the Data & AI Guild is being built to do. The hackathon was one moment in a longer journey. What comes next is about making the conditions for this kind of work sustainable — not a once-a-year event, but something woven into how our teams grow and what they’re capable of delivering.

The hackathon was not the finish line. It was evidence of what becomes possible when AI capability is embedded into the way teams learn, collaborate, and deliver.