Veröffentlicht
Ein Kunde hat mir kürzlich erzählt, er habe vier Stunden lang versucht, einen Agenten für eine Aufgabe zu bauen, die technisch schlicht nicht funktionieren konnte. Meine ehrliche Antwort: Das hätte ich dir nach vier Minuten sagen können.
Genau deshalb steht am Anfang jedes guten Agent-Projekts nicht das Bauen, sondern eine ehrliche Machbarkeitsprüfung – und genau dafür nutze ich in Kundenprojekten ein Format, das sich in der Praxis immer wieder bewährt: den Agent-Hackathon.
Das Prinzip: Machbarkeit vor Vollausbau
Ein Agent-Hackathon ist kein Wettbewerb um die schönste Demo. Er ist eine Methode, um in kurzer Zeit ehrlich zu klären, ob eine Idee überhaupt technisch trägt – bevor Wochen in eine Live-Anbindung an SQL-Server, Snowflake oder ein ERP-System fließen, die sich am Ende als überflüssig herausstellt. Zwei Tage wirken dabei bewusst als harte Deadline: Sie verhindern, dass sich eine Idee in endlosen Scope-Diskussionen verläuft, bevor überhaupt jemand getestet hat, ob sie funktioniert.
Warum Business und IT im Tandem antreten müssen
Der wichtigste Baustein ist die Teambesetzung, nicht die Technik. Microsofts eigene Anleitung für Copilot-Studio-Projekte nennt als Kernrollen unter anderem eine Projektleitung, eine Solution-Architektur, die eigentliche Agent-Entwicklung, eine Person für Erfolgsmetriken und eine für Security und Compliance – deutlich mehr als „ein Business-Mensch plus ein IT-Mensch”. Entscheidend ist trotzdem die Grundregel: Business bringt Prozesswissen, Testfragen und die Bewertung, ob das Ergebnis fachlich trägt. IT beziehungsweise das Platform-Team bringt die technische Umsetzung und die realistische Einschätzung, was in welchem Aufwand geht. Keine der beiden Seiten kann das Format allein tragen – das ist keine Ausnahme, sondern die dauerhafte Arbeitsweise, mit der Agents in Unternehmen entstehen.
Der Vorlauf entscheidet mehr als der Tag selbst
Ein guter Agent-Hackathon beginnt zwei bis vier Wochen vor dem eigentlichen Termin, nicht am Morgen von Tag eins. Jedes Team reicht vorab einen konkreten, heute tatsächlich manuell laufenden Prozess ein und beantwortet vier Leitfragen: Wie sieht der aktuelle Ablauf aus? Wie soll er nachher aussehen? Was genau tut heute weh? Und welche Datenquellen würde ein Agent dafür brauchen? Aus den Einreichungen wird priorisiert, damit am Hackathon-Tag nur an Ideen gearbeitet wird, die eine realistische Chance haben – nicht an der spontanen Idee, die jemandem morgens um neun einfällt.
Die Machbarkeitsprüfung zuerst, nicht das Bauen
Der Kern des Formats ist ein Prinzip, das sich mit Microsofts eigenem Vorgehen für Risikoabschätzung deckt: Statt direkt die Live-Anbindung an ein Kernsystem zu bauen, wird zuerst mit dem Agent Builder und mit Beispiel- oder Exportdaten geprüft, ob die grundlegende Aufgabe überhaupt lösbar ist. Erst wenn diese Kurzprüfung – Microsoft nennt das Konzept einen zeitlich begrenzten „Spike” für die riskanteste offene Frage – positiv ausfällt, folgt der Schritt in Copilot Studio mit echten Konnektoren, mehrstufigen Abläufen und Governance. Fällt sie negativ aus, ist das kein gescheiterter Hackathon-Tag, sondern ein früher, billiger Pivot – lange bevor irgendjemand eine Zusage für ein fertiges Feature gemacht hat.
Eine Zwei-Tage-Struktur, die sich bewährt hat
Tag 1 – von der Idee zur geprüften Machbarkeit: Kickoff und kurze Plattform-Einführung, danach stellt jedes Team seine vorab eingereichte Idee in wenigen Minuten vor. Es folgt der eigentliche Machbarkeits-Workshop: Ist die nötige Datenquelle verfügbar, gibt es einen Systemzugriff, ist die Regel eindeutig genug für einen Agenten oder braucht sie menschliches Ermessen, gibt es Compliance-Punkte, die das Vorhaben sofort stoppen? Danach legt jedes Team den kleinstmöglichen sinnvollen Testausschnitt fest – nicht den ganzen Prozess – und beginnt mit dem ersten Prototyp, getestet an Beispiel- oder Exportdaten.
Tag 2 – vom Prototyp zur Entscheidung: Weiterbauen und Testen mit echten Fragen aus dem Fachbereich, begleitet durch feste Ansprechpersonen aus dem Platform-Team. Am Nachmittag zeigt jedes Team eine Live-Demo, bewertet nach denselben drei Kriterien: fachlicher Wert, technische Machbarkeit, realistischer Aufwand bis zum Produktivbetrieb. Am Ende steht für jede Idee eine von drei Entscheidungen – weiterverfolgen, zurückstellen oder verwerfen – und eine konkret benannte Person, die diese Entscheidung danach auch trägt.
Die Fallstricke, die danach entstehen
Der Hackathon-Tag selbst ist selten das Problem. Drei Dinge entscheiden, ob aus einer guten Demo auch etwas Produktives wird:
- Zu großer Scope. Teams versuchen, den kompletten Prozess abzubilden, statt eines einzelnen, aussagekräftigen Ausschnitts. Eine Moderation, die frühzeitig eingrenzt, ist wichtiger als zusätzliche Bauzeit.
- Synthetische oder fehlende Daten. Testdaten, die nichts mit der Produktivrealität zu tun haben, verraten wenig darüber, ob ein Prototyp später wirklich trägt. Ein paar anonymisierte, thematisch passende Datensätze vorzubereiten lohnt sich mehr als jede zusätzliche Stunde Bauzeit.
- Keine Owner-Zuordnung danach. Der zuverlässigste Grund, warum ein guter Prototyp trotzdem nie produktiv wird: Niemand ist nach dem Event konkret dafür zuständig. Die Owner-Frage gehört deshalb an den Schluss der Agenda, nicht in eine Mail, die irgendwann nach dem Event verschickt wird.
Was aus so einem Format typischerweise entsteht
Über mehrere Durchläufe hinweg wiederholen sich die Use-Case-Kategorien, unabhängig von der Branche: ein Dokumenten- oder Vertragsprüfungs-Agent, der eingehende Unterlagen gegen einen festen Kriterienkatalog prüft; ein Hotline- oder Support-Agent, der als erster Kontaktpunkt an ein bestehendes Ticket- oder Wissenssystem angebunden ist; ein Qualifizierungs-Agent, der eingehende Anfragen oder Business Cases strukturiert vorbewertet, bevor ein Mensch entscheidet; ein Onboarding-Agent, der schrittweise durch einen internen Ablauf begleitet; und ein Auskunfts-Agent, der Fragen zunächst auf einem Datenexport beantwortet, bevor überhaupt über eine Live-Anbindung nachgedacht wird.
Wenn ihr ein solches Format für mehrere Teams oder Abteilungen mit einem festen Termin aufsetzen wollt, ist das eine Aufgabe für individuelle Projekte.
Den vollständigen Vortrag, aus dem dieses Format stammt, gibt es auf YouTube: „Copilot Studio & Agents: So bereitest du dein Unternehmen vor” (m365 Show, Kanal von Mirko Peters).
Quellen: Microsoft Learn – Organisieren von Hackathons (Power Platform), 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.
