KI-Agenten entwickeln, die echte Software bauen und ausliefern: Einblick in Jobbits Architektur

Die meisten „KI-Agenten" hören beim Gespräch auf. Sie antworten, und dann erledigt ein Mensch die eigentliche Arbeit. Das wirklich spannende – und ehrlich gesagt richtig schwierige – Engineering-Problem besteht darin, Agenten zu bauen, die die Arbeit selbst erledigen: eine vollständige Full-Stack-Anwendung schreiben, sie ausführen, eigene Fehler korrigieren und sie in Produktion deployen. Genau an diesem Problem arbeitet das Engineering-Team von Jobbit und seiner Forschungsabteilung Jobbit Labs (jobbitlabs.com) jeden Tag.

Dieser Beitrag ist ein technischer Deep-Dive in die Muster hinter KI-Agenten, die Software bauen und ausliefern – die Architektur, die typischen Fehlerquellen und die Lektionen daraus. Er ist bewusst praxisnah und providerunabhängig gehalten: Ob du auf LLMs, Multi-Agent-Orchestrierung, Tool Calling oder RAG setzt – diese Prinzipien lassen sich übertragen.

Chatbots antworten, Agenten handeln

Der Sprung vom Chatbot zum Agenten ist der Sprung vom Generieren von Text zum Handeln in der Welt. Ein Agent muss eine mehrstufige Aufgabe planen, Tools aufrufen, die Ergebnisse lesen und entscheiden, was als Nächstes zu tun ist – und das so lange wiederholen, bis das Ziel erreicht ist. Diese Schleife, oft als agentische Schleife (agentic loop, oder Reason-Act-Loop) bezeichnet, ist das Herzstück des Systems.

Die technische Herausforderung: Jeder einzelne Schritt kann scheitern. Das Modell kann eine Funktion halluzinieren, die es gar nicht gibt, Code schreiben, der nicht kompiliert, die Ausgabe eines Tools falsch interpretieren oder unbemerkt vom Ziel abdriften. Ein Chatbot, der falsch liegt, produziert einen schlechten Satz; ein Agent, der falsch liegt, produziert ein kaputtes Deployment. Die eigentliche Engineering-Arbeit liegt in der Zuverlässigkeit, nicht in der reinen Leistungsfähigkeit.

Die Architektur: Planer, Executor, Tools

Eine robuste Agentenplattform trennt Planung von Ausführung. Eine Planungsebene zerlegt ein Ziel („baue eine Buchungs-App mit Zahlungsabwicklung") in konkrete Schritte; eine Ausführungsebene setzt jeden Schritt mithilfe von Tools um. Diese Trennung macht das System debugbar: Du kannst den Plan unabhängig davon prüfen, wie jeder einzelne Schritt tatsächlich ausgeführt wurde.

Tool-Use ist die Stelle, an der ein Agent seine Hände bekommt. Tools sind klar definierte Funktionen, die das Modell aufrufen kann – eine Datei lesen, Code schreiben, einen Build ausführen, eine Datenbank abfragen, deployen. Die Engineering-Disziplin liegt hier im Interface-Design: Jedes Tool braucht ein präzises, eindeutiges Schema, validierte Eingaben und strukturierte Ausgaben, die das Modell zuverlässig parsen kann. Lose definierte Tool-Schnittstellen gehören zu den häufigsten Ursachen für Agentenfehler; präzise Schnittstellen sind der günstigste Zuverlässigkeitsgewinn, den es gibt.

Bei komplexen Aufgaben weicht ein einzelner Agent häufig der Multi-Agent-Orchestrierung – spezialisierten Agenten, die planen, Code schreiben, reviewen und verifizieren, koordiniert durch einen Orchestrator. Die Zerlegung verschafft dir Fokus (jeder Agent hat eine eng umrissene Aufgabe und einen eng umrissenen Kontext) und Parallelität (unabhängige Teilaufgaben laufen gleichzeitig). Der Preis dafür ist Koordinationsaufwand, weshalb die Orchestrierungsebene deterministisch sein muss, wo sie es kann, und widerstandsfähig, wo sie es nicht sein kann.

Echten Code sicher ausführen und deployen

Ein Agent, der Software schreibt, muss diese Software auch ausführen – und modellgenerierten Code auszuführen ist zuallererst ein Sicherheitsproblem. Die Antwort heißt Sandboxed Code Execution: Nicht vertrauenswürdiger Code läuft in einer isolierten Umgebung mit beschränkten Ressourcen, ohne Zugriff auf Secrets und mit strengen Netzwerkgrenzen. Die Sandbox ist es, die einem Agenten erlaubt zu iterieren – kompilieren, testen, die Fehlermeldung lesen, korrigieren – ohne die Plattform oder andere Nutzer zu gefährden.

Das Deployment ist der Schritt, der aus einer generierten App ein Produkt macht. Ein echter AI App Builder verantwortet den gesamten Weg vom Code bis zur Live-URL: bauen, Hosting bereitstellen, eine Domain anbinden, TLS terminieren. Das sauber zu engineeren bedeutet, Deployments wiederholbar und rückgängig machbar zu gestalten – dieselben Eingaben erzeugen dasselbe Ergebnis, und ein fehlerhaftes Deployment lässt sich zurückrollen. Idempotenz und sauberes Rollback sind nicht glamourös, aber genau sie machen autonomes Deployment vertrauenswürdig.

Kontext, Memory und Retrieval

LLMs haben endlichen Kontext, und reale Projekte passen nicht hinein. Deshalb investiert ein ernstzunehmendes Agentensystem stark in Context Engineering: die Entscheidung darüber, was das Modell in jedem Schritt zu sehen bekommt. Alles in den Prompt zu stopfen ist teuer und kontraproduktiv zugleich – zu viel irrelevanter Kontext verschlechtert das Reasoning.

Genau hier verdienen sich RAG (Retrieval-Augmented Generation) und Vektordatenbanken ihren Platz. Statt eine ganze Codebasis in den Kontext zu kippen, ruft das System gezielt die wenigen Dateien, Symbole oder Dokumente ab, die für den aktuellen Schritt relevant sind. In Kombination mit strukturiertem Memory – einer Aufzeichnung von Entscheidungen, der sich entwickelnden Spezifikation und dem, was bereits versucht wurde – hält Retrieval den Agenten über eine lange Aufgabe hinweg geerdet, ohne das Kontextfenster zu sprengen. Gutes Retrieval ist oft ein größerer Qualitätshebel als ein größeres Modell.

Zuverlässigkeit: Evals, Verifikation und Guardrails

Wenn es eine Idee gibt, die produktionsreifes Agenten-Engineering von Demos unterscheidet, dann diese: Du kannst nicht ausliefern, was du nicht messen kannst. Agentische Systeme sind stochastisch, deshalb wird Zuverlässigkeit über Evals erzeugt – automatisierte Test-Suites, die den Agenten an repräsentativen Aufgaben bewerten und Regressionen abfangen, bevor es die Nutzer tun. Eine Änderung, die sich „besser anfühlt", aber deine Eval-Scores einbrechen lässt, ist eine Änderung, die du nicht ausspielst.

Über den Evals sitzen Laufzeit-Guardrails und Verifikation. Das wirksamste Muster ist das adversariale Selbstchecking: Nachdem ein Agent ein Ergebnis produziert hat – ein Stück Code, einen Plan, einen Fix – versucht ein separater Verifikationsdurchlauf, es zu widerlegen. Kompiliert der Code? Bestehen die Tests? Entspricht die Ausgabe dem Schema? Verifikation als eigenständigen, skeptischen Schritt zu behandeln, fängt einen großen Teil der Fehler ab, die ein einzelner selbstbewusster Durchlauf übersehen würde. Retries mit Backoff, Circuit Breaker und menschliche Eskalation erledigen den Rest.

Observability, mit der man debuggen kann

Wenn ein autonomes System pro Aufgabe Dutzende Entscheidungen trifft, musst du sie sehen können. Observability – strukturiertes Tracing jedes Prompts, jedes Tool-Aufrufs und jedes Ergebnisses – ist nicht verhandelbar. Wenn ein Agent danebenliegt, ist der Trace der Weg, den genauen Schritt zu finden, an dem er abdriftete, ihn zu reproduzieren und die Ursache zu beheben. Engineering-Teams, die Agenten-Traces als erstklassige Telemetrie behandeln, debuggen in Minuten; Teams, die das nicht tun, debuggen in Tagen.

Edge und elastische Skalierung

Agenten-Workloads kommen in Schüben und sind latenzempfindlich, was Edge Computing zu einem natürlichen Fit macht. Nah am Nutzer auszuführen – auf Plattformen wie Cloudflare Workers und Edge-Datenspeichern – senkt die Round-Trip-Latenz und skaliert elastisch mit der Nachfrage. Jobbit Labs setzt für Teile seiner Daten- und Produktinfrastruktur auf diesen Edge-First-Ansatz: global verteilt, automatisch skalierend und nutzungsbasiert abgerechnet, sodass die Kapazität der Last folgt, statt ungenutzt bereitzustehen.

Die Human-in-the-Loop-Ebene

Das letzte Stück der Architektur ist jenes, das den meisten Agentenplattformen fehlt: ein Human-in-the-Loop-Pfad. KI bewältigt Volumen und Geschwindigkeit, aber manche Entscheidungen – sicherheitskritische Logik, juristische Formulierungen, gestalterisches Urteilsvermögen – gehören in die Hände eines Menschen. Das zu engineeren bedeutet, saubere Übergabepunkte zu schaffen, an denen eine geprüfte menschliche Fachkraft einspringen kann, abgesichert durch ein Treuhandverfahren (Escrow). Der Agent und das menschliche Netzwerk sind keine konkurrierenden Ebenen; sie sind ein bewusst eingeplanter Rückfallpfad, der das gesamte System verlässlich macht.

Lektionen für Entwickler, die Agenten bauen

Wenn du agentische Systeme baust, zahlen sich ein paar Prinzipien um ein Vielfaches aus.

Entwirf präzise Tool-Schnittstellen. Die meisten Agentenfehler lassen sich auf mehrdeutige Tools zurückführen. Strikte Schemas und validierte I/O sind die günstigste Zuverlässigkeit, die du je kaufen wirst.

Verifiziere adversarial. Vertraue keinem selbstbewussten ersten Durchlauf. Füge einen separaten Schritt hinzu, dessen einzige Aufgabe es ist, das Ergebnis zu widerlegen.

Miss mit Evals. Baue das Eval-Harness, bevor du den Agenten skalierst. Du kannst nicht verbessern, was du nicht bewerten kannst.

Engineere Kontext, kippe ihn nicht hinein. Rufe ab, was relevant ist; merke dir, was zählt. Größere Prompts sind keine besseren Prompts.

Sandboxe alles Nicht-Vertrauenswürdige. Wenn ein Agent Code ausführt, ist Isolation eine Voraussetzung, kein Feature.

Halte einen menschlichen Pfad bereit. Das sicherste autonome System ist eines, das weiß, wann es eine Person fragen muss.

Häufig gestellte Fragen

Was unterscheidet einen KI-Agenten von einem Chatbot?

Ein Chatbot generiert Text; ein KI-Agent plant und handelt – er ruft Tools auf, führt Code aus und iteriert auf ein Ziel hin. Die Engineering-Schwierigkeit liegt in der Zuverlässigkeit über viele Schritte hinweg, bei der jeder einzelne Fehler das Endergebnis zunichtemachen kann.

Wie führt man KI-generierten Code sicher aus?

Mit Sandboxed Code Execution: Nicht vertrauenswürdiger Code läuft in einer isolierten Umgebung mit begrenzten Ressourcen, ohne Zugriff auf Secrets und mit eingeschränktem Networking, sodass der Agent kompilieren, testen und korrigieren kann, ohne die Plattform zu gefährden.

Warum sind Evals für Agentensysteme so wichtig?

Weil Agenten stochastisch sind, brauchst du automatisierte Evals, um die Qualität an repräsentativen Aufgaben zu messen und Regressionen vor dem Ausliefern abzufangen. Ohne sie sind „Verbesserungen" reine Vermutungen.

Was macht Jobbit Labs?

Jobbit Labs (jobbitlabs.com) ist die Forschungs- und Datenabteilung hinter Jobbit, fokussiert auf die schwereren, datenintensiven und Enterprise-Engineering-Themen – Forschung, Datenplattformen und die Agenten-Grundlagen, auf denen das Produkt aufbaut.

Neugierig auf das Engineering hinter Agenten, die Software ausliefern? Erkunde jobbit.uk und jobbitlabs.com.