Agenten in ChatGPT bauen - wozu dann eine Plattform?

Die kurze Antwort

Ja, du kannst dir einen Agenten in ChatGPT zusammenklicken. Du kannst ihm eine Anweisung geben, Dateien danebenlegen, ein paar Aktionen anschließen und ihn benutzen. Das ist kein Kompromiss und kein Anfängerpfad - für eine ganze Klasse von Aufgaben ist es die richtige Lösung, und wer damit in einer Stunde fertig ist, hat nichts falsch gemacht.

Der Satz hat nur ein Ende: bis es ernst wird. Ernst heißt hier nicht „groß“, sondern etwas sehr Konkretes - der Agent soll dasselbe morgen wieder tun, er soll es tun, während niemand zusieht, und wenn er es nicht tut, soll es jemand merken. Genau an dieser Stelle hört Zusammenklicken auf zu tragen, und zwar nicht, weil das Werkzeug schlecht wäre, sondern weil die Fragen, die dann auftauchen, gar nicht mehr im Werkzeug beantwortet werden.

Diese Seite ist der Versuch, das nicht zu behaupten, sondern zu zeigen. Vier Fälle, die jeder kennt, der einen zusammengeklickten Agenten länger als eine Woche benutzt hat - und zu jedem die Stelle, an der auf dieser Plattform steht, was dahinter fehlt.

Was daran wirklich gut ist

Zuerst das Zugeständnis, und es ist ernst gemeint.

Ein Custom GPT nimmt dir die gesamte Mechanik ab, die im LLM-Call und in der Message-History steckt: Aufruf, Protokoll, Kontextaufbau, Werkzeugausführung. Du schreibst eine Anweisung - fachlich gesehen ein System Prompt - und bekommst dafür einen laufenden Agenten. Das ist ein enormer Hebel, und dieselbe Rechnung gilt für einen fertigen Agenten, den du dir hinstellst statt ihn zu bauen. Wir haben selbst einen: Hermes ist der Referenz-Agent, an dem hier vieles gezeigt wird.

Der Preis dafür ist auch keine Überraschung: Du bekommst nicht nur die Mechanik geschenkt, du bekommst sie auch versteckt. Solange alles läuft, ist das ein Vorteil. Es hört in dem Moment auf, einer zu sein, in dem etwas nicht läuft - denn dann brauchst du eine Vorstellung davon, wo du nachsehen müsstest, und die kommt nicht mit.

Fall 1: Der Agent vergisst mitten im Lauf, was er tun sollte

Das Muster ist immer dasselbe. Am Anfang hält sich der Agent an seine Anweisung, nach zwanzig Minuten Arbeit fällt er in einen Plauderton zurück, ignoriert Formatvorgaben und beantwortet die letzte Nachricht statt der Aufgabe. Kein Fehler, keine Meldung - er ist einfach woanders.

Der Grund ist keine Laune, sondern Arithmetik. Das Modell hat kein Gedächtnis; was nach Erinnerung aussieht, ist die Message-History, die der Harness bei jedem Aufruf komplett mitschickt. Diese Liste wächst mit jeder Werkzeugausgabe, jedem angehängten Dokument, jeder Zwischenantwort - das Kontextfenster wächst nicht mit. Irgendwann steht die eigentliche Anweisung so weit hinten, dass sie gegen zwanzig Seiten frisches Material konkurriert. Was du siehst, ist genau das.

Was fehlt, heißt Context-Management: entscheiden, was in jedem Aufruf mitfährt und was nicht. Zusammenfassen statt anhängen, auswählen statt alles mitschleppen, die Anweisung nachschieben statt hoffen. In einer zusammengeklickten Oberfläche gibt es dafür keinen Schalter, weil es keine Einstellung ist, sondern eine Entwurfsentscheidung. Sie steht bei Message-History und - sobald es um Wissen geht, das über den einzelnen Lauf hinaus gilt - bei Memory.

Fall 2: Ein Werkzeugaufruf scheitert, und der Agent macht munter weiter

Der zweite Fall ist der teuerste, weil er nicht wie ein Fehler aussieht. Die Kalenderabfrage läuft in einen Timeout, der Agent bekommt eine leere Antwort - und schreibt: „Für morgen ist nichts eingetragen.“ Er lügt nicht; ihm wurde nie beigebracht, dass leer und nichts zwei verschiedene Dinge sind. Das Ergebnis ist eine plausible, sachlich falsche Aussage am Anfang einer Kette, und alles danach baut darauf auf.

Der Ort, an dem das entschieden wird, ist nicht das Modell, sondern der Harness. Das Modell schlägt einen Aufruf nur vor - ausgeführt wird er vom Code drumherum, und dieser Code entscheidet auch, was im Fehlerfall zurückgeht: eine verwertbare Meldung, ein Abbruch, ein zweiter Versuch mit anderen Parametern. Bekommt der Agent den Fehler nie zu sehen, kann er ihn auch nicht umgehen.

Im Betrieb wird daraus ein Mengenproblem: Ein einzelner Werkzeugaufruf gelingt fast immer, zwanzig hintereinander fast nie, weil sich die Quoten multiplizieren. 95 Prozent je Schritt sind nach zwanzig Schritten 36 Prozent. Was man dagegen baut - Wiederholungen, Zwischenprüfungen, Werkzeuge, die im Fehlerfall etwas Brauchbares zurückgeben -, steht bei Tool-Calling im Betrieb. Und alles, was der Agent gar nicht erst tun darf, gehört zu den Guardrails.

Fall 3: Derselbe Prompt liefert heute etwas anderes als gestern

Du änderst eine Zeile in der Anweisung, weil ein Fall nicht gut lief. Danach läuft dieser Fall besser. Ob die anderen sieben immer noch funktionieren, weißt du nicht - du hast sie nicht angesehen. Zwei Wochen später wird im Hintergrund ein Modell aktualisiert, und dieselbe Anweisung verhält sich anders. Gemerkt hat es niemand, weil es nichts gibt, das es merken könnte.

Das ist der Unterschied zwischen Ausprobieren und Messen. Ein Agent, dessen Verhalten sich nicht reproduzieren lässt, ist kein zuverlässiger Agent, sondern ein Glücksspiel mit guter Trefferquote. Reproduzierbarkeit fängt beim LLM-Call an - Temperatur, Stoppwörter, Modellversion sind Einstellungen, keine Naturkonstanten - und endet bei einem festen Satz von Testfällen, den du nach jeder Änderung durchlaufen lässt. Wie man Modelle und Aufbauten vergleicht, ohne sich selbst zu betrügen, steht bei Benchmarks; wie eine solche Messung praktisch aussieht, kannst du im Lab „Eingabeformat“ an einer einzelnen Variable durchspielen.

Fall 4: Es läuft mit drei Dokumenten und kippt bei dreihundert

Die Demo ist überzeugend: drei PDFs hochgeladen, Fragen dazu gestellt, alle Antworten sitzen. Mit dreihundert Dokumenten antwortet derselbe Agent langsamer, teurer und schlechter - er zitiert das falsche Papier, übersieht das richtige und wirkt plötzlich dümmer als vorher.

Bei drei Dokumenten passt schlicht alles gleichzeitig in den Kontext. Auswahl ist dann keine Aufgabe, sondern entfällt. Bei dreihundert ist Auswahl die einzige Aufgabe: Welche fünf Ausschnitte fahren bei dieser einen Frage mit? Das ist Memory - Suche, Auswahl, Einbettung in den Prompt -, und es ist der Punkt, an dem aus einem Upload ein System wird.

Dasselbe gilt für Werkzeuge statt Dokumente. Von zweihundert verfügbaren Fähigkeiten sieht das Modell nur die, die du ihm zeigst, und die Ausgaben der übrigen fluten seinen Kontext. Warum Auswahl hier die eigentliche Konstruktionsarbeit ist, steht bei Tiny Agents und der Kompressionsgrenze.

Der Unterschied in einem Satz

Zusammengeklickte Agenten sind gut darin, einmal zu funktionieren. Alles, was sie darüber hinaus tragen sollen - morgen wieder, ohne Aufsicht, nachweisbar, mit mehr Material als in der Demo -, hängt an Entscheidungen, die außerhalb des Werkzeugs getroffen werden: Was fährt im Kontext mit? Was passiert im Fehlerfall? Woran merken wir, dass es schlechter geworden ist? Was darf der Agent auf keinen Fall?

Das sind vier Fragen, keine vierzig. Sie haben Namen, sie haben bekannte Antworten, und sie sind genau der Stoff, der auf dieser Plattform in drei Blöcken steht: der Harness, alles, was daneben steht, und das, worauf es läuft.

Womit du anfängst

Nicht mit einem Framework, und auch nicht damit, deinen Custom GPT wegzuwerfen. Behalte ihn - er ist von jetzt an dein Vergleichsmaßstab.

Der günstigste erste Schritt ist, die Mechanik einmal selbst zu sehen: ein einziger LLM-Call, dann eine Message-History drumherum, dann ein Werkzeug und eine Schleife. Danach liest du jedes fertige Produkt als das, was es ist - eine Sammlung von Voreinstellungen zu genau den Fragen von oben.

Die Grundlagen jedes Bauteils sind frei lesbar, ohne Konto, und beginnen mit einer Viertelstunde. Wenn du weiter vorne einsteigen willst: Was ist ein KI-Agent? beantwortet die Frage davor - was ein Agent überhaupt ist und aus welchen Teilen er besteht. Nachbauen kannst du das alles in den Tutorials.