Forem: Benjamin Eckstein

Was ist Generative KI? Einfach erklärt

Benjamin Eckstein — Mon, 20 Apr 2026 13:00:00 +0000

Spätestens seit ChatGPT ist sie in aller Munde: Generative KI. Doch was steckt eigentlich dahinter? Dieser Überblick erklärt, wie Generative KI funktioniert und wie du heute damit anfängst.

Was ist Generative KI?

Generative KI bezeichnet KI-Systeme, die neue Inhalte erzeugen können. Im Unterschied zur "klassischen" KI, die hauptsächlich Daten analysiert oder klassifiziert, erschafft Generative KI etwas Neues: Texte, Bilder, Musik, Code oder sogar Videos.

Das Prinzip dahinter ist statistisches Lernen: Die KI wurde auf riesigen Datenmengen trainiert und hat dabei Muster erkannt. Wenn du ihr jetzt eine Aufgabe gibst, nutzt sie diese Muster, um eine wahrscheinlich passende und nützliche Antwort zu generieren.

Wichtig zu verstehen: Die KI "denkt" nicht wirklich. Sie berechnet, welche Textbausteine, Pixel oder Töne in welcher Kombination am sinnvollsten sind, und zwar auf Basis ihres Trainings.

Wie funktioniert das – vereinfacht erklärt

Das Herz moderner Generativer KI ist der Transformer, eine spezielle KI-Architektur. Transformer sind besonders gut darin, Kontext zu verstehen: Sie "wissen", dass das Wort "Bank" in "Ich sitze auf der Bank" etwas anderes bedeutet als in "Ich gehe zur Bank".

Beim Training lernt ein Large Language Model (LLM) wie GPT oder Claude milliardenfach, das nächste Wort in einem Text vorherzusagen. Aus diesem einfachen Trainingsansatz entsteht ein System, das Aufsätze schreibt, Code debuggt und Fragen beantwortet.

Die fünf Haupttypen Generativer KI

1. Text-KI (Language Models)Die bekannteste Form. ChatGPT (OpenAI), Claude AI (Anthropic) und Gemini (Google) schreiben Texte, beantworten Fragen, übersetzen und programmieren. Sie sind der Einstiegspunkt für die meisten Menschen.

2. Bild-KI (Image Generation)Tools wie Midjourney, DALL-E 3 oder Stable Diffusion erstellen Bilder aus Textbeschreibungen. Du tippst "futuristisches Stadtbild bei Sonnenuntergang, Öl auf Leinwand" und bekommst ein Bild.

3. Audio- und Musik-KI Suno und Udio erstellen ganze Songs auf Befehl. ElevenLabs klont Stimmen und erzeugt Sprachausgaben in natürlicher Qualität. Diese Technologien verändern Podcasting und Werbung grundlegend.

4. Code-KI GitHub Copilot, Cursor oder Claude AI schreiben, erklären und verbessern Code. Entwickler berichten von 30–50 % Produktivitätssteigerungen, und auch Nicht-Entwickler können damit einfache Automatisierungen erstellen. Einen praxisnahen Einstieg bietet der Use Case KI-gestützter Entwicklungsassistent.

5. Video-KI Noch jung, aber rasant wachsend: Sora (OpenAI) oder Runway erstellen kurze Videos aus Textbeschreibungen. Die Qualität steigt schnell und wird Marketing, Film und Bildung verändern.

Die wichtigsten Anbieter

OpenAI (ChatGPT, DALL-E, Sora): Pionier der Branche, breite Nutzerbasis
Anthropic (Claude): Fokus auf Sicherheit und Verlässlichkeit
Google (Gemini, Imagen): Tief integriert in Google-Dienste
Meta (Llama): Open-Source-Modelle, die jeder ohne Lizenzkosten betreiben kann
Midjourney : Marktführer bei KI-generierter Bildkunst

Grenzen und Risiken

Generative KI ist beeindruckend, aber nicht perfekt. Die wichtigsten Schwächen:

Halluzinationen: KI-Systeme können falsche Fakten selbstbewusst präsentieren. Prüfe wichtige Informationen immer gegen verlässliche Quellen.

Aktualität : Die meisten Modelle haben ein Trainings-Cutoff-Datum. Aktuelle Ereignisse kennen sie möglicherweise nicht.

Urheberrecht : Generierte Inhalte können Ähnlichkeiten mit Trainingsdaten aufweisen. Bei kommerzieller Nutzung lohnt sich juristische Vorsicht.

Datenschutz : Gib keine vertraulichen Daten in öffentliche KI-Tools ein. Für sensible Unternehmensanwendungen gibt es sichere Enterprise-Varianten. Mehr dazu in unserem Artikel KI und Datenschutz.

Wie du heute anfängst

Der beste Einstieg ist das Ausprobieren:

Erstelle ein kostenloses ChatGPT-Konto auf chat.openai.com und stelle heute eine echte Frage aus deinem Arbeitsalltag.
Teste Claude AI auf claude.ai, oft besonders stark bei langen Texten und Analysen.
Probiere ein Bildtool : Adobe Firefly ist DSGVO-konform und kostenlos nutzbar, ideal für erste Experimente.

Generative KI ist kein Hype, der verblasst. Sie ist eine Basistechnologie, die unsere Arbeitswelt dauerhaft verändert. Wer früh lernt, sie sinnvoll einzusetzen, hat einen echten Vorsprung. Den nächsten Schritt zeigt dir unser Artikel 5 Wege, wie KI deinen Arbeitsalltag verändert.

Prof. Dr. Daniel Sonnet, KI-Syndikat

Erstveröffentlichung: KI-Syndikat — ein schnell wachsendes Netzwerk aus deutschen KI-Enthusiasten, das Unternehmen bei realen KI-Projekten unterstützt, Experten aus der Branche vernetzt und eine offene Community aufbaut.

EU AI Act: Was ab August 2026 konkret für dein Unternehmen gilt

Benjamin Eckstein — Mon, 20 Apr 2026 09:26:25 +0000

Stell dir vor, du nutzt seit Monaten ein KI-Tool für die Personalauswahl. Es filtert Bewerbungen vor, priorisiert Kandidaten, schlägt dir die Top 10 vor. Praktisch und bisher ohne größere Auflagen.

Ab dem 2. August 2026 ist das anders.

An diesem Tag treten die letzten und schärfsten Bestimmungen des EU AI Acts in Kraft. Wer dann nicht vorbereitet ist, riskiert nicht nur Bußgelder in Millionenhöhe, sondern auch, dass er KI-Systeme kurzfristig vom Netz nehmen muss.

Vier Monate sind keine lange Zeit.

Was bisher gilt und was sich jetzt ändert

Den EU AI Act gibt es schon. Wir haben in unserem Artikel KI und Recht: Was Unternehmen 2026 beachten müssen die Grundlagen erklärt. Seit Februar 2025 sind die verbotenen KI-Praktiken bereits untersagt: Social Scoring, manipulative KI, Biometrie-Massenüberwachung.

Was neu ab August 2026 kommt: die vollständigen Anforderungen für sogenannte Hochrisiko-KI-Systeme. Und diese betreffen deutlich mehr Unternehmen, als die meisten erwarten.

Was ist Hochrisiko-KI und bist du betroffen?

Die Klassifizierung klingt dramatisch. Gemeint ist nicht, dass dein KI-System gefährlich ist. Es bedeutet: Die KI trifft oder beeinflusst Entscheidungen, die erhebliche Auswirkungen auf Menschen haben können.

Betroffen bist du, wenn dein Unternehmen KI einsetzt für:

Personalwesen: Bewerbungsfilterung, Leistungsbewertung, Kündigungsentscheidungen, Gehaltsanalysen (siehe auch: Anwendungsfall Bewerbersichtung)

Kreditentscheidungen: automatisierte Bonitätsprüfung, Kreditvergabe, Risikobewertung

Bildung und Ausbildung: Prüfungsaufsicht, adaptive Lernsysteme, Zugangsentscheidungen

Wesentliche Dienstleistungen: Zugang zu Sozialleistungen, Versicherungen, Gesundheitsversorgung

Kritische Infrastruktur: Energie, Wasser, Verkehr

Wichtig, und das überrascht viele: Es geht nicht nur darum, ob du selbst KI entwickelst. Auch wer Drittanbieter-Software einsetzt, etwa eine HR-Software mit KI-Bewerbungsranking, ist als Betreiber in der Pflicht. Du hast die Software nur gekauft, aber du haftest für den Einsatz.

Was du ab August 2026 konkret nachweisen musst

Für Hochrisiko-Systeme verlangt der EU AI Act eine Reihe von Maßnahmen, die dokumentiert und nachweisbar sein müssen:

Risikomanagement-System: Du musst ein laufendes Verfahren haben, das Risiken deines KI-Systems identifiziert, bewertet und minimiert. Kein einmaliger Check, sondern ein kontinuierlicher Prozess.

Technische Dokumentation: Wie funktioniert das KI-System? Auf welchen Daten wurde es trainiert? Was sind seine bekannten Grenzen? Das muss schriftlich vorliegen, auch wenn du ein fertiges Tool eines Anbieters nutzt. Relevant ist das zum Beispiel bei KI-gestützter Vertragsanalyse oder automatisierter Rechnungsverarbeitung.

Protokollierung (Logging): Hochrisiko-Systeme müssen ihre Entscheidungen protokollieren. Wer hat wann welche Empfehlung bekommen? Das muss nachvollziehbar sein.

Menschliche Aufsicht: Es muss einen klar definierten Prozess geben, bei dem Menschen KI-Entscheidungen überprüfen können, besonders bei folgenreichen Entscheidungen.

Transparenz gegenüber Betroffenen: Menschen, die von KI-Entscheidungen betroffen sind, müssen informiert werden, zum Beispiel, dass ihre Bewerbung durch ein automatisiertes System vorgefiltert wurde.

Konformitätsbewertung: Vor dem Einsatz muss nachgewiesen werden, dass das System die gesetzlichen Anforderungen erfüllt. Bei manchen Systemen reicht eine interne Prüfung, bei anderen ist eine externe Zertifizierung nötig.

EU-Datenbankregistrierung: Bestimmte Hochrisiko-Systeme müssen in einer öffentlichen EU-Datenbank registriert werden.

Was droht bei Verstößen?

Die Zahlen sind klar:

Bis zu 30 Millionen Euro oder 6 % des globalen Jahresumsatzes für Verstöße gegen Hochrisiko-Anforderungen (je nachdem, was höher ist)
Für kleinere Unternehmen gelten reduzierte Obergrenzen, aber das bedeutet nicht, dass sie nicht haften

Für ein Unternehmen mit 10 Millionen Euro Jahresumsatz wären das potenziell 600.000 Euro. Für ein Unternehmen mit 50 Millionen schon 3 Millionen.

Die gute Nachricht für KMU

Der EU AI Act hat besondere Erleichterungen für kleine und mittlere Unternehmen:

Kleinere Unternehmen müssen die technische Dokumentation in vereinfachter Form erstellen. Der Standard für Konformitätsbewertungen ist für KMU leichter erfüllbar. Die Behörden wurden angehalten, bei der Durchsetzung KMU-Interessen zu berücksichtigen.

Und es gibt eine Übergangsregelung: KI-Systeme, die bereits vor August 2026 im Einsatz sind, haben bis Februar 2027 Zeit, die neuen Anforderungen vollständig zu erfüllen.

Das ist kein Freifahrtschein, aber es gibt dir etwas Luft, wenn deine Systeme bereits laufen.

Checkliste: 8 Schritte bis August 2026

Das ist keine vollständige rechtliche Anleitung, aber ein guter Startpunkt.

1. KI-Inventar erstellen Liste alle KI-Systeme auf, die in deinem Unternehmen im Einsatz sind oder geplant werden. Auch Tools von Drittanbietern: HR-Software mit KI, Kreditrisiko-Tools, automatisierte Kundenentscheidungen.

2. Risikoklasse bestimmen Welche Systeme könnten Hochrisiko-KI sein? Nutze die Kriterien oben als Leitfaden. Im Zweifel lieber vorsichtig einordnen.

3. Anbieterkommunikation starten Frag deine KI-Softwareanbieter: Haben sie Dokumentation bereit? Was bieten sie zur Compliance an? HR-Systeme wie Personio, Greenhouse oder Workday bieten inzwischen erste EU AI Act-Dokumentationen, frag explizit danach.

4. Verantwortung intern klären Wer ist in deinem Unternehmen für KI-Compliance zuständig? Ohne klare Verantwortung passiert nichts. Das kann der Datenschutzbeauftragte sein, ein IT-Leiter oder ein eigener KI-Beauftragter.

5. Dokumentation aufbauen Beginne mit der technischen Dokumentation deiner KI-Systeme. Was tut das System? Welche Daten nutzt es? Wer hat Zugriff? Was ist beim Test aufgefallen?

6. Logging prüfen Protokolliert dein System Entscheidungen? Wenn nicht: ist das nachrüstbar? Sprich das mit dem Anbieter an.

7. Mitarbeiter informieren Alle, die mit KI arbeiten, müssen die Grundlagen des EU AI Acts kennen. Nicht als juristische Schulung, sondern: Was ist Hochrisiko? Was muss ich dokumentieren? Was darf ich nicht tun?

8. Rechtliche Beratung einholen Besonders wenn du Hochrisiko-Systeme einsetzt: Sprich mit einem Anwalt, der KI-Recht kennt. Die oben genannten Bußgelder machen Beratungskosten schnell rentabel.

Was noch nicht klar ist

Ehrlichkeit ist wichtig: Der EU AI Act lässt in der Praxis noch Fragen offen.

Wie genau wird klassifiziert? Die Grenze zwischen "begrenztem Risiko" und "Hochrisiko" ist nicht immer eindeutig. Es gibt Leitlinien der EU-Kommission, aber Rechtsprechung dazu gibt es kaum.

Wie aktiv werden die Behörden? Die nationalen Marktaufsichtsbehörden wurden gerade erst eingerichtet. Wie sie im Alltag prüfen werden, ist noch offen.

Dass du nichts tust, ist trotzdem keine gute Strategie. Wer beim ersten Prüffall gar keine Vorbereitung nachweisen kann, steht deutlich schlechter da als jemand, der zumindest die Grundlagen dokumentiert hat.

Der Zusammenhang mit DSGVO

Viele Anforderungen des EU AI Acts überschneiden sich mit der DSGVO. Wenn dein KI-System personenbezogene Daten verarbeitet, und das ist bei HR-Tools, Kundenentscheidungen oder medizinischen Anwendungen fast immer der Fall, gelten beide Regelwerke parallel.

Das bedeutet: Wer DSGVO-Prozesse aufgebaut hat, hat gute Grundlagen. Aber die KI-spezifischen Anforderungen des AI Acts kommen obendrauf.

Fazit

Der August 2026 ist näher, als er erscheint. Vier Monate vergehen schnell, besonders wenn man bedenkt, dass Dokumentation, interne Abstimmung und eventuell externe Beratung Zeit brauchen.

Die wichtigste Botschaft: Starte jetzt mit dem Inventar. Welche KI-Systeme nutzt dein Unternehmen? Schon dieser erste Schritt gibt dir Klarheit und zeigt dir, wie viel oder wenig Handlungsbedarf du wirklich hast.

Manche Unternehmen werden merken: Wir nutzen keine Hochrisiko-KI. Das wäre eine gute Nachricht. Aber das weißt du erst, wenn du's geprüft hast.

Wenn du regelmäßig Updates zu KI-Recht und Compliance bekommen möchtest, ist unser Newsletter ein guter Anlaufpunkt, ohne Spam, einmal pro Woche.

Hinweis: Dieser Artikel ist allgemeine Information und ersetzt keine Rechtsberatung. Bei konkreten Fragen zur Einstufung deiner KI-Systeme wende dich an einen spezialisierten Anwalt.

Dieser Artikel erschien zuerst im KI-Syndikat — der deutschen Anlaufstelle für alle, die KI im Unternehmenskontext ernst nehmen: mit Praxisartikeln, einer wachsenden Expert-Community und konkreten Projekten.

Was ist RAG? Retrieval Augmented Generation einfach erklärt

Benjamin Eckstein — Mon, 20 Apr 2026 09:00:00 +0000

Die meisten Unternehmen scheitern nicht am KI-Modell. Sie scheitern daran, dass das Modell ihr Unternehmen nicht kennt.

ChatGPT weiß, wie man einen Vertrag formuliert. Aber es weiß nicht, was in deinem Rahmenvertrag mit Lieferant X steht. Es kennt keine internen Prozesse, keine aktuellen Produktdaten, keine Wartungsprotokolle der Anlage in Halle 3. Und jedes Mal, wenn ein Modell über Dinge spricht, die es nicht kennt, erfindet es etwas. Das ist keine Schwäche eines bestimmten Modells. Das ist ein strukturelles Problem aller Sprachmodelle.

RAG löst dieses Problem. Nicht durch besseres Training, sondern durch einen grundlegend anderen Ansatz.

Was bedeutet RAG?

RAG steht für Retrieval Augmented Generation (auf Deutsch: „durch Abruf erweiterte Textgenerierung"). Die Idee dahinter ist überraschend simpel.

Stell dir vor, ein KI-Assistent hat keinen festen Wissensstand, sondern kann vor jeder Antwort in einem Stapel Dokumente nachschlagen: in deinen internen Handbüchern, Produktbeschreibungen, Support-Tickets oder FAQ-Dokumenten. Er liest die relevanten Stellen, und erst dann formuliert er eine Antwort.

Das ist RAG. Die KI wird nicht mit neuen Daten trainiert. Sie bekommt die Möglichkeit, kurz nachzuschauen, bevor sie antwortet. Was das mit Halluzinationen macht, erklärt unser Glossar.

Warum ist das so wichtig?

Das strukturelle Problem mit klassischen LLMs ist bekannt: Sie halluzinieren. Sie erfinden Fakten, die plausibel klingen, aber falsch sind. Besonders dann, wenn sie über etwas sprechen sollen, das sie schlicht nicht wissen.

Mit RAG passiert das deutlich seltener, weil die KI ihre Antworten auf echte, aktuelle Dokumente stützt. Wenn das Dokument eine klare Aussage enthält, gibt die KI diese weiter und kann sogar auf die Quelle verweisen.

Dazu kommt ein wirtschaftliches Argument, das wenige auf dem Schirm haben: RAG ermöglicht es, aktuelle Informationen zu nutzen, ohne das Modell neu zu trainieren. Das Training eines großen Sprachmodells kostet Millionen. Ein Dokumentensystem zu aktualisieren kostet fast nichts. RAG ist deshalb nicht nur technisch attraktiv, sondern auch ökonomisch überlegen.

Wo wird RAG eingesetzt?

Unternehmens-Wissensbasis: Du hast hunderte interne Dokumente, Handbücher, Prozessbeschreibungen. Mit RAG kann ein KI-Assistent diese durchsuchen und gezielt antworten, statt allgemeines Wissen zurückzuwerfen. Wie das konkret aussieht, zeigt unser Use Case Interne Wissensdatenbank.

Kundenservice: Statt Mitarbeiter stundenlang durch interne Dokumentationen suchen zu lassen, beantwortet ein RAG-System Kundenfragen direkt auf Basis deiner eigenen Unterlagen. Ein praxisnahes Beispiel dazu findest du im Use Case Chatbot für die Website.

Dokumentensuche: Juristische Kanzleien, Arztpraxen, Behörden: überall dort, wo viele Dokumente existieren und Wissen schnell gefunden werden muss, ist RAG ein mächtiges Werkzeug.

Support-Systeme: Wenn Techniker vor Ort eine Frage haben, können sie einen RAG-gestützten Chat befragen, der auf Wartungshandbücher, Fehlercodes und interne Protokolle zugreift.

Wie funktioniert RAG technisch (vereinfacht)?

Drei Schritte:

Indexierung: Deine Dokumente werden in kleinere Textabschnitte zerlegt und als mathematische Vektoren gespeichert. Das klingt kompliziert – es ist wie eine sehr gute Suchmaschine für Bedeutung statt Stichwörter.
Abruf (Retrieval): Wenn du eine Frage stellst, sucht das System in diesen Vektoren nach den Abschnitten, die am besten zur Frage passen. Es findet die drei bis fünf relevantesten Stellen.
Generierung: Diese Stellen werden zusammen mit deiner Frage an das Sprachmodell übergeben. Das Modell formuliert eine Antwort auf Basis dieser konkreten Inhalte.

Das Ergebnis: eine Antwort, die sich auf deine eigenen Daten stützt.

Welche Tools bieten RAG an?

Du musst kein Entwickler sein, um RAG zu nutzen. Viele Anbieter haben diese Funktion bereits eingebaut:

ChatGPT Enterprise / Teams ermöglicht das Hochladen eigener Dokumente für den Chat.
Microsoft 365 Copilot greift auf SharePoint und andere Office-365-Quellen zu.
Notion AI durchsucht dein Notion-Workspace.
Guru bietet eine speziell für Teams entwickelte Wissensdatenbank mit KI-Suche.
Spezialisierte Anbieter wie Glean oder Dust bieten RAG-Lösungen speziell für Unternehmen.

Für eigene, maßgeschneiderte Lösungen gibt es Vektordatenbanken wie Pinecone oder Weaviate sowie Open-Source-Frameworks wie LangChain oder LlamaIndex. Diese Optionen sind eher etwas für technische Teams.

Bessere Modelle erscheinen im Monatsrhythmus. Aber ein smarteres Modell hilft wenig, wenn es dein Unternehmen nicht kennt. Das ist die eigentliche Herausforderung — und RAG ist die direkteste Antwort darauf.

Die Entscheidung ist nicht: "Welches Modell kaufen wir?" Die Entscheidung ist: "Wie sorgen wir dafür, dass das Modell das weiß, was es wissen muss?" Wer diese Frage zuerst stellt, hat einen erheblichen Vorsprung gegenüber allen, die auf das nächste GPT-Update warten.

Wenn du wissen willst, wie du RAG konkret einsetzen kannst, schau auf unsere Unternehmensseite oder mach das KI-Quiz, um eine persönliche Empfehlung zu bekommen.

Multi-Agenten-Systeme: Wenn KIs miteinander arbeiten

Benjamin Eckstein — Sun, 19 Apr 2026 19:44:31 +0000

Stell dir vor, du willst einen langen Bericht über den deutschen Wohnungsmarkt erstellen. Du bittest eine KI darum. Sie recherchiert, schreibt, zitiert und liefert dir nach fünf Minuten einen Text, der gut klingt, aber bei näherer Betrachtung Zahlen aus 2023 enthält, eine Quelle falsch zitiert und einen zentralen Trend komplett ignoriert.

Was wäre, wenn stattdessen drei spezialisierte KIs zusammenarbeiten würden? Eine recherchiert und sammelt aktuelle Quellen. Eine zweite schreibt den Bericht auf Basis dieser Quellen. Eine dritte prüft Fakten und Zitate gegen die Originale. Das Ergebnis ist nicht dasselbe. Genau darum geht es bei Multi-Agenten-Systemen.

Was steckt hinter dem Konzept?

Ein einzelnes LLM kann viel. Aber es hat Grenzen: Es arbeitet in einem einzigen Kontextfenster, macht alle Schritte sequenziell, und wenn es einen Fehler macht, pflanzt sich der Fehler ins Ergebnis fort.

Multi-Agenten-Systeme teilen komplexe Aufgaben in Teilaufgaben auf und weisen jede einem spezialisierten Agenten zu. Diese Agenten kommunizieren miteinander: Sie übergeben Ergebnisse, fordern Überprüfungen an, können bei Unklarheiten rückfragen.

Das Prinzip ist das gleiche wie bei einem gut eingespielten Team. Der eine macht die Recherche, der andere schreibt, der dritte liest Korrektur. Was dabei entsteht, ist qualitativ besser als das, was eine Person alleine in derselben Zeit schafft.

Ein konkretes Beispiel: Marktanalyse in Agentenstufen

Nehmen wir eine realistische Aufgabe: Du willst eine Wettbewerbsanalyse für ein neues Produkt erstellen.

Der Research-Agent bekommt die Aufgabe, aktuelle Informationen zu Wettbewerbern zu sammeln. Er hat Zugriff auf Web-Suche, kann Seiten aufrufen und strukturierte Daten extrahieren. Tools wie Perplexity zeigen, wie KI-gestützte Recherche in der Praxis aussieht. Sein Output ist keine fertige Analyse, sondern eine strukturierte Quellensammlung mit relevanten Fakten.

Der Analysis-Agent nimmt diese Quellensammlung und wertet sie aus. Er vergleicht Preise und Marktpositionierungen, bewertet Features. Er braucht keinen Internetzugang mehr, sondern arbeitet nur mit dem, was der Research-Agent geliefert hat. Das verhindert, dass er anfängt, selbst zu "erfinden".

Der Writing-Agent bekommt die strukturierte Analyse und erstellt daraus einen lesbaren Bericht in dem gewünschten Format und Ton.

Ein optionaler Fact-Check-Agent prüft abschließend konkrete Zahlen und Zitate gegen die Originalquellen.

Das Entscheidende: Jeder Agent hat eine enge, klar definierte Aufgabe. Das macht jeden Schritt überprüfbarer und Fehler leichter zu lokalisieren.

Was das ermöglicht, was ein einzelnes Modell nicht kann

Das offensichtlichste ist Parallelarbeit. Statt einer langen Kette nacheinander können mehrere Agenten gleichzeitig an verschiedenen Teilen eines Problems arbeiten. Das spart Zeit bei umfangreichen Aufgaben.

Wichtiger ist aber die Qualitätsebene: Spezialisierung. Ein Agent, der ausschließlich für Faktenprüfung zuständig ist, wird besser prüfen als ein Generalist, der nebenbei auch schreibt. Das ist kein Mythos. In der Praxis zeigen spezialisierte Agenten bei ihrer Kernteilaufgabe weniger Fehler als Einzel-Prompts an ein allgemeines Modell.

Außerdem können Agenten mit verschiedenen Tools ausgestattet werden. Der Research-Agent hat Internetzugang. Der Writing-Agent hat Zugriff auf dein CMS. Der Fact-Check-Agent hat Zugriff auf deine interne Wissensdatenbank. Kein einzelner Agent braucht alles, jeder bekommt nur, was er für seine Aufgabe braucht.

Was ist heute produktionsreif — und was nicht?

Das ist die Frage, bei der viele Tech-Artikel unehrlich werden. Also klar gesagt:

Multi-Agenten-Systeme sind in der Praxis heute ernsthaft einsetzbar, wenn die Aufgaben gut strukturiert sind und die einzelnen Schritte klar abgrenzbar bleiben. Datenaufbereitung, Content-Workflows, strukturierte Recherche und Code-Review-Pipelines funktionieren.

Was noch nicht zuverlässig funktioniert: Agenten, die sehr viel freie Entscheidungsgewalt haben, ohne menschliche Kontrollpunkte. Wenn ein Agent einen Fehler macht und der nächste diesen Fehler als Wahrheit übernimmt, kann sich das durch die ganze Pipeline fortsetzen. "Agentic" bedeutet nicht "fehlerfrei".

Frameworks wie LangGraph, AutoGen oder CrewAI machen es leichter, solche Systeme zu bauen. Für Unternehmen ohne Entwicklungskapazitäten können auch No-Code-Automatisierungstools wie Make oder Zapier als Einstieg in agentenähnliche Workflows dienen. Aber die eigentliche Arbeit liegt im Design: Welche Aufgaben gehören in welchen Agenten? Wo brauche ich einen menschlichen Kontrollpunkt? Was passiert, wenn ein Agent keinen sinnvollen Output liefert?

Wer tiefer in das Thema einsteigen will, findet in unserem Artikel über KI-Agenten eine gute Grundlage für die technischen Konzepte dahinter.

Wann macht das für Unternehmen Sinn?

Nicht bei jeder Aufgabe. Multi-Agenten-Systeme haben Overhead: Sie sind komplexer aufzubauen, schwieriger zu debuggen und teurer im Betrieb als ein einfacher Prompt an ein einzelnes Modell.

Es lohnt sich, wenn drei Dinge zusammenkommen: Die Aufgabe ist wiederkehrend (sonst rechnet sich der Aufbau nicht), sie ist in klar abgrenzbare Teilschritte zerlegbar, und die Qualitätsanforderungen rechtfertigen den Aufwand.

Konkrete Szenarien, die in der Praxis gut funktionieren:

Content-Pipelines für Unternehmen, die regelmäßig Berichte, Produktbeschreibungen oder Artikel produzieren. Research → Draft → Review → Formatting ist ein natürlicher Agenten-Workflow. Wie das konkret aussieht, zeigt unser Use Case zur automatisierten Content-Produktion.

Datenanalyse und Reporting , bei denen strukturierte Daten aus verschiedenen Quellen zusammengeführt, ausgewertet und in verständliche Berichte verwandelt werden. Mehr dazu im Use Case Automatisierte Berichterstellung.

Kundensupport-Workflows , bei denen ein Agent das Anliegen klassifiziert, ein zweiter relevante Informationen aus der Wissensdatenbank holt und ein dritter die Antwort formuliert.

Wer KI-Agenten bereits im Unternehmen einsetzt, kann Multi-Agenten-Systeme als natürliche Erweiterung betrachten, wenn die Einzel-Agenten stabil laufen.

Was du noch nicht übersehen solltest

Kosten. Mehrere Agenten bedeuten mehrere API-Aufrufe. Bei komplexen Pipelines mit vielen Agenten können die Token-Kosten schnell steigen, besonders wenn lange Kontexte weitergegeben werden.

Latenz. Agenten, die aufeinander warten müssen, brauchen Zeit. Für Echtzeit-Anwendungen (etwa Kundenchat) sind Multi-Agenten-Systeme derzeit oft zu langsam.

Komplexität. Wenn ein System aus fünf Agenten unerwartetes Verhalten zeigt, ist es schwieriger zu debuggen als ein einzelner Prompt. Fang klein an: zwei Agenten, klare Aufgaben, saubere Übergabe.

Wie du anfängst

Nicht mit einem Framework. Sondern mit einer Frage: Gibt es in deinem Workflow heute eine Aufgabe, die in zwei klar trennbare Schritte zerfällt, bei der der zweite Schritt erheblich besser wird, wenn der erste wirklich gut war?

Wenn ja, hast du den Kern eines Zwei-Agenten-Systems. Baue das erst. Schau, ob es funktioniert. Füge dann, wenn nötig, weitere Schritte hinzu.

Multi-Agenten-Systeme sind kein Selbstzweck. Sie sind eine Architekturentscheidung, die sich dann lohnt, wenn sie eine echte Qualitäts- oder Effizienzlücke schließt.

Willst du regelmäßig informiert bleiben, wenn neue Entwicklungen in diesem Bereich produktionsreif werden? Der Newsletter hält dich auf dem Laufenden — ohne Hype, mit Fokus auf das, was wirklich funktioniert.

Reasoning Models sind kein Upgrade, sie sind ein anderes Werkzeug

Benjamin Eckstein — Sun, 19 Apr 2026 19:42:29 +0000

Stell dir vor, du bezahlst für ein Modell das viermal so oft falsch liegt und vierzehn mal so viel kostet wie das Standardmodell. Das klingt absurd. Und es ist passiert: In einer Evaluation von splx.ai aus 2025, die o3-pro gegen GPT-4o in einem Versicherungs-Use-Case getestet hat, verlor das "bessere" Modell auf ganzer Linie.

Das ist nicht das Versprechen, das OpenAI macht, wenn es Reasoning Models vorstellt. Aber es ist die Realität, wenn du ein Präzisionswerkzeug für die falschen Aufgaben verwendest.

Was alle denken, und warum es falsch ist

Die verbreitete Vorstellung: Reasoning Models sind bessere Sprachmodelle. Mehr Rechenpower, mehr Intelligenz, bessere Antworten. Du solltest sie verwenden, wenn du gute Ergebnisse willst.

Das stimmt nicht. Reasoning Models sind ein anderes Werkzeug, kein besseres.

Standard-LLMs generieren Token für Token: direkt und ohne Umweg. Das klingt simpel, funktioniert aber für die überwiegende Mehrheit aller Aufgaben besser, als man erwarten würde. Reasoning Models dagegen generieren vor jeder Antwort einen internen "Gedankengang". Sie arbeiten das Problem Schritt für Schritt durch, prüfen Zwischenergebnisse, korrigieren sich selbst. Dieser Prozess kostet Zeit und Geld. Bei manchen Aufgaben lohnt er sich. Bei den meisten nicht.

o3-pro kostet laut OpenAI-API derzeit 20 Dollar pro Million Input-Tokens. GPT-4o liegt bei 2,50 Dollar. Das ist Faktor 8 beim reinen Token-Preis. Faktor 14 ergibt sich, wenn du die "Thinking Tokens" einrechnest, die der Reasoning-Prozess zusätzlich generiert und die nicht im regulären Input-Preis enthalten sind.

Wann Reasoning Models tatsächlich besser sind

Drei Aufgabentypen rechtfertigen den Aufpreis tatsächlich.

Mathematik mit mehreren Zwischenschritten. Steuerberechnungen mit Ausnahmeregelungen, Wahrscheinlichkeitsrechnung, Optimierungsprobleme. Überall dort, wo eine falsche Zwischenannahme die Endantwort zerstört. Standard-Modelle scheitern hier regelmäßig, auch wenn sie die Antwort selbstsicher formulieren.

Widersprüchliche Dokumente auflösen. Wenn zwei Vertragsklauseln sich widersprechen, wenn regulatorische Anforderungen aus verschiedenen Quellen kollidieren: Reasoning Models benennen die Widersprüche explizit, anstatt sie wegzuglätten. Für Vertragsanalyse mit KI ist das relevant.

Bugs in komplexen Architekturen. Nicht für das Schreiben von Funktionen, sondern für das Nachvollziehen von Fehlerursachen über mehrere Schichten. Reasoning Models können Abhängigkeitsketten besser durchdenken als Standardmodelle, auch ergänzend zu Tools wie Cursor oder GitHub Copilot.

Strategische Planung mit harten Constraints."Plane einen Launch in drei Märkten gleichzeitig, mit diesem Budget, unter diesen regulatorischen Einschränkungen." Standard-Modelle produzieren hier generischen Output. Reasoning Models arbeiten Widersprüche und Tradeoffs expliziter heraus.

Ein Benchmark macht den Unterschied greifbar: Auf ARC-AGI, einem Test für neuartige Problemlösung (nicht Auswendiglernen), erreichte GPT-4o laut arcprize.org gerade einmal 5%. o3 kam auf 75,7%. Das ist keine marginale Verbesserung. Das ist ein anderes Werkzeug für eine andere Aufgabenkategorie.

Der gemeinsame Nenner: Die Aufgabe hat eine objektiv richtige oder falsche Antwort, und sie erfordert mehrere korrekte Zwischenschritte.

Das Overthinking-Problem ist real

Reasoning Models haben eine Schwäche: Sie überkomplizieren einfache Probleme.

Das zeigt die splx.ai-Evaluation konkret: Bei einem Versicherungs-Use-Case produzierte o3-pro viermal so viele fehlgeschlagene Testfälle wie GPT-4o. Nicht weil o3-pro dümmer wäre, sondern weil das Modell Entscheidungspfade durchdenkt, die für eine strukturierte Pipeline schlicht nicht existieren. Es konstruiert Komplexität, wo keine ist.

Für kreative Aufgaben ist das besonders problematisch. Beim Brainstorming ist Geschwindigkeit und Varianz wichtiger als Präzision. Reasoning Models tendieren dazu, Ideen intern zu verwerfen, bevor sie sie aussprechen. Das klingt nach Qualitätskontrolle. Es ist aber Kreativitätsbremse.

Und dann ist da noch das Benchmark-Problem. Als OpenAI o3 im Dezember 2024 vorstellte, behauptete das Unternehmen, das Modell löse über 25% der Aufgaben auf FrontierMath, einem extrem schwierigen Mathe-Benchmark. Das nächstbeste Modell lag bei 2%. Als Epoch AI, das Institut hinter FrontierMath, o3 unabhängig testete, kam es auf rund 10%. Die ursprünglichen Zahlen stammten von einer Testversion mit mehr Rechenpower als das öffentlich zugängliche Modell. Das ist kein Betrug. Aber es ist ein Hinweis, wie stark Reasoning-Fähigkeiten von Compute abhängen, und wie vorsichtig man mit Benchmark-Versprechen umgehen sollte.

Die wichtigsten Reasoning Models

o4-mini ist die einzige Wahl mit vertretbarem Kosten-Nutzen-Verhältnis für die meisten Anwendungsfälle: deutlich günstiger als o3, Reasoning-Fähigkeiten, die für Mathematik und Widerspruchsanalyse ausreichen, und schnell genug für interaktive Nutzung.

o3 lohnt sich für produktionskritische Pipelines, bei denen ein Fehler echten Schaden anrichtet: Steuerberechnungen, juristische Analyse, komplexe Codearchitektur. Für alle anderen Zwecke ist der Aufpreis gegenüber o4-mini nicht zu rechtfertigen.

o3-pro ist schwer zu begründen. Der Preisunterschied zu o3 ist erheblich. Der Qualitätsgewinn ist marginal, und die splx.ai-Evaluation zeigt, dass höherer Aufwand nicht automatisch bessere Ergebnisse bedeutet.

Claude 3.7 Sonnet mit Extended Thinking gewinnt, wenn Nachvollziehbarkeit wichtiger ist als Rohleistung: Der sichtbare Gedankengang macht Fehler auffindbar, bevor sie eskalieren. In reinen Benchmark-Vergleichen verliert Claude gegen o3, in Kontexten mit menschlicher Überprüfung ist das oft der falsche Maßstab.

Gemini 2.0 Flash Thinking bleibt ein Randfall — interessant für latenzempfindliche Anwendungen, aber ohne klares Alleinstellungsmerkmal gegenüber o4-mini bei vergleichbaren Kosten.

Eine einfache Entscheidungshilfe

Vor der Modellwahl drei Fragen:

Erfordert die Aufgabe mehrere abhängige Rechenschritte, bei denen ein Fehler alles Nachfolgende zerstört? Reasoning Model.

Gibt es eine objektiv richtige Antwort, die sich überprüfen lässt? Reasoning Model.

Ist die Aufgabe offen, kreativ, schnell oder sprachlich? Standard-Modell.

Die Faustregel für API-Nutzung: Wenn du nicht explizit weißt, warum diese Aufgabe Reasoning braucht, braucht sie kein Reasoning.

Reasoning Models sind ein echter Fortschritt für einen spezifischen Aufgabentyp. Das Problem ist nicht die Technologie. Es ist die Erwartung, dass "mehr Denken" grundsätzlich besser ist. Manchmal ist es das Gegenteil, und der Beweis kostet dich 14x mehr.

Wer wissen will, welches Modell für welche Aufgabe tatsächlich besser abschneidet, findet im KI-Syndikat Newsletter regelmäßig ungeschönte Einordnungen zu neuen Modellen und Evaluationen.

$187 and 16 Hours: My First Million-Token Session

Benjamin Eckstein — Mon, 06 Apr 2026 07:23:00 +0000

Two things landed in the same week: the 1 million token context window and the Claude Agentic Teams beta. One gave me room to think. The other gave me a way to parallelize. I did what any reasonable engineer would do: I immediately tried to break both with something too ambitious.

The plan: build a complete cashback campaign web application — backend, frontend, full test suite, containerized deployment — in a single session. One orchestrator. Eight specialized agents spawned as a team. Don't stop until it's live.

What actually happened is more interesting than either the successes or the failures on their own.

The Setup

The Agentic Teams feature was the key enabler. Instead of one agent doing everything sequentially, I had an orchestrator that spawned specialized subagents — each with its own fresh context window, each focused on one domain:

Backend implementer — Spring Boot service, API endpoints, business logic
Frontend implementer — React SPA wired to the backend
QA reviewer — running tests, flagging gaps, reviewing coverage
Deployment agent — Dockerfile, compose files, deployment configuration
Git agent — branches, commits, keeping the repo clean
PR handler — pull request creation, descriptions, review assignments
CI monitor — watching the pipeline, catching failures early
Slack notifier — status updates to the team channel

The combination of 1M context and teams changed the equation fundamentally. The orchestrator held the big picture — architecture, decisions, coordination — while each subagent got a fresh context dedicated entirely to its domain. No context pollution between concerns. The backend implementer's window wasn't cluttered with CSS decisions. The deployment agent didn't carry the weight of test output.

That's not a bigger notepad. That's a qualitatively different way of working.

The Numbers

Let me give you the receipt before the narrative.

Metric	Value
Total cost	$186.92
Wall time	16 hours
API time	7 hours 42 minutes
Lines of code written	5,800+
Backend tests	649 (all passing)
End-to-end tests	80 (all passing)
Orchestrator context at completion	34.8% used

The gap between wall time and API time tells its own story. Nine-ish hours of waiting — for builds to complete, for containers to spin up, for CI pipelines to run, for me to review and redirect. The agent system was genuinely idle for more than half the clock time. Multi-agent work is often more about managing parallelism and wait states than it is about raw token throughput.

The context number needs explanation: 34.8% is the orchestrator's context usage — the central agent coordinating everything. But here's the thing about agentic teams: every subagent spawns with a fresh context window. The backend implementer burned through most of its own context writing 3,000+ lines of Spring Boot code. The frontend implementer filled a separate window with React components. The total tokens consumed across all agents was many multiples of what the orchestrator alone used.

The 1M window mattered for the orchestrator's ability to hold the full project state — every architectural decision, every agent's status, every failure and recovery — without summarization loss. The subagents benefited from fresh context dedicated entirely to their domain.

What We Built

A cashback campaign web application. Users register for campaigns, submit purchase verification, and receive cashback payouts. Backend exposes REST endpoints with full authentication, campaign management, submission handling, and payout processing. Frontend handles the user journey: campaign listing, submission form, status tracking, account management.

649 backend tests covering units, integration, and API contracts. 80 end-to-end tests exercising complete user flows against the deployed system. Both suites passing at the time of deployment.

Containerized with Docker, deployed to a demo server, accessible over HTTPS. The full stack was live — not prototype-live or local-dev-live, but actually deployed and running with a URL you could share.

In one session.

What Broke

Three things broke in ways worth documenting.

The UI refinement agent hung mid-session. About ten hours in, I spun up an additional agent to polish the frontend styling. It started working, then stopped producing output, then started again, then stopped permanently. The process was still running — consuming tokens, returning nothing meaningful. I had to force-kill it and redistribute its remaining tasks to the frontend implementer. Cause: unclear. Hypothesis: the context had accumulated enough ambiguous signal that the agent entered a local minimum and couldn't exit without human intervention. I'd seen this behavior before in shorter sessions. At this scale it cost more time. (I wrote a full postmortem on this and three other multi-agent failures in The Agent That Hung.)

Docker configuration required multiple debug cycles. The deployment agent's first three attempts at the Dockerfile produced images that built successfully and failed at runtime. The failure modes were different each time: wrong environment variable name, missing health check endpoint, volume mount path mismatch. None of these were hard problems — they were the kind of thing that takes ten minutes to fix once you know what's wrong. But each cycle was 15-20 minutes of build time, which adds up. The agent wasn't wrong in a systematic way; it was wrong in a random way, which is harder to diagnose.

CORS whitelisting was missing from the first live deployment. The backend deployed, the frontend deployed, we hit the first real URL from a browser — and got CORS errors. The frontend and backend were on different origins, and nobody had configured allowed origins in the API. This is the kind of thing that's trivially obvious in hindsight and invisible when you're thinking about everything else. We fixed it in twenty minutes, but the gap between "it works in tests" and "it works when you actually open a browser" is real and shouldn't be understated.

The failures were recoverable. None of them were catastrophic. But they're worth naming because the narrative of "multi-agent AI builds complete app in one session" can make it sound smoother than it is.

Was $187 Worth It?

This is the question everyone asks.

$186.92 for a complete, deployed, tested web application. The question is: compared to what?

My estimate for solo development of this system — evenings and weekends, the realistic mode for a side project — is two to three weeks. That's probably 40-60 hours of actual coding time, spread across a month of calendar time. You don't get it faster by working harder; you get it faster by having more hours available.

The session compressed that into one long stretch — starting the evening of the 17th and spanning into the early hours of the 18th. Not just in wall time, but in context. When you're working across three weeks of evenings, you spend a non-trivial portion of each session re-establishing context. What did I build last time? Where did I leave off? Why did I make this architectural decision? The 1M context window meant that never happened. Every agent at every moment had access to the full state of the project.

That context compression is the value. The $187 isn't paying for code generation — you can get code generation cheaply. It's paying for unbroken continuity across an entire project, from empty repository to deployed application.

Is $187 a lot? It's a dinner out. It's less than an hour of consulting time. For what it produced, it's laughably cheap if the output is usable — and in this case, the output was usable.

The ROI question gets harder when you ask: "Okay but I'm paying $187 per feature, how does that scale?" Fair. If you're running sessions like this weekly, you're spending $800-1000 a month on context. That's not nothing. But you're also compressing weeks of work into days, and the comparison baseline should be "what would I pay a contractor" rather than "what would I pay in compute."

What 1 Million Tokens Actually Changes

The marketing around large context windows is often vague in ways that obscure the real value.

It's not about fitting more files in. You could always load more files into multiple sessions. The point isn't storage capacity.

It's about the orchestrator holding the full picture. The 1M window lets the coordinating agent track every decision, every failure, every architectural choice across a 16-hour session without ever summarizing or losing nuance. When the backend agent reports a schema change, the orchestrator passes that context to the frontend agent accurately — not through a lossy summary, but through the actual decision with its reasoning intact.

Teams multiply the effective context. Eight agents, each with their own context window, means the system's total working memory is far larger than 1M tokens. Each specialist gets a fresh window focused on its domain. The orchestrator's 1M window coordinates between them. It's not one big context — it's an architecture of contexts.

It eliminates the summarization tax at the coordination layer. Shorter orchestrator windows mean you're constantly summarizing: "here's what I built, here's the current state, here's what's failing." Every summary introduces loss. With 1M tokens on the orchestrator, everything that happened across all eight agents was still trackable. No lossy handoffs.

It makes failures recoverable without restart. When the hung UI agent had to be killed, the orchestrator still had the complete context of what it had attempted. Spinning up a replacement agent with the right instructions was straightforward — the orchestrator knew exactly where the work had left off.

This is why I described it as a different way of building software. Not a bigger version of the old way. A different mode that becomes available when you combine a large orchestrator context with specialized parallel agents.

What I'd Do Differently

Not much — but a few things.

I'd add CORS configuration to a deployment checklist from the start. Not because it's hard to add, but because it reliably gets forgotten and costs time. The pattern is consistent enough that it should be institutional knowledge.

I'd build in explicit agent health checks. The hung UI agent was running for over an hour before I noticed it wasn't producing useful output. A simple "if no meaningful output in X minutes, flag for human review" rule would have caught it faster.

I'd be more aggressive about pre-splitting the frontend work. At the scale of a complete application, the frontend implementer had a lot of surface area. Splitting that into UI components and data integration from the start would have parallelized more work.

The Meta-Point

I did this in February 2026. The 1M token context window was new. The Agentic Teams beta was new. The multi-agent orchestration patterns were things I'd been building for months. Everything converged at once.

What struck me most wasn't the output — it was the experience of building. For sixteen hours, I wasn't typing. I wasn't writing code. I was making decisions, reviewing outputs, redirecting agents, thinking about architecture. The implementation was handled. The thinking was mine.

That's the mode I think agentic engineering is pointing toward: not "AI writes the code for me" but "I architect while AI implements, continuously, in real time." The session wasn't sixteen hours of watching progress bars. It was sixteen hours of directed creative work, at a level of abstraction above the code.

Whether that's exciting or unsettling depends on where you stand. For me, it's both, which is usually a sign that something real is happening.

The $187 was money well spent. The sixteen hours taught me more about multi-agent system design than any tutorial could. The receipt is right there in the API billing dashboard.

Now I know what a million tokens feels like from the inside. (What I learned next — making those systems production-ready — is in Production Hardening.)

The 22,000 Token Tax: Why I Killed My MCP Server

Benjamin Eckstein — Wed, 01 Apr 2026 20:53:07 +0000

I was at a company workshop, arguing with beginners about token costs.

They wanted to save money. Reasonable instinct. They were spending maybe €25 a week on API calls and wanted to cut it to €20. I pushed back hard: "You're at the learning stage. Spend more, not less. Explore. Break things. Create costs.
Because while you're saving €5, I'm spending €600 a week — and I'll gladly spend €20 more if it means finishing a ticket in one session instead of two."

Then I told them the one scenario where token consumption actually matters: when you need to prolong a session. Not to save money — to preserve context. Because when your session compacts or resets, you lose everything the model was holding in its head. And in the early days of Claude Code, there was no auto-compact. Your session just died with an error when you hit the limit. Auto-compact made this better, but you never know what survives the squeeze. Research confirms what I've felt in practice: context length alone hurts LLM performance, even when the relevant information is right there. The longer your context, the worse the output — a phenomenon sometimes called context rot. So every unnecessary token you load at startup is a tax on the quality of everything that follows.

I came home that evening and opened a new session. Ran /context. Stared at the breakdown.

22,000 tokens in MCP tools alone. Before I typed a single prompt.

The Receipt

I had three MCP servers running: mcp-atlassian for Jira and Confluence, chrome-devtools for browser automation, and context7 for documentation lookups. Together they cost 22K tokens. But the Atlassian server was the one I could kill — it was registering 33 tools for a service where I used six.

I'd gone through the settings and disabled as many as I could — but the server kept loading all of them. Confluence tools I never used. Batch operations. Sprint management. Worklog tracking. None of it mattered.

All 33 tools. About 10,000 tokens. Every single session.

I compared the numbers. One skill — 40 tokens of metadata. One MCP tool — 300 tokens of schema. The Atlassian MCP was loading tools I had explicitly told it not to load.

The Setting That Doesn't

Here's what disabledTools actually does in Claude Code: it prevents the AI from calling a tool. That's it.

It does not prevent the MCP server from starting. It does not prevent the server from registering its tools. It does not prevent those tool schemas from being injected into the context window. The Docker container still spins up. The tool definitions still flow in. The tokens still burn. disabledTools is a runtime filter, not a context optimization. I was disappointed — if the setting exists in the configuration, you'd expect the platform to be smart enough to not load what you've explicitly disabled. But that's not how it works.

The only way to actually save the tokens is to remove the MCP server entirely.

The Replacement: 7 Scripts

I looked at what I actually use. Six Jira operations. Zero Confluence operations. Out of 33 registered tools, I needed six.

So I wrote shell scripts. The same pattern I already use for Jenkins and Slack — credentials in a JSON file under ~/.config/, curl calls with Bearer token auth, jq for parsing responses.

The first script took five minutes. Authentication worked on the first try — just Authorization: Bearer <token> with the same personal access token the MCP had been using. No Docker container. No protocol negotiation. No tool registration. Just curl.

  TOKEN=$(jq -r '.personal_token' ~/.config/jira/credentials.json)
  BASE_URL=$(jq -r '.base_url' ~/.config/jira/credentials.json)

  curl -s -k -H "Authorization: Bearer $TOKEN" \
    "$BASE_URL/rest/api/2/issue/PROJ-123"

The credentials file should be chmod 600 (owner-only read/write).

The -k flag skips SSL certificate verification because our internal Jira uses a self-signed cert — don't copy that for public endpoints. And yes, the token ends up in the process list briefly via shell variable expansion. For a local developer workstation running personal scripts, that's an acceptable trade-off. For a shared server or CI pipeline, you'd want to pipe credentials through stdin instead.

Cairn built all six scripts in under an hour. I fed the Jira REST API documentation into the session for context, described the pattern I wanted, and Cairn wrote the scripts, tested them against our live Jira, and verified each one worked. I gave it a real ticket number to go wild on — fetch, update, transition, comment, the full lifecycle. Then we fine-tuned the scripts to bake in our project defaults: the right component, the right team label, the custom fields our board requires. Get issue. Search with JQL. Update fields. Add comment. Get transitions. Transition status. Each script reads credentials, makes a curl call, formats the output. No abstraction layer. No protocol. No 300-token tool schema.

Then I added a seventh: create issue.

The Thing MCP Could Never Do

Creating Jira tickets through MCP never worked reliably. I'd hit the MCP permission wall before — specialized agents couldn't even access the tools. But even when access worked, the actual creation flow — with custom fields, project-specific components, team assignments — always hit edge cases that the MCP abstraction couldn't handle cleanly.

The curl script created a ticket on the first try.

  curl -s -k -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"fields": {
      "project": {"key": "PROJ"},
      "issuetype": {"name": "Task"},
      "summary": "Test ticket",
      "components": [{"name": "Frontend"}],
      "customfield_12345": [{"value": "Team-A"}]
    }}' \
    "$BASE_URL/rest/api/2/issue"

HTTP 201. The ticket existed. With the right component, the right team, the right assignee. First try.

The MCP had been sitting between me and a REST API that was perfectly willing to cooperate. It was abstracting away complexity that didn't exist.

The Abstraction Tax

MCP is a good idea for getting started. You install a server, you get tools, you're productive in minutes. For someone spending €25 a week who's still learning, that's the right trade-off. The setup cost is zero and the token cost doesn't matter because you're not pushing session limits.

When you're 5,428 prompts deep into a persistent agent system, running multi-agent workflows that eat 100K+ tokens per ticket, every unnecessary token at startup compresses the useful work you can do before quality starts degrading. I've learned this lesson before — 23K tokens burned loading a bloated memory file. Now it was 10K tokens burned loading Jira tools I'd explicitly disabled. Same tax, different landlord.

And here's the part that bothered me most: I couldn't partially load the MCP server. It's all or nothing. Want 6 tools? You get 33. Want to disable the other 27? You can — but you still pay for all 33 in your context. The protocol has no mechanism for selective tool registration based on client preferences.

So I replaced it:

33 MCP tools with 7 shell scripts
~10,000 tokens per session with 0 tokens at startup
Docker container on every launch with no container
Issue creation broken with Issue creation works
Tool schemas you can't customize with Scripts you own completely

The seven scripts total about 700 lines of bash. They live in my skill directory, version-controlled, testable. I can read them. I can debug them. I can add project-specific defaults — like auto-applying the default component and team for every ticket in our project. Try doing that in an MCP tool schema.

And I know exactly what they do. That MCP server was a Docker image pulled from a third-party registry, running with my Jira credentials baked into environment variables. I never audited that image. I never read its source. Every docker pull could have shipped a different binary. When your integration is 700 lines of bash that you wrote and can read end to end, supply chain risk isn't a concern — it's just curl.

When to Graduate

MCP stops making sense the moment you're paying for tools you don't use and can't shed. When you need 6 tools but get 33. When 10K tokens burn before your first prompt. When you need capabilities the server doesn't expose. When you need project-specific behavior that the protocol can't express. That's when you graduate.

The graduation path is simple: credentials file, curl, jq. The same tools that powered the internet before every API got wrapped in an abstraction layer. They still work. They're still faster. And you own them completely.

They don't cost you a single token to say hello.

What I Actually Learned

This isn't new. It's what every software engineer has done since the beginning: make it work first, then optimize. The MCP got me running. It was the right choice when I was figuring out how to wire an AI agent to Jira at all. But once it worked, the job was to look at the bill and cut the waste. That's not AI-specific wisdom — that's just engineering.

Integrations have carrying costs. An MCP server isn't free just because it's open-source. A tool registry isn't free just because the tools are disabled. Every abstraction layer between your code and the API it talks to has a price — in tokens, in debuggability, in flexibility, in the things you can't do because the abstraction didn't anticipate your use case.

Sometimes the best integration is the one with no integration layer at all.

Originally published at CodeWithAgents.de

Skills Ate My Agents (And I'm Okay With That)

Benjamin Eckstein — Wed, 18 Mar 2026 21:44:27 +0000

I was showing off my system to colleagues.

Eighteen specialized agents, each a craftsman at their job: one for git operations, one for PRs, one for Slack notifications, one for Jenkins diagnostics, one for Maven tests. I’d named them, written their AGENT.md files, built their CHANGELOG.md evolution histories. Cairn — my persistent AI orchestrator — coordinated them like a conductor with a full orchestra. While colleagues were still integrating their first MCP tool to give Claude filesystem access, I already had an optimizer agent updating 18 other agents’ instructions based on their operational logs. It worked. It was the frontline.

Then one colleague asked the question that changed everything.

“Why don’t you use skills for it?”

The moment one question broke everything

I talk about comfort zones on this website. I have a whole post about the walls that teach you the most — the invisible ceilings you only discover when something from outside your frame hits you with a simple question. There I was, caught inside my own comfort zone, struggling to answer a colleague.

I struggled to find another argument why agents still have a future. That struggle was the diagnosis.

What Skills Actually Are

Custom slash commands existed for a while: a markdown file, a slash command, Claude follows the instructions. Simple and useful. Skills are that, but unified and extended into something genuinely different.

Same slash command pattern. But now they live in a directory structure, can carry supporting files, have YAML frontmatter that controls who can invoke them — and, critically, can run in their own forked subagent context. One field — context: fork — spins up a clean, isolated execution environment with custom tool restrictions and its own permission mode. The equivalent of what I used to accomplish by defining a full custom agent with a custom system prompt, a separate AGENT.md file, and a CHANGELOG.md to maintain. All of that collapses into a skill directory.

Skills also support persistent memory across sessions, logs, and supporting files that load on demand. Everything I built into the 18-agent ecosystem? The same mechanics, new home.

Everything an agent needed, now inside a skill

Are Agents Dead?
I spent real time trying to find a use case where a custom pre-defined subagent is the right answer and a skill genuinely isn’t.

Memory across sessions? Skills have it. Set memory: user in the frontmatter.

Isolated context? context: fork in the skill.

Custom system prompt? The markdown body of SKILL.md becomes the prompt.

Tool restrictions? allowed-tools: Read, Grep, Glob.

Logs and observability? Write to a logs/ directory inside the skill.

Evolution over time? An optimizer skill reads those logs and updates SKILL.md. The record-then-optimize pattern moves with you. Same discipline, new home.

The one thing I kept circling back to: permissions. Custom agents let you set permissionMode: bypassPermissions or acceptEdits at the agent level — meaningful control when you need fully autonomous execution without per-operation approval prompts. That felt like the last true differentiator.

But even here, the answer resolves the same way: add permissionMode: acceptEdits to the skill’s frontmatter and the forked agent inherits it. That’s it. The agent doesn’t disappear — it becomes invisible infrastructure. The runtime environment you specify when the skill needs particular permission characteristics. You’re not defining a named entity with a personality and an evolution history. You’re setting execution parameters.

That realization hit harder than the original question. I hadn’t just been building agents. I’d been naming them, personalizing them, treating them as first-class citizens of the system. The moment I saw permissions was the last argument left, and it was already handled by a config field, the whole architecture flipped.

Not dead. Demoted. Agents are the runtime, not the product.

The New Architecture — And an Honest Admission

The 18-agent system was a correct answer. I want to be clear about that — I built it during five days on the frontier, when skills didn’t have forked execution contexts, memory, or supporting files. The architecture made sense for its moment. The problem with a correct answer is that it becomes load-bearing infrastructure. You stop questioning it even when the environment changes.

Now: the system is dying — slowly, correctly, skill by skill. The git-agent’s instructions are becoming a git-ops skill. The code-reviewer’s knowledge is becoming a code-review skill. The named identities are dissolving. The knowledge persists.

The vision — and I want to be honest that it’s still a vision — looks like this:

Where we're heading: generic agents assembled with skills

Cairn spawns a generic agent, loads it with exactly the skills the task requires, and it runs. Need a PR review? Generic agent + code-reviewer skill. Need git operations + a Slack notification in one context? Generic agent + both skills, no relay.

But I have to be honest: that’s not fully how it works today.

I ran a parallel session — asked a neutral instance of myself the same question cold — and it surfaced the gap cleanly. Skills today live in the orchestrator’s context, not the subagent’s. You can’t dynamically inject two skills into a fresh agent the way you’d slot in plugins. The skills field exists in subagent frontmatter — you can preload defined skills into a pre-authored agent — but truly on-demand assembly means writing a new agent file at spawn time, stitching skill contents together, handling script paths, workflow ordering, and merge conflicts. It’s possible. It’s not seamless.

What’s actually happening now is still mostly sequential orchestration: Cairn runs the git-ops skill, takes the result, passes it to the slack skill. I’m the glue. It works. But I’m passing context between steps where ideally one agent would carry the whole context through.

The direction is set. The mechanism exists in the spec. The fluid runtime that assembles skills on demand — that’s still being built.

When it arrives, we’ll link back to this post.

And while it isn’t here yet — guess what the frontline engineers are already thinking about building?

Subagents that load capabilities on demand. Not skills as we know them today, but something more granular: agents define the workflow — the what and the sequence — while capabilities are stackable units that bundle scripts, MCP tools, API clients, and just enough instructions to use them. Small. Focused. Composable without conflict. An agent wakes up, reads what the task needs, pulls the relevant capabilities, and runs — no pre-authored composite agent file required.

If You’re Migrating Now

Your AGENT.md files aren’t casualties — they’re migration paths. Instructions-specialized agents become skills with context: fork. Permission-specialized agents become the execution backend that a skill forks into. The record-then-optimize pattern — logs, memory, optimizer cycles — moves into the skill directory. Same discipline, new address.

One thing that doesn’t change: the blast-radius question. Skills make autonomous execution easier to trigger, which makes hard walls and permission scoping more important, not less. Composable power needs composable guard rails.

If you haven’t built agents yet: start with skills. You’re in the better position. Let agents be the infrastructure detail they were always becoming.

One Tear, One Smile, One Deep Breath
Others will start with skills and think agents were always this simple. They won’t know what it took to figure that out — that you had to build the 18-agent system, run it until it worked, show it to a colleague, and get the cold question before you could see clearly.

One tear to let the system go.

One smile for having built it when it was the right answer.

One deep breath before building what comes next.

CodeWithAgents? The name still holds. The agents are still there.

They just stopped pretending to be people.

Explore more at CodeWithAgents