Multi-Agent-System aufbauen: Wie ein Solo-Berater sein eigenes KI-System gebaut hat (Teil 1)
- Marcus Machon
- 21. Apr.
- 31 Min. Lesezeit
Aktualisiert: vor 1 Tag
Wer heute ein Multi-Agent-System aufbauen will, steht vor zwei Entscheidungen, die über Erfolg oder Frust entscheiden, und beide haben nichts mit Programmieren zu tun. Die erste: das Modell. Ich habe in zwei Monaten gelernt, dass man hier nicht sparen darf. Viele Dinge, die heute sauber laufen, liefen bei mir erst ab Claude Opus 4.6 überhaupt. Und die Modelle werden monatlich besser, Opus 4.7 ist seit Kurzem noch einmal eine Klasse stärker. Die zweite Entscheidung: die Architektur. Viele Anläufe scheitern nicht am Modell, sondern an der Einstiegs-Ebene und an fehlender Struktur. Genau darum geht es in diesem ersten Teil. Teil 2 folgt in den nächsten Wochen und handelt von den offenen Fragen: Fehler, Grenzen und Risiken. Teil 3 dann Security, soweit es mir möglich ist.
Einen Anspruch habe ich nicht: dass meine Lösung für Ihr Unternehmen passt. Mein System ist ein persönliches Experiment auf einem alten Linux-Rechner, ohne kritische Daten, mit öffentlichen Studien und meiner eigenen Arbeit als Datenbasis. Keine Enterprise-Umgebung, keine Regulatorik, keine Kundendaten. Dafür aber rund zwei Monate echte Praxis (Start: 20. Februar 2026), und ein paar Zahlen, die größer geworden sind, als ich selbst für möglich hielt:
über 110 Fach-Tabellen in einer zentralen Datenbank mit über 130.000 Datensätzen (inklusive Audit-Log, Wissens-Index und semantischer Chunks)
über 2.400 vernetzte Markdown-Dokumente als Wissensbasis
über 40 nächtliche Automatisierungen
23 wiederverwendbare Arbeitsabläufe (Skills) und fünf spezialisierte Sub-Agenten
über 2.000 Messungen der Skill-Qualität
rund 400 dokumentierte Fehlermuster, derselbe Fehler passiert heute deutlich seltener (ehrlich: ganz verschwunden ist er nicht)
und: seit Inbetriebnahme kein einziger kritischer Systemfehler
Die letzte Zahl ist mir die wichtigste. Kein Datenverlust, kein produktionsrelevanter Ausfall, keine falschen Zahlen in Veröffentlichungen. Dass das System täglich weiterwächst, macht das nicht selbstverständlich.
Was dieser Beitrag ist, und warum er umsonst ist
Ich lege hier mein komplettes Vorgehen offen: Architektur, Fehler, Quellen und die Methode dahinter. Kostenlos, ohne Newsletter-Hürde, ohne Kurs-Funnel. Wer meine Zeit im Beratungs-Format will, bucht sie. Wer selbst bauen will, findet hier genug.
Mein Vorgehen beim Aufbau war/ist bewusst fast wissenschaftlich: gegengeprüfte Quellen wie Studien und peer-review Papers, Entscheidungen schriftlich festgehalten, strittige Thesen nach einem festen Schema analysiert (Behauptung, Beleg, Konfidenz, Einwand). Gleichzeitig gehört zur Ehrlichkeit dazu, dass Arbeiten mit KI "weird" ist. Sie erfordert eine andere Denk- und Arbeitsweise, als ich sie aus über 25 Jahren Berufserfahrung kenne. Niemand in diesem Feld kann alles im Detail kennen. Die Modelle und Werkzeuge ändern sich im Monatsrhythmus, und wer klassisch an so ein KI-System rangeht, der Business Case, dann die Architekturkommission, dann ein dreimonatiges Pilotprojekt womöglich noch nur mit Testdaten, scheitert meiner Überzeugung nach.
Was für mich funktioniert, ist ein kontinuierliches Abwägen zwischen zwei Polen. Auf der einen Seite: maximale Autonomie für die KI, inklusive Selbstverbesserung. In meiner Sandbox darf Claude fast alles. Code schreiben, Schema migrieren, Skills bauen, eigene Ergebnisse bewerten. Auf der anderen Seite: null Zugriff auf sensible Daten oder Tools. Kein Kundendatenbestand, keine E-Mails. Erst durch diese Kombination bin ich in der Lage, Dinge zu lösen, von denen ich vorher nicht einmal geträumt habe. Wer die KI im goldenen Käfig hält, bekommt Tool-Gefühl. Wer sie überall hinlässt, bekommt vielleicht eine Katastrophe. Der Korridor dazwischen ist schmal, und er verändert sich mit jedem Modell-Release. Und absolute Sicherheit gibt es nirgendwo.
Aus dieser Mischung ist bei mir mit der Zeit ein Gefühl für mein System entstanden. Wo sind wahrscheinlich Lücken, wo verstecken sich Fehler, was fehlt. Das ist gleichzeitig eine Art Kunst: zu wissen, wann man messen muss, und wann Bauchgefühl reicht. Wer nur logisch-analytisch arbeitet, wird langsam. Wer nur vibe-codet, baut Chaos. Beides braucht es, in wechselnder Gewichtung.
Für alle, die selbst loslegen wollen, finden Sie an den entscheidenden Stellen Blöcke mit der Überschrift "Technisches Briefing für Ihr LLM". Diese Blöcke sind als Copy-Paste-Prompts gedacht: direkt in Ihre eigene Claude-, Gemini- oder ChatGPT-Instanz einfügen und recherchieren, erklären oder umsetzen lassen. Jede Box enthält Patterns, Fallstricke, Begründungen und, wo sinnvoll, konkrete Konfigurations-Hinweise. Das ist die Abkürzung, die ich selbst gerne gehabt hätte.
Sie finden einen Fehler? Eine bessere Quelle? Einen fehlenden Aspekt? Schreiben Sie mir direkt (LinkedIn Profil am Ende). Ich aktualisiere diesen Beitrag aktiv, das ist der Vorteil eines Blogs gegenüber einem gedruckten Buch.
Warum das mehr ist als Hype: eine leise Disruption
Kritik an KI ist nicht falsch, sie hinkt meiner Meinung nach nur dem Stand der Technik hinterher. Die meisten skeptischen Studien stammen aus 2024 oder früher, als die Modelle schlicht nicht gut genug waren. Auch viele Studien aus 2025 arbeiten bereits mit überholten Modellversionen, die Halbwertszeit in diesem Feld beträgt Monate, nicht Jahre. Ende 2025 gab es einen Sprung, den ich im Alltag spüre: Aufgaben, an denen Modelle vor einem Jahr noch gescheitert sind, erledigt Claude heute in Minuten. Meinen eigenen "Hier passiert etwas Fundamentales"-Moment habe ich damals in einem LinkedIn-Post festgehalten, bei dem viele dachten, ich übertreibe. Ich glaube ich tat es nicht.
Die typischen Kritiken am sogenannten Vibe Coding (einfach die KI bauen lassen und hoffen) kann ich trotzdem nachvollziehen. Ja, die KI macht Fehler. Ja, Code bläht sich ohne Kontrolle auf. Ja, Abhängigkeiten wachsen im Stillen. Aber: Wer das System ernsthaft überwachen lässt, fängt diese Probleme früh ab. Bei mir läuft seit über zwei Monaten kein einziger kritischer Fehler. Jedes ernsthafte Problem habe ich bisher rechtzeitig gesehen und meist schnell gelöst. Bugfixing und Monitoring gehören zum Alltag, manchmal frisst das viel Zeit, vor allem weil ich Teile der Architektur teilweise wöchentlich umbaue. Aber ich sehe an Dashboards, Auswertungen und Prozessen sehr schnell (manchmal natürlich auch nicht), wenn etwas aus dem Ruder läuft. Blinde Flecken bleiben, wie überall. Der Punkt ist: Die Kritiken an KI-gestütztem Bauen haben einen wahren Kern. Mit einer bewusst gewählten Architektur, einem funktionierenden Fehlergedächtnis und dem Willen zur ehrlichen Analyse sind diese Herausforderungen meiner Erfahrung nach lösbar, oder zumindest beherrschbar.
Drei Dinge sind heute fundamental anders:
Erstens: Das Eintrittsticket liegt im zweistelligen Bereich, nicht im hohen fünfstelligen. Ich zahle ein Monats-Abo für Claude und nutze einen alten Rechner. Eine KI-Schätzung für den Nachbau meines Systems durch eine Agentur lag bei rund 50.000 Euro und drei Personen, und die Zahl halte ich inzwischen für viel zu niedrig. Das ist kein belastbarer Marktpreis, aber die Größenordnung spricht für sich: Was gestern noch ein Projekt mit Budget, Lenkungskreis und Dienstleister war, wird heute zum Wochenend-Experiment eines Einzelnen.
Zweitens: Die großen Enterprise-Blocker greifen bei Solo-Operatoren und kleinen Teams nicht. Was Konzerne bremst (Governance, Altsysteme, Datenschutz) spielt für Einzelne mit öffentlichen Daten kaum eine Rolle, dazu gleich mehr. Die Disruption passiert deshalb an den Rändern: bei Beraterinnen, Freelancern, kleinen Fachfirmen. Die können heute in zwei Monaten haben, wofür Konzerne Jahre brauchen.
Drittens: Das Fundament ist Open Source plus Abo, nicht Cloud-Lock-in. Linux, SQLite, Markdown, Git, Obsidian, alles kostenlos. Einzige gebundene Komponente: mein Claude-Abo. Wenn Anthropic die Preise verdoppelt, wechsle ich das Modell, nicht die Architektur. Das ist ein anderes Dependency-Profil als jede SaaS-Plattform.
Gerechtfertigte Kritik bleibt trotzdem: Die aktuellen Abos sind von den Anbietern subventioniert; Token-Kosten könnten steigen. Sicherheit ist für Enterprise-Szenarien eine Herausforderungen (ich denke das sollte trotzdem lösbar/ beherrschbar sein). Für Solo- und Klein-Setups mit unkritischen Daten ist der Hebel aber schon heute real, und das ändert, wer in den nächsten zwei Jahren wirtschaftlich überhaupt mithalten kann.
Für wen dieser Beitrag taugt, und für wen nicht
Ein Solo-Setup ist kein Konzern-Setup. Was bei mir funktioniert, lässt sich nicht einfach auf hundert Mitarbeitende übertragen. In Unternehmen kommen Themen dazu, die bei mir schlicht wegfallen: wer darf was mit welchen Daten sehen, wie integriert man zwanzig Jahre alte Systeme, wie sieht Governance für DSGVO und EU AI Act aus, wie trainiert man hundert Leute, die noch nie produktiv mit KI gearbeitet haben. Das sind andere Baustellen.
Trotzdem lohnt der Blick auf Solo-Setups auch für Unternehmen. Nicht als Blaupause, sondern als Referenz: Was ist der State of the Art, wenn jemand alleine und ohne die üblichen Bremsen baut? Vieles davon ist direkt auf einen kleinen internen Piloten übertragbar.
Mein Rat dafür: eine Ebene vor dem großen Transformationsprojekt ansetzen. Zwei bis vier Mitarbeitende, die Lust auf das Thema haben. Klar abgegrenzte, unkritische Use Cases, Marktrecherche, Wettbewerbsbeobachtung, Content, Leadqualifizierung, internes Wiki. Keine personenbezogenen Daten, keine Kundendaten. Ein paar Lizenzen, ein alter Rechner, zwei bis vier Wochen ernsthafte Nutzung. Der Wert liegt weniger im unmittelbaren Output als im Erfahrungsaufbau. Wer jetzt startet, weiß in einem Jahr, was geht und was nicht, und muss nicht raten.
Dieser Beitrag beschreibt das Solo-Ende. Vieles davon lässt sich auf einen Klein-Piloten übertragen, einiges nicht. Den Unterschied sollten Sie beim Lesen im Kopf behalten.
Ist das überhaupt relevant für mich?
Kurze Antwort: vermutlich ja. Die Studienlage ist allerdings widersprüchlicher, als es auf den ersten Blick wirkt.
Eine Studie der Harvard Business School (Dell'Acqua et al. 2026, 758 Wissensarbeitende) zeigt: Innerhalb der sogenannten Jagged Frontier, also bei Aufgaben, die KI gut kann, erledigen Menschen mit KI-Unterstützung rund 12 Prozent mehr Aufgaben und sind etwa 25 Prozent schneller. Außerhalb dieser Grenze kippt der Effekt, bis zu 19 Prozent seltener kommen korrekte Lösungen zustande. Die Grenze ist nicht fix, sie verschiebt sich mit jeder neuen Modell-Generation. Das macht sauberes Messen schwer.
Zur Verbreitung in Deutschland: Das KfW-Mittelstandspanel 2026 (Zimmermann, n=6.845) zeigt, dass rund 80 Prozent der mittelständischen Unternehmen aktuell keine KI nutzen. Bitkom meldet parallel, dass die Nutzung quer durch alle Branchen auf 41 Prozent gestiegen ist. Unter den KI-nutzenden Unternehmen stufen sich 62 Prozent selbst als Nachzügler ein, nur 30 Prozent sehen sich als Vorreiter. Das passt zu meinem Eindruck aus Gesprächen: Viele diskutieren, wenige bauen. Dieser Beitrag richtet sich an die Bauenden.
Und jetzt der ehrliche Teil. Wenn man mehrere Studien nebeneinander legt, widersprechen sie sich regelmäßig. Die eine findet klare Produktivitätsgewinne, die nächste kaum messbare Effekte, die dritte sogar Nachteile. Das liegt selten an schlechter Forschung, sondern an der Natur der Sache: andere Modelle, andere Aufgaben, andere Teilnehmende, andere Messzeitpunkte. Wer 2023 mit GPT-3.5 gemessen hat, misst etwas anderes als 2026 mit Claude Opus 4.7 oder bald GPT-5.5. Eine belastbare, allgemeingültige Antwort auf die Frage „bringt GenAI Nutzen?" gibt die Wissenschaft bis heute nicht her.
Was ich sagen kann: Für mich und mein System funktioniert es bisher sehr, sehr gut.
Was ist ein Multi-Agent-System, und was genau unterscheidet es von ChatGPT?
Ein Multi-Agent-System ist eine Architektur, in der mehrere spezialisierte KI-Agenten auf einem gemeinsamen Wissensspeicher arbeiten, Aufgaben untereinander übergeben und sich gegenseitig ergänzen. Der Unterschied zu einem einzelnen Chatbot: Spezialisierung, Parallelverarbeitung und geteilter Kontext.
Wichtiger als die Definition ist die Abgrenzung. Ein Multi-Agent-System ist kein komplett autonomes System, das eigenständig entscheidet. Ich gebe frei. Ich validiere (manchmal mehr, manchmal weniger). Es ist kein Ersatz für menschliches Urteil bei strategischen Fragen.
Ehrlich: Eine gewisse Black Box bleibt es trotzdem. Ein Sprachmodell ist im Kern immer eine. Mein System wird zusätzlich zu einer, weil ich bei über 110 Tabellen und mehr als vierzig Automatisierungen längst nicht mehr jeden Schritt einzeln prüfe. Das ist ein Restrisiko, das ich bewusst trage.
Was es vom ChatGPT- oder Gemini-Chatfenster unterscheidet, ist fundamental und wird oft unterschätzt. Im Browser-Chat reden Sie mit einer KI, die nach dem Gespräch fast alles wieder vergisst. Memory-Funktion aktivieren, Dateien manuell hochladen, das geht, aber die KI bleibt eine Gesprächspartnerin. In meinem System ist Claude ein Kollege mit Zugang zum Büro. Die KI legt Dateien an, aktualisiert sie, führt Datenbankabfragen aus, startet Hilfsprogramme, schreibt ihre eigenen wiederverwendbaren Arbeitsabläufe (in der Fachwelt Skills genannt) und dokumentiert, was sie getan hat.
Das Wissen wächst dabei fast vollautomatisch. Jedes neue Paper, jeder Chat mit mir, jede Rückmeldung zu einem Ergebnis fließt zurück ins System, und es wird mit jedem Zyklus besser. Aus einer einmaligen Antwort wird dauerhaftes Wissen. Wenn ich ChatGPT eine Studie gebe, kann es sie im Gespräch analysieren. Wenn ich meinem System eine Studie gebe, landet sie in der Evidenz-Datenbank, wird gegen existierende Einträge geprüft, bekommt ein Konfidenz-Level, wird mit relevanten LinkedIn-Posts und Blog-Themen verknüpft und steht ab sofort bei jeder Recherche zur Verfügung.
Und es gibt einen Punkt, der für mich der größte Unterschied ist: die fast absolute Gestaltungsfreiheit. Ich entscheide, welche Apps und Tabellen entstehen, welche Skills es gibt, wie die Qualitäts-Gates aussehen, welche Prozesse automatisch laufen. Kein Produkt-Backlog, kein Hersteller, der über meine Workflows bestimmt. Man baut sich im Prinzip sein eigenes, maßgeschneidertes KI-"Betriebssystem" für den eigenen Arbeitsbereich. Das ist die Stärke, und gleichzeitig das Risiko, weil die KI deutlich mehr kann und anrichtet als im Browser.
Warum habe ich mir das gebaut und wofür nutze ich es wirklich?
Kurz: Ich bin Solo-Berater mit Microsoft-365-Governance und KI-Readiness als Spezialgebiet. Kein Team, das mit mir skaliert. Keine Beratungs-Infrastruktur, die sich selbst finanziert. Was mir fehlt, ist Hebel. Was ich mir gebaut habe, ist dieser Hebel in Software.
Die Motivation ist nicht nur Hype, sondern ein konkretes Problem: Content produzieren, Leads recherchieren, Studien auswerten, Entscheidungen dokumentieren. Das alles frisst Zeit, die ich als Einzelperson nicht habe. Jedes klassische Werkzeug löst davon einen Teil. Mein Multi-Agent-System versucht, die Teile zusammenzubringen.
Das System nutze ich heute für sechs Aufgabenfelder:
Content-Management: LinkedIn-Posts entwerfen, Blogbeiträge strukturieren, Themen-Pipeline pflegen. Jedes Content-Stück wird automatisch gegen die eigene Evidenz-Datenbank geprüft (857 Einträge, 73 direkt zitierfähig, knapp 40 aktiv als widerlegt gesperrt).
Lead-Recherche: Unternehmen im DACH-Mittelstand identifizieren und anreichern. Aktuell 67 Leads, alle mit nachvollziehbarer Datenherkunft.
Freelancer-Plattformen automatisch screenen: 137 Projekte bisher analysiert. Eingehende Ausschreibungen werden vom System vorbewertet, nur relevante landen in meinem Posteingang.
Wissensmanagement: Deep Researches zu Fachthemen (Microsoft Copilot, KI-Sicherheit, DSGVO), automatische Paper-Auswertung, Konfidenz-basierte Evidenz-Datenbank und rund 500 verdichtete Erkenntnisse.
Strategie und Positionierung: Architecture Decision Records (aktuell 42 ADRs), strukturierte Analysen mit einem eigenen Analyse-Prozess (Toulmin-Modell). Entscheidungen sind Monate später nachvollziehbar.
Automatisierte Recherchen: über 40 nächtliche Automatisierungen beobachten Markt-Updates, Microsoft-Announcements, KI-Forschung und arXiv-Papers. Relevantes wandert in die Wissensbasis, der Rest ist aussortiert, bevor ich morgens an den Schreibtisch komme. Neue Forschungserkenntnisse werden analyisiert und ggf. umgesetzt und getestet.
Was genau kann dieses System? (Feature-Liste zum Aufklappen)
Wer konkret wissen will, welche Aufgaben dieses System abdeckt: hier die Übersicht, geordnet nach Business-Bereichen. Die Begriffe sollten jedem, der im Mittelstand oder in Beratung arbeitet, bekannt vorkommen.
Strategie & Steuerung
OKR-Management: Jahres- und Quartalsziele mit Schlüsselergebnissen, aus denen Aufgaben automatisch abgeleitet werden
Wochenfokus: wöchentliche Prioritäten, an denen das System meine Aufgabenplanung ausrichtet
Entscheidungsprotokolle (ADRs): jede wichtige Architektur- oder Strategieentscheidung wird mit Begründung und Alternativen festgehalten
Risk Register: offene Risiken mit Bewertung und Gegenmaßnahmen
Projekt- & Aufgabenmanagement
Aufgabenverwaltung: Tasks mit Fälligkeiten, Abhängigkeiten, Verknüpfung zu Zielen und Projekten
Projekt-Ordner: jede Initiative hat einen eigenen Arbeitsbereich mit Historie und Beteiligten
Inbox für Ad-hoc-Eingänge: alles Neue landet an einem Ort und wird triagiert
Wiederkehrende Aufgaben: automatische Erstellung nach Zeitplan (wöchentlich, monatlich)
Wissensmanagement & Recherche
KI-Wiki: durchsuchbare Wissensbasis von Studien, Deep Researches, Microsoft Apps mit Querverweisen und Graph-Ansicht (Obsidian). Dieses Wiki wird wiederum für LinkedIn/ Blog Posts, Sales Call und als Input für Angebote und Kundenprojekte genutzt
Evidenz-Datenbank: verifizierte Fakten aus Studien mit Konfidenz-Stufen und Quellenangabe
Semantische Suche: findet inhaltlich verwandte Einträge, nicht nur Wort-Treffer
Faktencheck-Workflow: jede Zahl wird gegen Primärquellen geprüft, bevor sie verwendet wird
Paper-Extraktion: wissenschaftliche PDFs werden automatisch ausgewertet und in die Wissensbasis aufgenommen
Erkenntnisse & Thesen: verdichtete Insights, die auf mehreren Evidenzen aufbauen
Content & Kommunikation
LinkedIn-Redaktion: Entwurf, Planung, Veröffentlichung und Performance-Analyse
Blog-Redaktion: SEO-Metadaten, Fakten-Gate vor Publikation, Archiv
Content-Pipeline: von Idee über Entwurf bis Veröffentlichung, ein Workflow
Trendauswertung: was performt in Social Media, welche Themen tragen
Bild-Generierung: Skill für einheitliche Visuals für Posts und Beiträge. Umsetzung aber mit Nano Banana Pro
Vertrieb & Leads
Lead-Datenbank (CRM): Status-Tracking
Lead-Recherche & Anreicherung: automatische Hintergrund-Recherche zu Unternehmen (Website, News, Finanzen)
Freelancer-Plattform-Screening: eingehende Ausschreibungen werden vorbewertet, nur relevante landen bei mir
Sales-Call-Vorbereitung: Briefing mit Firmenprofil, Pain Points, Argumenten
Kundenkonzepte: strukturierte Konzepte mit Input aus KI-Wiki
Analytics & Reporting
Dashboard (HQ): zentrales Status-Board über alle Bereiche hinweg
KPI-Tracking: einheitliche Definition der Kennzahlen, eine Wahrheitsquelle
Wochen- und Monats-Reports: automatisch generiert, nicht manuell zusammengeklickt
Website-Analytics: Integration mit Google Analytics
Social-Media-Analytics: Engagement, Reichweite, Follower-Wachstum je Kanal
Security & Monitoring
System-Health-Überwachung: 9 Services, 24/7 im Blick, Alerts bei Ausfällen
Sicherheits-Feeds: neue Schwachstellen und CVEs, die mein System betreffen könnten
Kostenüberwachung: Token-Budget mit Frühwarnung vor Wochen- und Tokenlimits
Audit-Log: wer hat wann was geändert, auch/ insbesondere die KI
Automatisches Backup: Datenbank und Wissensbasis, mehrfach täglich
Automatisierung & Selbstverbesserung
Nächtliche Jobs: 47 Automatisierungen (Feeds verarbeiten, Backups, Bereinigung)
M365 Weekly Digest: automatische Wochenzusammenfassung von Microsoft-365-Neuerungen
KI-Forschungs-Feed: aktuelle Paper und Trends, gefiltert auf meine Themen
Push-Benachrichtigungen (Discord): das System meldet sich auf dem Handy, wenn etwas wichtig ist
Skill-Bewertung: jeder Arbeitsablauf wird laufend gemessen
Autonome Selbstverbesserung: das System testet Varianten seiner eigenen Prozesse und übernimmt nur das, was messbar besser ist
Fehler-Gedächtnis: dokumentierte Fehlermuster, damit derselbe Fehler nicht zweimal passiert
Was mir das messbar bringt:
Strukturumbauten an Datenbank oder Prozessen dauern in der Regel 20 bis 40 Minuten, nicht Tage oder Wochen. Beispiel aus der letzten Woche: Schema-Migration über sechs Apps, kein einziger Integritätsfehler, Zeitaufwand rund eine Stunde.
Nachvollziehbarkeit: Für jede Zahl in meinen Beiträgen kann ich Primärquelle, Konfidenz-Level und Verifikations-Datum nennen.
Seit Wochen kein kritischer Systemausfall, obwohl das System täglich erweitert wird.
Was mir das nicht bringt (ehrlich):
Kein Automatismus auf der Ergebnisseite. Das System macht mich schneller und gründlicher, nicht automatisch erfolgreicher. Der Unterschied ist mir wichtig: Es nimmt mir Prozess-Arbeit ab und schafft Zeit für das, was Software nicht kann, Beziehungen aufbauen, Vertrauen gewinnen, echte Gespräche führen. Business-Outcomes garantiert dir kein Werkzeug der Welt. Das schafft man auch mit großen Teams oft nicht. Das System ist Infrastruktur, kein Umsatztreiber an sich. Es macht aber möglich, dass ich als Einzelperson Themen bearbeite, für die sonst ein dreiköpfiges Team nötig wäre.
"Erst die Daten sauber, dann KI"? Nein.
Ein Einwand hält sich hartnäckig: Man müsse erst die Daten und Prozesse sauber bekommen, dann komme KI. Das Gegenteil ist meine Erfahrung. Wer auf diesen Zustand wartet, wartet für immer. Strukturiertes Wissen hilft, ist aber kein Muss. Grüne Wiese geht auch. Am Anfang macht man viele Fehler, die Security ist nicht gehärtet, Prozesse wackeln. Das ist okay, solange die KI einen schlechten Prozess in 20 bis 40 Minuten anpassen kann. Ich habe meine Datenbank, meine Apps und meine Skill-Architektur so oft umgebaut, dass ich aufgehört habe zu zählen.
Niemand kann die Zukunft vorhersagen. Vielleicht ist dieser Blogbeitrag in wenigen Wochen in Teilen überholt, weil ein einfacheres oder besseres Werkzeug auf den Markt kommt. Der echte Hebel, den ich heute sehe, ist deshalb ein anderer: die systematische Erzeugung von Unternehmenswissen und Kontext für zukünftige KI-Modelle. Und damit meine ich nicht tausend PowerPoints und Word-Dateien im SharePoint. Ich meine hochrelevante, aktuelle, möglichst hochwertige Insights, Lessons Learned aus internen und externen Signalen, dokumentierte Entscheidungen mit Begründung, verifizierte Evidenz mit Konfidenz-Level.
THESE: Genau dieser Kontext ist das, was das nächste Modell in zwölf Monaten braucht, um in Ihrem Unternehmen wirklich wertvoll zu sein. Wer heute damit anfängt, sammelt ihn laufend. Wer in zwei Jahren einsteigt, hat ein besseres Modell, aber nichts, womit es arbeiten kann.
Meine Lernkurve: vom Agenten-Framework zurück zum Terminal
Angefangen habe ich im Februar 2026 auf dem ehrgeizigsten Weg: mit einem Agenten-Framework namens OpenClaw. Mehrere Agenten, erst Telegram, dann Discord als mobiles Frontend, eigene API-Aufrufe, selbstgebautes Tooling. Ich war zwei Wochen tief im Code, bis das Ding überhaupt rudimentär lief. Ein schönes Lehrstück, aber ehrlich: zu viel Architektur, zu wenig Ergebnis. In diesen ersten Wochen war ich mehrfach kurz davor, alles hinzuwerfen. Das gehört zur Wahrheit dazu. Wer den Einstieg plant, sollte wissen, dass dieses "das wird nie funktionieren"-Gefühl Teil des Weges ist.
Parallel habe ich immer mehr mit Claude Chat recherchiert und Architekturthemen entschieden, weil es schlicht besser und günstiger war. Irgendwann waren meine OpenClaw-Agenten in Discord nur noch passive Benachrichtigungs-Kanäle für Alerts.
Der eigentliche Gamechanger war aber Claude Code im Terminal. Plötzlich konnte ich Probleme lösen, an denen die eigenen Agenten reihenweise scheiterten: komplexe Refactorings, Schema-Migrationen, Debugging über mehrere Dateien hinweg. Das Tool arbeitet direkt in meinen Ordnern, hat Zugriff auf alle Werkzeuge des Systems und denkt in größerem Kontext als jede API-Schleife, die ich mir selbst zusammengestrickt habe.
Vor wenigen Tagen habe ich OpenClaw komplett abgebaut. Der einzige spürbare Nachteil: Mobile-Arbeit fällt weg. Vom Handy aus lässt sich Claude Code im Terminal nicht wirklich bedienen, und das ist okay für mich, weil ich die Hand am echten Rechner habe, wenn ich baue. Alles andere: messbar besser.
Aus dieser Erfahrung sind zwei Ebenen plus zwei Ergänzungen übrig geblieben:
Ebene 1, Claude.ai im Browser/ App (alternativ Gemini oder ChatGPT). Das Gespräch mit einem klugen Berater. Ich tippe, bekomme Antworten, lade mal eine PDF hoch. Gut für Recherchen, Strategiegespräche, Brainstorming. Diese Ebene kennen die meisten.
Ebene 2, Claude Code im Terminal. Der eigentliche Handwerker. Die KI arbeitet direkt auf meinem Rechner: liest Dateien, schreibt Dateien, führt Befehle aus, debuggt. Hier findet der gesamte Aufbau statt. Einstieg ab Pro-Abo (rund 18 Euro pro Monat). Für ernsthafte Nutzung empfehle ich inzwischen den Max Plan, dazu später mehr.
Ergänzung 1, Obsidian als menschliches Frontend. Ein kostenloser Markdown-Editor mit Graph-Ansicht. Gold wert für den menschlichen Überblick in das Ordner- und Dateisystem, weil die KI schnell gerne Chaos stiftet wenn man nicht aufpasst! Aber alle Dateien sind strikt für LLMs und kaum für Menschen optimiert.
Ergänzung 2, Discord für Push-Benachrichtigungen. Kein KI-Chat, sondern ein Meldekanal: Sicherheitswarnungen, neue Freelancer-Ausschreibungen, fehlgeschlagene Automatisierungen. Das System meldet sich, wenn etwas wichtig ist. Kein aktives Befragen, nur Push aufs Handy.
Meine Empfehlung: Fangen Sie mit Ebene 1 und 2 an. Discord, Telegram, etc. dazu, wenn das Fundament steht. Keine eigenen Agenten-Frameworks, keine Telegram-Bots, keine API-Bastelei am Anfang. Ich habe das alles probiert und in den ersten Tagen rund 30 Euro verbrannt, weil die KI ohne klare Struktur wild Dateien angelegt hat. Ohne Fundament entsteht Chaos, nicht irgendwann, sondern sofort oder schlimmer: unbemerkt.
Die Ebenen-Logik habe ich in einem früheren Beitrag ausführlicher beschrieben: KI-Strategie im Mittelstand: Warum Sie kein Transformationsprojekt brauchen.
Multi-Agent-System aufbauen: Das Fundament (Hardware, Terminal, Shared Folder)
Phase 1: Wegwerf-Hardware und Minimal-Security
Nehmen Sie einen alten PC oder Laptop. Installieren Sie Ubuntu (Claude Chat, ChatGPT, Copilot oder Gemini helfen bei der Einrichtung!). Legen Sie mehrere Benutzer an: einen für sich selbst, einen für die KI-Umgebung (Principle of Least Privilege). Keine kritischen Daten auf diesen Rechner. Tägliches Backup einrichten. Fertig.
Das Wichtigste klingt erst mal falsch: Geben Sie der KI in der Aufbauphase möglichst viele Rechte. Ja, das widerspricht jeder Security-Lehre. Aber wer der KI während des Aufbaus alles verbietet, debuggt wochenlang statt zu bauen. Das Risiko ist dadurch kleiner, aber nicht null. Wer ehrlich ist, räumt ein: Absolute Sicherheit gibt es nicht. Der Schaden bleibt aber begrenzt, wenn weder Kundendaten noch Geschäftsgeheimnisse auf der Maschine liegen. Mehr zu Security in Teil 2.
Technisches Briefing für Ihr LLM (Basis-Setup, Kopiervorlage): Kontext: Ubuntu 24.04 LTS auf einem Einzelrechner, KI-Agenten-System für eine Solo-Nutzerin. Keine kritischen Daten, kein Produktionsbetrieb für Dritte. Bitte erklären und als idempotente Schritt-für-Schritt-Anleitung umsetzen: - Zwei Benutzer anlegen: einen persönlichen Account (uid 1000) und einen Systemuser für die KI-Automation (uid < 1000). Gemeinsame Gruppe, setgid-Bit auf dem Arbeitsverzeichnis, damit beide dort schreiben können. - Trennung von Code und Laufzeitdaten: Repo unter /srv, Secrets in /etc/<app>, State unter /var/lib/<app>, Logs unter /var/log/<app>, Backups unter /var/backups/<app>. Keine Laufzeitdaten ins Git-Repo. - SSH absichern: PasswordAuthentication=no, nur Public-Key-Login, Root-Login gesperrt. UFW aktivieren: default deny incoming, SSH rate-limited, alles andere gezielt freigeben. - unattended-upgrades für Security-Updates aktivieren. - Tägliches Backup: borgbackup oder restic (verschlüsselt, dedupliziert), Retention 7 täglich / 4 wöchentlich / 12 monatlich. Bitte für jeden Punkt: Begründung, häufige Fallstricke, ein Verifikations- kommando und ein Minimalbeispiel. Fortgeschrittene Härtung (AppArmor, systemd-Sandboxing, Least-Privilege-sudoers) separat für Phase 2 vorschlagen, nicht vermischen.Phase 2: Claude Code im Terminal statt APIs
Claude Code ist ein Kommandozeilen-Werkzeug von Anthropic, das direkt auf Ihren Ordnern arbeitet. Kein API-Key-Gebastel. Sie schreiben einen Satz, die KI macht den Rest: liest Dateien, schreibt Dateien, führt Befehle aus.
Der Vorteil gegenüber reiner API-Nutzung oder günstigen Modellen: direkter Zugriff auf Opus als stärkstes Modell, planbare Fixkosten im Abo und volle Kontrolle über den Kontext. Wer billige Modelle per API kombiniert, spart an der falschen Stelle und zahlt die Ersparnis in Debugging-Zeit zurück. Der Abstand zwischen Premium- und günstigen Modellen schrumpft zwar laufend, aber für produktive Agenten-Arbeit zählt heute jede Qualitätsstufe.
Technisches Briefing für Ihr LLM (Einstieg mit Claude Code): Kontext: Claude Code CLI (Anthropic) als primäre Arbeitsumgebung auf meinem Rechner. Bitte erklären und vorschlagen: - Was unterscheidet Claude Code von der reinen API-Nutzung? Welche Vorteile bekomme ich konkret (Kontextmanagement, Tool-Zugriff, Slash-Commands)? - CLAUDE.md als projektweite Systeminstruktion: wo platzieren, was rein gehört (Konventionen, Pfade, Verbote), was NICHT rein gehört (ephemere Tasks, Secrets). Zeige eine Minimal-Vorlage. - Modell-Wahl: Opus für Architektur und Refactors, Sonnet als Default, Haiku nur für einfache Lookups. Kurze Faustregel, wann welches Modell. - Subscription-Tiers (Pro vs. Max): wann reicht Pro, wann lohnt Max? - Git-Grundregeln: Pre-Commit-Hooks, kein git push ohne Freigabe, Branch-Schutz auf main. Schlag auf dieser Basis eine minimale Projektstruktur (Repo-Root + Shared Workspace) vor und begründe jede Entscheidung. Fortgeschrittenes (Subagenten, Hooks, eigene Skills) separat für eine zweite Runde, nicht vermischen.Phase 3: Shared Folder und das Blackboard-Prinzip
Legen Sie einen Ordner an (ich nenne ihn SHARED) und strukturieren Sie ihn nach Themen. Jeder Unterordner bekommt eine README.md, die beschreibt, was drin liegt und wofür. Diese README ist nicht für Sie. Sie ist für die KI.
Das Blackboard-Prinzip stammt aus der KI-Forschung der 1980er-Jahre: Mehrere Agenten lesen und schreiben auf einem gemeinsamen Speicher. Bei mir ist das eine README.md pro Ordner. Einfach, robust, skalierbar. Die Agenten lesen vor jeder Aufgabe, aktualisieren danach. So entsteht ein System, das sich selbst dokumentiert.
Obsidian dockt hier an. Ich sehe eine Graph-Ansicht aller Dokumente, springe per Wiki-Links zwischen Notizen, editiere unterwegs. Die KI liest und schreibt dieselben Dateien auf der Server-Seite. Zwei Perspektiven auf einen Wissensspeicher, die menschliche (visuell, assoziativ) und die maschinelle (strukturiert, über Metadaten).
Der Effekt ist messbar. Das ACE Framework (Zhang et al. 2025, arXiv:2510.04618) zeigt: Kontexte als "evolving playbooks" zu behandeln verbessert Agent-Benchmarks um 10,6 Prozent. Ein gut gepflegter Shared Folder ist genau das: ein mitwachsender Wissensspeicher, der mit jedem Durchlauf besser wird.
Die Analogie zu Niklas Luhmanns Zettelkasten (Luhmann 1981, Kommunikation mit Zettelkästen. Ein Erfahrungsbericht) liegt nahe. Was Luhmann mit seinem vernetzten Notizsystem erreichte, kleine Wissens-Einheiten, die sich gegenseitig referenzieren, erreicht ein Multi-Agent-System mit README-Dateien und Frontmatter-Metadaten. Nur dass jetzt ein Sprachmodell durch den Zettelkasten navigiert.
Technisches Briefing für Ihr LLM (Wissens-Ordner als Blackboard): Kontext: Markdown-basierter Shared Folder, an dem ein oder mehrere Agenten arbeiten. Basis: Blackboard-Architektur (Hayes-Roth 1985), angepasst für moderne Agent-Systeme. Bitte erklären und Beispiele generieren: - YAML-Frontmatter als einheitlicher Header für jedes Dokument: id, content_type (z.B. adr/skill/evidence/project/note), status, created_at, updated_at, related (Links zu verwandten Dateien), llm_summary (ein Satz für den Agenten, entscheidet, ob er die Datei überhaupt laden muss). - Eine zentrale Router-Datei (HOME.md oder CLAUDE.md) mit thematischen Clustern, pro Cluster 3-5 Einstiegspunkte. Agenten lesen zuerst den Router, nicht das gesamte Verzeichnis. - Lazy Loading: Bei langem Kontext sinkt die Reasoning-Qualität spürbar. Konsequenz: erst die llm_summary, dann gezielt nachladen. - Jede README mit einem klaren Zweck, je enger der Scope, desto höher die Trefferquote. - .gitignore: Laufzeitdaten (Datenbanken, node_modules, Logs) raus aus dem Repo. Generiere: eine Beispiel-CLAUDE.md und eine Muster-Frontmatter-Spezifikation. Optional (später): ein einfacher Schema-Validator als pre-commit-Hook.Ich habe eine ganze Woche nur an diesem Fundament gearbeitet. Das war keine verlorene Zeit. Das war die beste Investition des ganzen Projekts.
Was mich am meisten überrascht hat: Etwa 80 Prozent meiner Zeit mit diesem System gehen in Architektur, nicht in das eigentliche Tun. Das klingt ineffizient. Ist es nicht. Wer die Architektur nicht investiert, zahlt sie doppelt später.
Wie dokumentieren Sie Wissen in einem Multi-Agent-System?
Jede Entscheidung wird als kurzes ADR (Architecture Decision Record) festgehalten. Jede wiederkehrende Aufgabe als Skill (Markdown-Prozessbeschreibung). Recherchen landen als Deep-Research-Dokumente mit Konfidenz-Level in der Wissensbasis. So entsteht ein System, das sich selbst erklärt.
Phase 4: ADRs für Entscheidungen
Nach drei Wochen fragen Sie sich: Warum haben wir das damals so entschieden? Das ADR-Konzept wurde von Michael Nygard in seinem Essay Documenting Architecture Decisions (Nygard 2011) eingeführt. Ein ADR ist ein kurzes Dokument, das festhält, was entschieden wurde, warum, welche Alternativen verworfen wurden und was die Konsequenzen sind. Eine halbe Seite reicht. Klingt bürokratisch. Ist es nicht. Es ist das Unternehmensgedächtnis. Ich habe heute über 40 ADRs, und die KI liest regelmäßig darin nach.
Phase 5: Wissensmanagement als Multiplikator
Wissen ist das Futter für das System. Je besser das Wissen, desto besser die Outputs. Mein Ansatz hat drei Säulen:
Deep Research für jedes neue Thema (in Claude.ai, Gemini oder ChatGPT). Ergebnis als Markdown in einen Wissens-Ordner. Primärquellen ziehe ich automatisch als PDF nach, konvertiere sie mit pymupdf4llm in Markdown und reichere Zitationsnetzwerke über die offene Forschungsdatenbank OpenAlex an.
Evidence-Datenbank mit Konfidenz-Stufen: citation_ready, content_matched, raw, debunked. Mein Stand heute: 857 Einträge, 73 davon direkt zitierfähig, 38 widerlegt. Was als widerlegt markiert ist, darf das System nie verwenden.
Skills als wiederverwendbare Prozessbeschreibungen. Wer einen Vorgang mehr als dreimal macht, schreibt einen Skill.
Mein häufigster Lernmoment: KI-Recherchen zitieren Studien falsch. Nicht immer, aber regelmäßig. Drei Gegencheck-Runden sind Pflicht, bevor eine Zahl in einem Beitrag landet. Wie ich Fakten im System systematisch prüfe, habe ich in einem eigenen Beitrag beschrieben: KI-Faktenprüfung: Wie ein Wissenssystem Fakten prüft, bevor sie in deinem Feed landen.
Zu den Agenten selbst eine wichtige Warnung, die ich am Anfang unterschätzt habe: Weniger ist oft besser. Viele starten direkt mit mehreren Agenten gleichzeitig, weil das nach einem echten System klingt. Die Forschung zeigt das Gegenteil: Mehr Agenten bedeutet nicht automatisch besser. Der Software-Architekt Amit Kothari fasst das Problem 2025 in einer viel beachteten Analyse zusammen:
"Communication overhead follows a hard mathematical formula: n(n-1)/2. The failure rate doubles just from adding orchestration." (Kothari 2025, Multi-Agent Orchestration: The Complexity Trap)
Konkret: Multi-Agent-Systeme verbrauchen nach Kothari bis zu fünfzehnmal mehr Tokens als eine einzelne Claude-Instanz, und jenseits von vier Agenten zahlen Sie mehr für schlechtere Ergebnisse.
Meine ehrliche Empfehlung: Für den Aufbau reicht ein Agent. Claude Code im Terminal. Mehr nicht bzw. hat Claude Code auch eigenen Anthropic Agents. Eigene Agenten sind erst sinnvoll, wenn Sie wirklich parallelisieren müssen (zum Beispiel zehn Leads gleichzeitig anreichern) oder wenn ein klar umgrenzter Teilprozess oft genug wiederkehrt. Wenn es dann soweit ist, gilt: enger Aufgaben-Zuschnitt schlägt den Universal-Agenten.
Technisches Briefing für Ihr LLM (neuer Skill): Kontext: Ich möchte einen wiederkehrenden Arbeitsablauf als Skill festhalten. Ein Skill ist eine kurze Prozessbeschreibung, die ein Agent selbstständig ausführen kann. Bitte erklären und gemeinsam entwerfen: - Sniper-Prinzip: ein Skill, ein klarer Zweck. Kein Universal-Workflow. Mehrere schmale Skills schlagen einen breiten. - Frontmatter, das der Agent braucht: name, description (entscheidet über Auto-Trigger, daher präzise formulieren), input_contract (was braucht der Skill), output_contract (was liefert er), error_patterns (bekannte Fehlerfälle, damit der Agent sie erkennt). - Self-Check am Ende: der Skill prüft selbst, ob sein Output dem Contract entspricht. Nicht der nächste Schritt. - Versionierung: jeder Skill in Git, Änderungen als Commit begründet. - Messung: jede Ausführung wird bewertet (einfache Regel-Assertions reichen). Mein Prozess: [Input-Quellen, Schritte, Output-Format]. Bitte generiere eine Skill-Datei nach diesem Rahmen inklusive Fehlerfällen und Self-Check. Fortgeschrittenes (Toulmin für Analyse-Skills, Sycophancy-Gegenprüfung, Regression-Ceiling) separat als Erweiterung vorschlagen, nicht mischen.Phase 6: Frühzeitig eine zentrale Datenbank aufsetzen
Textinformationen gehören ins Dateisystem, strukturierte Daten in eine Datenbank. Ich habe anfangs auf eine Datenbank verzichtet ("Overengineering für einen alleine"). Das war mein größter struktureller Fehler.
Wichtiger Hinweis: Nicht am ersten Tag. In Woche eins baut man noch am Fundament, Ordnerstruktur, erste Skills, Gefühl für das Tooling. Aber spätestens nach einer Woche lohnt es sich, SQLite einzuziehen. Wer damit zu lange wartet, sammelt Daten in JSON-Dateien und zahlt später doppelt.
Konkret: Mein System lief vor der Migration auf sechs getrennten JSON-Dateien. Von 111 Aufgaben waren nur 17 mit einem Ziel verknüpft, nicht weil jemand vergessen hätte zu verlinken, sondern weil die Struktur es nicht konnte. Abfragen über mehrere Datenbereiche waren unmöglich. Backups deckten sechs Dateien ab, aber keine Beziehungen zwischen ihnen. Meine heute 116 Tabellen sind nicht überdimensioniert, sie sind die Grundlage für jedes Reporting und jede Automatisierung. Claude baut das Schema; Sie benennen nur die Entitäten und Beziehungen.
Technisches Briefing für Ihr LLM (SQLite-Fundament): Kontext: SQLite als zentrale Datenbank für ein KI-Agenten-System auf einem Rechner. Meist schreibt nur ein Prozess gleichzeitig. Bitte erklären und ein Start-Schema vorschlagen: - Wichtige PRAGMAs mit Begründung: journal_mode=WAL, foreign_keys=ON, synchronous=NORMAL, busy_timeout. Kurz: was macht jeder Schalter, und warum ist er für ein Solo-Setup sinnvoll? - STRICT tables für Typensicherheit. - Foreign Keys mit bewusster ON DELETE-Regel, Indexe auf Fremdschlüsseln. - Einfacher Audit-Trail über einen Trigger, der Änderungen in eine audit_log-Tabelle schreibt. - Schema-Migrationen in versionierten Up-/Down-Dateien und einer schema_version-Tabelle. - Backups über die .backup-API, nicht VACUUM INTO. - Häufige Anti-Patterns: JSON-Blobs als Mülleimer, fehlende UNIQUE- Constraints, überladene Trigger. Mein System: [3-5 konkrete Anwendungsfälle]. Schlage 5-8 Start-Tabellen vor mit Zweck, Spalten, Typen, Indexen und Beziehungen. Danach: vollständiges SQL-Schema als Init-Skript.Skalierung: Apps, Reporting, Automatisierung
Phase 7: Lokale Apps als menschenfreundliche Anzeigen
Ab einem bestimmten Datenumfang verlieren Sie den Überblick. Dann kommen lokale Web-Apps. Meine sechs Apps haben kaum noch Buttons. Sie sind vor allem Anzeigeflächen für die Daten aus Datenbank und Dateisystem. Der einzige dauerhafte Button: "An Claude übergeben" kopiert den Kontext ins Terminal. Das ist die effizienteste Arbeitsweise, die ich gefunden habe.
Phase 8: Einheitliches Reporting
Sobald Daten fließen, wollen Sie messen. Mein Fehler war: unterschiedliche Reporting-Logik in verschiedenen Apps für dieselbe Kennzahl. Heute gibt es ein zentrales KPI-Register mit Definition und Berechnungsvorschrift. Jede App zieht daraus. Wer das von Anfang an macht, spart sich Wochen an Konsolidierung.
Phase 9: Automatisierung, Selbstverbesserung und Monitoring
Über 40 Cron-Jobs laufen bei mir nachts: Wissensmanagement aufräumen, Skills automatisch testen und verbessern, Datenbank-Konsistenz prüfen, Erkenntnisse der Woche zusammenfassen. Das funktioniert nicht immer perfekt, und es hat klare Grenzen (dazu in Teil 2). Aber wenn ich einen Verdacht habe, sage ich: "Mach mal eine Analyse." Das System findet meistens, was ich suche. Manchmal auch, was ich gar nicht gesucht habe.
Ohne ständiges Überwachen geht das nicht. Und ehrlicherweise zählt Bauchgefühl: Wenn mir etwas komisch vorkommt, weise ich das System darauf hin, meistens findet es dann alle Details. Deshalb sind Automatisierung und Monitoring kein Luxus, sondern die Brille, mit der ein Einzelner überhaupt noch den Überblick behält. Blinde Flecken bleiben trotzdem. Die gibt es bei Menschen auch.
Wie weit dieser Gedanke trägt, zeigt sich in einem eigenen Unterprojekt: Das System verbessert seine eigenen Prozesse, misst die Verbesserung und behält nur, was wirklich besser ist. Details dazu folgen in einem späteren Beitrag.
Mein Messwerkzeug: jede Skill-Ausführung wird bewertet. Aktuell über 2.000 Evaluations mit Mittelwerten zwischen 0,60 und 0,87. Der schwächste Skill ist der blog-Skill selbst, mit 0,63. Ironisch für den Skill, mit dem ich diesen Beitrag schreibe.
Phase 10: Aufgabenmanagement (kurz gehalten)
Am Anfang reicht eine Markdown-Datei. Später: eine/ mehrere Datenbank Tabellen mit App. Ein Agent braucht zu wissen, was als Nächstes ansteht. Ohne das läuft er im Kreis oder erfindet Aufgaben. Wichtig: Aufgaben mit OKRs oder Projekten verknüpfen, damit der Agent versteht, worauf eine Aufgabe einzahlt.
Die größte Unbekannte: den richtigen Kontext geben
Nach zwei Monaten ist meine ehrliche Einschätzung: Die größte Unbekannte sind nicht die Modelle. Es bin ich. Ob ich die richtigen Ziele, Vorgaben, Projekte und Aufgaben gebe, das entscheidet über Erfolg oder Sackgasse mehr als jedes Architektur-Detail. Die KI wird nicht von allein sagen "ich sehe hier eine Business Chance!". Und das obwohl ich mein System explizit dazu ermuntere, anhand von Daten zu bewerten und eigene Vorschläge zu machen. Aktuell muss ich Ideen immer noch aktiv triggern, und vor allem die Querverbindungen mitgeben. Die KI berücksichtigt meinen Input und ausgewähltes internes Wissen, aber sie sieht selten von selbst, welche Abhängigkeiten zu anderen Bereichen bestehen. Perfekter, schneller Mitarbeiter, der fast alles gewissenhaft umsetzt, aber ohne den Blick über den Tellerrand.
Das ist keine Schwäche, die man wegprogrammiert. Das ist der Rahmen, den man verstehen muss, um sinnvoll einzusetzen.
Security: Grundhaltung, keine Blaupause
Security ist nicht der Fokus dieses Beitrags, aber komplett auslassen wäre unehrlich. Konkrete Architektur-Details spare ich absichtlich aus, detaillierte Beschreibungen der eigenen Verteidigungslinien erhöhen selten das Sicherheitsniveau, aber immer das Risiko. Ein paar Grundhaltungen kann ich trotzdem teilen:
Die wichtigste Entscheidung fiel am Anfang des Projekts: keine kritischen Daten auf diese Maschine. Keine Kundendaten, keine personenbezogenen Daten Dritter, keine Geschäftsgeheimnisse mit NDA. Was auf dem System liegt, sind öffentliche Studien, meine eigene Arbeit, Content-Entwürfe, Positionierung, Strategie und meine eigenen Gedanken.
Grundprinzipien, die meiner Einschätzung nach jede vergleichbare Umgebung braucht: minimale Rechte für alle Prozesse, saubere Trennung von Code und Zustand, Aufnahme externer Inhalte nur über kontrollierte Schleusen, kontinuierliches Monitoring mit Alerts. Details dazu, und vor allem: eine ehrliche Einordnung, wo Solo-Setups an Grenzen kommen und wann externe Expertise zwingend nötig wird, folgen in Teil 2.
Der wichtigste Satz vorab: Nicht anzufangen hat auch Risiken. Wer abwartet, verliert das Fenster, in dem solide Architektur mit begrenztem Risiko gebaut werden kann.
Wie viel Zeit und Geld kostet der Aufbau eines Multi-Agent-Systems?
Für das Fundament (Phasen 1 bis 5) brauchen Sie mit dieser Anleitung ein bis zwei Wochen. Ich habe ohne Anleitung zwei bis drei Wochen gebraucht.
Zu den Kosten sollte ich ehrlich sein: Der Einstieg liegt bei einem zweistelligen Monatsbetrag, Claude Pro oder ein vergleichbares Abo, plus einem alten Rechner und Open-Source-Software. Für ernsthafte Aufbauarbeit reicht das aber nicht lange. Meine eigene Kostenkurve spricht für sich: Februar rund 20 Euro, März bereits 90 Euro, jetzt im April fast 190 Euro. Ich bin mittlerweile im Claude Max Plan, weil die Limits mit wachsender Systemkomplexität immer wieder zur Bremse wurden. Aktuell gilt: wer produktiv damit arbeiten will, sollte mit einem dreistelligen Monatsbudget rechnen, nicht mit 18 Euro. Diese Abhängigkeit und Kosten sehe ich aktuell als das größte Risiko.
Zur Einordnung habe ich eine KI-basierte Schätzung für den Nachbau dieses Systems durch eine externe Agentur machen lassen: rund 50.000 Euro und drei Personen. Nach zwei Monaten Praxis halte ich die Zahl für zu niedrig, realistischer wäre wohl das Zwei- bis Dreifache, wenn man Sauberkeit, Integration und Tests mitrechnet. Es ist eine grobe Schätzung, keine Marktanalyse. Was ich aber sagen kann, ohne mir auf die Schulter zu klopfen: Ich habe in meiner gesamten Berufslaufbahn noch kein Unternehmen erlebt, das in einem so engen Ausschnitt so vernetzt, automatisiert und datenbasiert arbeitet wie dieses Solo-Setup. Das liegt nicht an mir, das liegt an der Architektur und daran, dass in Unternehmen zwangsläufig andere Kräfte wirken (Rechte, Governance, Altsysteme, Abstimmung). Trotzdem: Was in diesem Korridor heute möglich ist, überrascht mich regelmäßig selbst.
Und: Das System ist nie fertig. Es wächst mit Ihnen. Jedes Problem, das mir begegnet ist, habe ich im Tandem mit Claude gelöst. Manchmal in 20 Minuten, manchmal über mehrere Wochen.
Persönlich und unromantisch: das System macht süchtig
Ein ehrliches Wort, weil ich es sonst nirgendwo gelesen habe, aber bei mir und bei fast allen Bekannten, Freundinnen und ehemaligen Kolleginnen beobachte, die ein ähnliches System bauen: Nach anfänglicher Skepsis ist man sehr schnell hooked. Ich habe die ersten Wochen fast Tag und Nacht durchgearbeitet. Nicht, weil ich musste, sondern weil es so viel Spaß gemacht hat. Vermutlich ein kontinuierlicher Dopamin-Kick, weil man komplexe Vorhaben in wenigen Minuten umsetzen kann. Und es fiel einem immer noch kurz eine weitere Sache ein, die man "nur mal eben" testen wollte.
Diese Geschwindigkeit hat eine Kehrseite. Schneller Auf- und Umbau produziert neue Fehler, die man wieder fixen muss. Und schon sitzt man im Teufelskreis und arbeitet fast nur noch am System statt mit ihm. Das ist bei mir ehrlich gesagt bis heute so. Klassischer Scope Creep. Gleichzeitig sehe ich jede dieser Stunden als Investition und als Lernen, der Effekt verblasst nicht einfach, er akkumuliert. Trotzdem: Es frisst Zeit, es ist die eleganteste Form der Prokrastination, die ich je hatte, und in Spitzenphasen habe ich meinen Wochenablauf an Token-Limits angepasst. Wer das durchzieht, sollte sich der Wirkung bewusst sein.
Der schwierigste Teil war, rückblickend, das System überhaupt rudimentär zum Laufen zu bekommen. In dieser Zeit war ich mehrfach kurz davor, alles hinzuwerfen. Das Gefühl "das wird nie funktionieren" gehört zum Aufbau dazu. Wer diese ersten Wochen übersteht, kommt auf die andere Seite, und dort ist es dann genau das erwähnte Dopamin-Feld. Zu wissen, dass diese Phase kommt und wieder geht, hätte mir damals geholfen.
Wie schnell und produktiv ist so ein System wirklich?
Die ehrliche Antwort: schneller, als die meisten Maßstäbe zulassen. Claude hat seine eigenen Aufwands-/ Zeiteinschätzungen um den Faktor 50 bis 90 übertrieben, weil er es an menschliche Entwicklungszeit angelehnt hat. Typische neue Automatisierung oder ein Reporting-Baustein: wenige Minuten, in komplexeren Fällen 20 bis 40 Minuten, inklusive Test, Integration und Dokumentation. Die KI liest den Bestand, schreibt den Code, führt die Tests aus, dokumentiert das Ergebnis und committet. In einer Rutsche.
Die externe Validierung dafür kommt inzwischen auch aus der Forschung. Ein Working Paper des Federal Reserve Board (Grundl 2026) lässt drei Agentic-AI-Systeme (Claude Code Opus 4.6 und zwei GPT-5-Varianten) dieselbe kausale Ökonometrie-Analyse durchführen wie 146 akademische Teams mit überwiegend Promotionshintergrund. Ergebnis: Die Mediane liegen nah beieinander, in einem Blind-Review-Turnier werden die AI-Submissions sogar konstant vor den menschlichen Ausarbeitungen eingeordnet. Wichtiger Vorbehalt bleibt: Die Stochastik ist real, Opus 4.6 produzierte in 44 von 100 Läufen einen falschen Vorzeichen-Effekt bei der frei formulierten Aufgabe. Die Studie zeigt also beides: Das Leistungsniveau ist da, aber Mehrfachläufe und Plausibilitätschecks sind Pflicht. Das wiederum hat natürlich auch massive Auswirkungen auf den Tokenverbrauch...
In meinem eigenen Alltag heißt das: Das Bottleneck bin ich. Parallele Sessions aufsetzen, die groben Richtungen entscheiden, Querverbindungen herstellen, die KI mit den richtigen Hinweisen füttern. Ich arbeite zunehmend orchestrierend, strategisch, konzeptionell. Manche Fähigkeiten verlerne ich dadurch vermutlich, andere wachsen: das Gefühl, wann man messen muss, wann ein Ergebnis plausibel ist, wann man lieber nochmal gegenprüft.
Eine gesunde Portion Selbstkritik gehört dazu: Gerade Expertinnen verlassen sich mit zunehmender Erfahrung immer stärker blind auf KI-Output, das zeigen mehrere aktuelle Studien (Shaw and Nave 2026 dokumentieren, dass selbst bei bekannten KI-Fehlern Menschen in 80 Prozent der Fälle mitgehen). Ich kann das bei mir selbst bestätigen. Ich gebe viel Verantwortung ab und automatisiere ganze Prozessketten, meine Rolle ist in vielen Bereichen nur noch: Ideen geben, Projekte triggern, Querverbindungen herstellen, nachfragen. Das ist effizient. Aber es ist auch eine ehrliche Ansage an mich selbst, dass blinde Flecken kein Theoriethema sind, sondern ein tägliches Risiko.
Was wirklich den Unterschied gemacht hat (und was nicht)
Wenn Sie aus diesem Beitrag nur eine Sache mitnehmen sollen, dann bitte diese Liste.
Das waren aus meiner Sicht die echten Erfolgsfaktoren:
Ein starkes Modell im Terminal. Claude Code mit Opus 4.6 (und jetzt 4.7). Ohne ein leistungsfähiges Modell war jeder Versuch eine Frustrations-Übung. Schwächere Modelle verstehen große Kontexte nicht, planen schlecht und bauen Fehler ein, die man nicht sieht. Hier zu sparen kostet am Ende Wochen. Aber alle Modelle werden nachweislich besser, d.h. was vielleicht vor ein paar Monaten noch nicht ging, geht jetzt.
Früh anfangen, mit echten Daten, nicht mit Konzeptfolien. Keine wochenlangen Strategie-Workshops, keine KI-Framework-Tabellen, keine PowerPoint-Lenkungskreise. Mit echten, unkritischen Daten loslegen: Content-Management, Lead-Recherche, eigene Governance-Notizen. Was kritisch ist, muss jeder selbst abwägen, aber irgendwo muss man bauen, sonst lernt man nichts. Der Unterschied ist fast nie die Strategie, es ist das frühe Tun mit echten Prozessen. Learning by doing schlägt jedes Framework.
Ein sauberes Blackboard-Dateisystem mit Selbst-Dokumentation. Jeder Ordner hat eine README, jede Datei eine Kurzzusammenfassung für die KI, und jede Änderung wird von der KI selbst dokumentiert, inklusive Lessons Learned. Wer das auslässt, baut blind. Wer es konsequent pflegt, bekommt ein System, das über Monate hinweg besser wird statt schlechter.
Eine zentrale Datenbank von Woche eins. SQLite, ein Schema, eine Wahrheitsquelle. Nicht sechs JSON-Dateien, die niemand in Beziehung setzen kann. Die Datenbank ist das Rückgrat für jedes Reporting, jede Analyse und jede Automatisierung.
Skills, die laufend gemessen und verbessert werden. Wiederverwendbare, eng geschnittene Arbeitsabläufe statt Universal-Prompts. Messung pro Ausführung, Regressionsschutz bei Änderungen, Versionierung in Git. Ein Skill, ein Zweck.
Wissenschaftliche Methodik, intern und in der Recherche. Jede Analyse läuft durch ein festes Raster (Behauptung, Beleg, Konfidenz, Steel Man). Jede Zahl kommt aus einer Evidenz-Datenbank mit Konfidenz-Stufen. Bei wichtigen Fragen werden mehrere unabhängige Studien geprüft, nicht eine selektiv zitiert. Das schützt vor dem einfachsten Fehler: der KI zu glauben, weil sie überzeugend klingt.
Prozesse end-to-end automatisieren, der Mensch hält sich raus, aber überwacht. Ich bin das Bottleneck, nicht die KI. Je mehr Schritte ich in einer Kette selbst machen muss, desto langsamer läuft das Ganze. Gefühlt wird das System immer dann am besten, wenn ich mich am meisten raushalte. Aber: das bedeutet nicht weglaufen. Dashboards, Alerts, Qualitäts-Gates vor Veröffentlichung, regelmäßiges Nachsehen bleiben Pflicht. Autonomie ohne Überwachung ist Leichtsinn, Überwachung ohne Autonomie ist Mikromanagement. Beides braucht es.
Git für alles. Jede Änderung ist nachvollziehbar, jede Version wiederherstellbar. Das ist nicht Infrastruktur, das ist Überlebensversicherung.
Ein Fehler-Gedächtnis. Dokumentierte Fehlermuster, die der Agent abfragt, bevor er einen Fehler wiederholt. Das System wird nur klug, wenn es aus seinen Fehlern strukturell lernt, nicht nur im Nachhinein "schon mal gesehen" denkt.
Der Mensch als Strategie-Filter. Die KI schlägt vor, führt aus, dokumentiert. Die Strategie, die Querverbindungen und die Freigaben kommen von mir. Das System wird schlagartig schwach, wenn man diesen Punkt delegiert.
Das würde ich ausdrücklich nicht empfehlen:
Günstige oder schwächere KI-Modelle. Was an Abokosten gespart wird, zahlt man in Debugging-Zeit und schlechteren Ergebnissen mehrfach zurück. Ein kleines Modell mag für einfache Lookups reichen, aber nicht für Architekturarbeit.
Tipps und Tricks aus Reddit-Foren oder YouTube-"Power-Prompts". Die meisten sind ggf. veraltet, wissenschaftlich nicht fundiert, oft sogar kontraproduktiv. Meine Empfehlung: aktuelle Primärquellen (Hersteller-Dokumentation, peer-reviewed Paper von 2025/2026, strukturierte Erfahrungsberichte erfahrener Nutzer). Die Halbwertszeit von Tutorials in diesem Feld beträgt Wochen. Für viele Themen vertraue ich außerdem wiederum der KI: Notfalls mehrere LLM-Tools Deep Research Analysen durchführen lassen und miteinander vergleichen. Ja, Deep Researches beinhalten viele Halluzinationen, aber im Kern sind die Empfehlungen korrekt und dann kann ich auf kleinere Fehler (Studien erfunden, falsches Jahr, falsche Autoren) akzeptieren.
Gefrickel mit dutzenden Agenten in Telegram, Discord-Bots oder bunten Orchestrierungs-Frameworks. Das sieht beeindruckend aus, produziert aber Token-Kosten, Komplexität und Angriffsfläche ohne echten Mehrwert. Ich habe selbst ein solches Agenten-Framework mehrere Wochen parallel betrieben und letzte Woche bewusst zurückgebaut. Die Gründe in Kurzform: spürbar höherer Token-Verbrauch pro Aufgabe, kleinerer nutzbarer Kontext, umständliches Debugging ohne Terminal-Werkzeuge, zusätzliche Betriebs- und Angriffsfläche, und am Ende: in keinem einzigen Anwendungsfall besser als das Terminal-Setup. Für ein Solo-System gilt: weniger Infrastruktur ist sicherer und produktiver als eine beeindruckend klingende Agenten-Topologie.
Lange Konzeptionsphase vor dem ersten echten Durchlauf. Wer erst wochenlang plant, hat wochenlang nicht gelernt. In Unternehmen braucht es vielleicht ein, zwei Zusatzschleifen für Governance, aber niemand lernt durch Theorie, wie sich ein Multi-Agent-System anfühlt. Mein Rat: mit dem unkritischsten echten Prozess starten, nach jeder Woche ehrlich bewerten, was Mehrwert bringt und was nicht.
Zu früh automatisieren. Erst muss ein Prozess fünf- bis zehnmal manuell gelaufen sein, bevor er einen Cron-Job verdient. Sonst automatisiert man Müll auf Autopilot. Und die Basis/ Architektur muss sauber stehen: Ordner-/Datei-/Blackboardsystem, automatische Dokumentationen/ Lessons Learned, Datenbank, ggf. Apps und Skills.
Hardcoding und Schatten-Konfiguration. Pfade in Skripten, Secrets im Repo, Konfigurationen nur im Kopf. Alles, was nicht als Code oder Dokument existiert, verschwindet unter Arbeitsdruck.
Runtime-Daten und Code im selben Verzeichnis. Live-Datenbanken, Logs und Backups gehören strukturell getrennt vom Code-Repository. Wer die Trennung sauber zieht, schließt eine ganze Klasse von Unfällen strukturell aus.
Blindes Vertrauen bei allem, was nach außen geht. Intern vertraue ich den KI-Outputs weitreichend, das System hat sich diesen Kredit über Wochen erarbeitet. Aber sobald eine Aussage öffentlich wird (LinkedIn-Post, Blogbeitrag, Kundenkonzept), prüfe ich selbst nach. Und mir fallen auch nach der fünften KI-Prüfschleife noch Fehler auf. Eine Studie von Fernandes, Villa, Nicholls et al. (2026) zeigt den Grund: KI-Nutzung verbessert die Leistung messbar, erhöht aber die Selbstüberschätzung noch stärker. Der Dunning-Kruger-Effekt verschwindet, alle Nutzenden halten sich für gut. Wer hier nicht gegensteuert, wird schneller mit mehr Überzeugung mehr falsche Dinge sagen.
Wer diese Dinge konsequent macht und die acht vermeidet, hat den Großteil der Wegstrecke geschafft. Der Rest ist Geduld und tägliche Anwendung.
Was kommt in Teil 2: Im zweiten Teil geht es um die Schattenseite. Was mein System systematisch falsch macht (Sycophantie, Halluzination, Token-Kostendynamik) und warum Multi-Agent-Systeme nie "fertig" sind. Teil 3 beantwortet dann wie ich an das Thema Security rangegangen bin und welche Sicherheitsfragen ich nicht abschließend beantworten kann.
Teil 2 folgt in den nächsten Wochen. Arbeitstitel: "Was mein Multi-Agent-System kann und wo ich heute noch keine Antworten habe." Thema: die ehrliche Einordnung. Fehler, Risiken, Lessons Learned.
Marcus Machon berät Mittelständler bei Microsoft-365-Governance und KI-Readiness. Dieser Beitrag ist Teil 1 eines dreiteiligen Erfahrungsberichts.
In Planung: Live-Webinar. In den nächsten Wochen zeige ich dieses System live, aus dem Terminal heraus, mit echten Beispielen. Keine Folien-Show, sondern die tatsächliche Arbeitsweise.
Fehler gefunden? Bessere Quelle? Widerspruch? Ich pflege diesen Beitrag aktiv, schreiben Sie mir direkt: https://www.linkedin.com/in/marcus-machon/
Quellen und weitere Lektüre:
Bitkom e.V. (2026). Digitalisierung der Wirtschaft 2026. Repräsentative Befragung, n über 600.
Dell'Acqua, F. et al. (2026). Navigating the Jagged Technological Frontier. Harvard Business School, Organization Science.
Fernandes, Villa, Nicholls et al. (2026). AI Makes You Smarter, But None The Wiser: The Disconnect Between Performance and Metacognition.
Grundl, S. (2026). A Comparison of Agentic AI Systems and Human Economists. Federal Reserve Board Working Paper, April 2026.
Kothari, A. (2025). Multi-Agent Orchestration: The Complexity Trap. Online-Analyse.
Nygard, M. (2011). Documenting Architecture Decisions. Cognitect Blog.
Shaw, S.D. and Nave, G. (2026). Thinking Fast, Slow, and Artificial: Cognitive Surrender. 3 präregistrierte Experimente, N=1.372.
Zhang, Q. et al. (2025). ACE: Evolving Contexts via Playbooks (arXiv:2510.04618, ICLR 2026).
Zimmermann, V. (2026). Einsatz von Künstlicher Intelligenz vor allem in Unternehmen mit hohen Innovations- und Digitalisierungsaktivitäten. KfW Research, Fokus Volkswirtschaft Nr. 533, 11. Februar 2026. (Datenbasis: KfW-Mittelstandspanel 2025, n=6.845 Beobachtungen, Erhebungszeitraum 2022–2024.)
Eigene Evidence-Datenbank, Stand 21. April 2026: 857 Einträge, davon 73 citation_ready und 38 debunked.
