Published
A client told me recently that he’d spent four hours trying to build an agent for a task that simply couldn’t work, technically. My honest answer: I could have told him that in four minutes.
That’s exactly why every good agent project starts not with building, but with an honest feasibility check – and in client projects, I use a format for exactly that purpose, one that keeps proving itself in practice: the agent hackathon.
The Principle: Feasibility Before Full Build
An agent hackathon is not a contest for the prettiest demo. It’s a method for honestly clarifying, in a short amount of time, whether an idea actually holds up technically – before weeks go into a live connection to a SQL server, Snowflake, or an ERP system that turns out to be unnecessary in the end. Two days deliberately act as a hard deadline: they keep an idea from getting lost in endless scope discussions before anyone has even tested whether it works.
Why Business and IT Have to Show Up Together
The most important building block is team composition, not technology. Microsoft’s own guidance for Copilot Studio projects names core roles that include a project lead, solution architecture, the actual agent development, someone for success metrics, and someone for security and compliance – considerably more than “one business person plus one IT person.” Still, the basic rule is what matters: business brings process knowledge, test questions, and the judgment of whether the result actually holds up professionally. IT, or the platform team, brings the technical implementation and a realistic sense of what’s achievable at what effort. Neither side can carry the format alone – that’s not an exception, it’s the permanent way agents get built inside organizations.
The Lead-Up Matters More Than the Day Itself
A good agent hackathon starts two to four weeks before the actual event, not on the morning of day one. Every team submits a concrete process in advance – one that’s actually running manually today – and answers four guiding questions: What does the current process look like? What should it look like afterward? What exactly hurts about it today? And what data sources would an agent need for it? The submissions get prioritized, so that hackathon day only works on ideas with a realistic chance – not on the spontaneous idea someone comes up with at nine in the morning.
The Feasibility Check First, Not the Build
The core of the format is a principle that matches Microsoft’s own approach to risk assessment: instead of building the live connection to a core system right away, the team first uses the Agent Builder with sample or exported data to check whether the underlying task is solvable at all. Only once this short check comes back positive – Microsoft calls the concept a time-boxed “spike” for the riskiest open question – does the next step follow into Copilot Studio with real connectors, multi-step flows, and governance. If it comes back negative, that’s not a failed hackathon day, it’s an early, cheap pivot – long before anyone has made a commitment to a finished feature.
A Two-Day Structure That Has Proven Itself
Day 1 – from idea to proven feasibility: Kickoff and a short platform introduction, then every team presents its pre-submitted idea in a few minutes. Next comes the actual feasibility workshop: Is the necessary data source available, is there system access, is the rule clear enough for an agent or does it need human judgment, are there compliance issues that stop the project right away? After that, every team defines the smallest meaningful test slice – not the whole process – and starts on the first prototype, tested against sample or exported data.
Day 2 – from prototype to decision: Continued building and testing with real questions from the business side, supported by fixed points of contact from the platform team. In the afternoon, every team shows a live demo, evaluated against the same three criteria: business value, technical feasibility, and realistic effort through to production. Every idea ends with one of three decisions – pursue, defer, or discard – and one specifically named person who actually owns that decision afterward.
The Pitfalls That Come Afterward
The hackathon day itself is rarely the problem. Three things decide whether a good demo actually turns into something production-ready:
- Scope that’s too big. Teams try to map the entire process instead of a single, meaningful slice of it. Facilitation that narrows the scope early matters more than extra build time.
- Synthetic or missing data. Test data that has nothing to do with production reality reveals little about whether a prototype will actually hold up later. Preparing a handful of anonymized, topically matching datasets pays off more than any extra hour of build time.
- No owner assigned afterward. The most reliable reason a good prototype still never makes it to production: no one is concretely responsible for it after the event. That’s why the owner question belongs at the end of the agenda, not in an email sent out sometime after the event.
What Typically Comes Out of a Format Like This
Across multiple runs, the same use-case categories keep coming back, regardless of industry: a document or contract review agent that checks incoming paperwork against a fixed set of criteria; a hotline or support agent connected as the first point of contact to an existing ticketing or knowledge system; a qualification agent that structures and pre-assesses incoming requests or business cases before a human decides; an onboarding agent that guides people step by step through an internal process; and an information agent that answers questions against a data export first, before anyone even thinks about a live connection.
If you want to set up a format like this for several teams or departments on a fixed date, that’s a job for Individual Projects.
The full talk this format comes from is on YouTube: „Copilot Studio & Agents: So bereitest du dein Unternehmen vor” (in German; m365 Show, Mirko Peters’ channel).
Sources: Microsoft Learn – Organisieren von Hackathons (Power Platform) (in German), Design training programs and events, Build your team, Define value before you build your agent, Prioritize risks and identify workarounds, Agent in a Day; AngelHack – The AI Internal Hackathon Playbook, How To Run An AI Agent Hackathon: A 2026 Playbook.
