Bootstrap · First stage of your AI journey
Agentic AI hackathon
A fixed-timeframe hackathon where cross-functional teams build a working AI agent against a realistic brief, then demo it live. Run it over a few intensive days or part-time across a month, on our learning scenario or one of your own use cases.
Reading about agents is not the same as building one
Before you can sensibly decide which AI use cases to fund, the people making and challenging those decisions need a feel for what agents can actually do inside your organisation. That feel does not come from vendor demos, which are built to show the happy path, and it does not come from a slide explaining what a tool call is. It comes from building an agent.
When organisations skip this step, the same problems tend to appear later, usually at a more expensive moment:
- Knowledge stays theoretical. People can explain retrieval or multi-agent orchestration in a meeting, but nobody has had to decide how to split a policy library into chunks, or what to do when a tool call lacks permissions.
- The friction turns up in production. Workstation proxies, model access approvals, cloud permissions and data policies all slow real AI work down. It is far better to hit them during a hackathon, when the only thing at stake is a demo, than in the first project with a delivery date.
- Expectations drift in both directions. People who have never built an agent either assume it will do everything or dismiss it as a toy. Both views make the next conversation about budgets harder than it needs to be.
The research points the same way. In BCG’s 2026 AI at Work survey, 72% of respondents said the skills expected of them had shifted, yet only 36% felt they had received adequate upskilling. The previous year’s edition found that 79% of employees who had more than five hours of training were regular AI users, against 67% of those who had less. Hands-on time is what moves people from curiosity to capability.
Source: BCG, AI at Work: Why Strategy Matters More Than Tools (2026); BCG, AI at Work 2025: Momentum Builds, but Gaps Remain (2025)
A real brief, a fixed deadline, and a live demo at the end
The hackathon is our entry point into the Bootstrap stage. Like our other pre-defined engagements, you know before you start what will happen, who needs to be involved and what the end looks like.
Small cross-functional teams each build a working agent against the same brief, and at the end every team presents its design and runs it live in front of the others. The structure adapts to you in two ways:
The format. You can run it full-time over a few consecutive days, or you can run it part-time over roughly a month, with teams building alongside their normal work, supported by office hours, and coming together in person for a final sprint before the presentations.
The subject. We can provide a learning-only scenario built around a fictional European company or, if your policies allow it, we can instead build the hackathon around one of your own use cases and your own data, which makes the result more directly useful but needs more preparation.
There is one thing we deliberately leave out: there is no scoring and there are no winners. The brief is not prescriptive, so teams make genuinely different design choices, and five good approaches compared side by side teach a room far more than one winning entry.
Three phases, over a few days or a few weeks
Shaping (before the work starts)
A short workshop to agree the format, the subject and who takes part. We also settle which platform each team builds on, whether that is AWS, Azure or the platform you have already approved, and make sure every participant can reach it from your environment. Access requests are almost always the slowest part of the preparation, so we start them early.
We build inside your own environment wherever possible, using your laptops and your network. That can feel like extra effort, but it is where your real AI work will happen, so it is the right place to find the friction.
Phase one: Kick off
The whole group comes together for the brief. We walk through the scenario, release the materials pack and set out the ground rules. For each platform, we run a focused deep-dive on its agentic services, so teams start with a working picture of the tools rather than a list of product names.
We also put the design questions on the table from the start: whether to use one agent with tools or several specialists, where retrieval should live, how the agent decides what to look at first, what happens when two sources disagree, and how every finding can be traced back to its evidence. None of these has a single right answer. We ask each team to make a choice and be ready to defend it.
Finally, we show what good output looks like, side by side with output that merely sounds plausible, so teams know the standard they are aiming for.
Phase two: Build
Teams build in cycles. In the part-time format, that means a couple of weeks of work alongside the day job, with regular office hours where teams bring whatever they have, however rough it is. In the full-time format, the same cycles are compressed into consecutive days with us in the room throughout.
Our role during this phase is to unblock, to challenge and to explain. We help when teams hit a platform or permission problem, we push back when a design choice has not been thought through, and we make sure people understand why their agent behaves the way it does. By the end of this phase, most teams have an agent running end to end and are tuning it.
Phase three: Sprint and present
The final stretch is best done in person. Teams polish their agents, run dry runs, and prepare their presentations using a common template we provide, so the sessions are easy to compare.
Each team covers its approach and architecture, runs its agent live, and then shows two things: one output it is proud of, and one thing its agent should have caught but missed, with a diagnosis of why. That second part is often the most valuable few minutes of the whole engagement, because it is where the room learns about the limits of retrieval, tools and prompts. Each team closes with an honest reflection on what worked, what did not and what surprised them.
We finish by drawing out the patterns and lessons that came up across teams, together with the participants, so the organisation keeps what it learned.
Questions we get asked
How long does it take?
It depends on the format you choose. The full-time format runs over a few consecutive days. The part-time format runs over roughly four weeks, with the heaviest time commitment in the final in-person sprint. Both need a short shaping phase beforehand, mostly to give access requests time to clear.
Do you need access to our data?
Not if you use our mock scenario, which is entirely fictional and needs no data approvals at all. If you would rather work on one of your own use cases with real data, we can do that where your policies permit it, and we will work within whatever controls your data and security teams set.
Who should take part?
A mix of people works best: engineers and architects, someone with a security or risk perspective, and people who are enthusiastic about building AI agents. Each team needs at the very least one person who is comfortable writing code, but not everyone has to be a developer. Some of the most useful contributions come from people who know what a good answer looks like, rather than how to code one.
Which platforms and frameworks do you use?
We have run it on both AWS and Azure, using their managed agent services, with teams writing in Python or Typescript and using open-source frameworks such as LangChain and Strands. If your organisation has already chosen a platform, we will run it there.
Can it run remotely?
Largely, yes, especially in the part-time format, where kickoff and office hours work well online. We strongly suggest holding the final sprint and the presentations in person. That is where teams compare notes, and the room is noticeably more useful when everyone is in it.
Why are there no winners?
Because a competition rewards the most polished demo, not the most useful lesson. Without scoring, teams are willing to try riskier designs and to talk openly about what failed, which is exactly the knowledge you want spreading through your organisation.
What happens afterwards?
That is up to you. Many participants come out wanting to go further, and that momentum is worth tapping into. Generally, people will be at their most creative after the hackathon, so your organisation will have a list of ideas worth putting through our Use Case Prioritisation exercise.
Ready to get your teams building?
If you want your people to understand agents by building one, rather than by watching someone else do it, this hackathon is for you. Fill in the details and we will send you the full description of this exercise, including the formats, the materials we provide and what you should expect from us. If that aligns with your goals, we can schedule a first call to work out the details.
