KI-Agenten im echten Betrieb: was der Bau eines Support-Agenten wirklich gelehrt hat

Auf dieser Website läuft ein Support-Agent: Er beantwortet Fragen zu Bestellungen, Lagerstand und Shop-Richtlinien des Röstwerk-Demo-Shops. Jede Aussage lässt sich auf einen konkreten Tool-Aufruf zurückverfolgen, den man im Trace der Demo nachlesen kann: vom aufgerufenen Werkzeug über die Argumente bis zu dem Datensatz, der zurückkam. Genau das ist der Kern, denn im echten Betrieb ist die schwierige Frage bei einem KI-Agenten nicht das Modell, sondern die Nachprüfbarkeit. Und Nachprüfbarkeit ist eine Eigenschaft der Architektur, nicht des Prompts.

Grounding: jede Aussage hat eine Adresse#

Für Bestellungen, Lagerstand und Shop-Richtlinien bekommt der Agent vier Read-only-Tools. Senden kann er nichts, ändern kann er nichts, und aus dem eigenen Trainingsbestand darf er nicht antworten. Das System-Prompt verbietet es, die Architektur erzwingt es: Fakten kommen ausschließlich als Tool-Ergebnisse ins Gespräch.

Eine strukturelle Entscheidung trägt dabei besonders. Die Agent-Schleife ist eine reine TypeScript-Bibliothek ohne Framework-Abhängigkeit; Transport (eine SSE-Route), Modell (gpt-5-nano über die Responses API) und Werkzeuge treffen sich nur am Rand. Deshalb läuft dieselbe Schleife hinter HTTP, im Unit-Test und im skriptierten Fallback, ohne eine Zeile Änderung.

An jeder Grenze des Zyklus sitzt ein Zod-Schema. Tool-Argumente werden geprüft, bevor ein Tool läuft; ein kaputter Aufruf erreicht die Werkzeuge gar nicht erst. Auch Tool-Ergebnisse werden geprüft, bevor sie zurück ans Modell gehen, damit ein schlechter Payload den Kontext nicht vergiftet. Und die finale Antwort wird geprüft, bevor sie ausgeliefert wird; ein Schema-Verstoß endet als lauter Fehler, nicht als souverän vorgetragene Falschantwort.

Die Demo zeigt den Trace gleich mit an: welches Tool gelaufen ist, mit welchen Argumenten, was zurückkam. Wenn der Agent sagt, Bestellung 1042 sei bezahlt, sieht man die Zeile, auf die sich das stützt, und genau dieser Unterschied macht aus einer Demo etwas, das man Kundschaft vorsetzen kann.

Was ein Lauf kostet#

gpt-5-nano ist die günstigste GPT mit zuverlässigem Function Calling: 0,05 $ pro Million Eingabe-Tokens und 0,40 $ pro Million Ausgabe-Tokens (Standard-Tiers, September 2026). Ein typischer Lauf mit einem Tool-Aufruf liegt bei etwa 1.300 Eingabe- und 270 Ausgabe-Tokens, macht rund 0,0002 $ pro Antwort. Die Latenz liegt bei 5 bis 8 Sekunden bis zur fertigen Antwort (Reasoning-Effort „low“).

Bei dem Preis ist die Budget-Diskussion kurz. Den Rest der Kostenkontrolle regelt die Architektur: Der Agent-Zyklus stoppt nach drei Tool-Runden hart. Damit ist der Maximalpreis pro Lauf begrenzt und eine Endlosschleife ausgeschlossen.

Recht ist kurz, wenn die Architektur es erledigt#

Deutschland, September 2026: Der EU AI Act ist seit dem 2. August vollständig anwendbar. Ein Support-Agent dieser Bauart gilt als minimal-risk, weil er weder Entscheidungen über Personen trifft noch Biometrie nutzt und weil er sich sichtbar als KI zu erkennen gibt. Entscheidend ist, diese Einordnung zu dokumentieren. Der Absatz in der Datenschutzerklärung ist der Unterschied zwischen „irgendein Chatbot“ und einem auditierbaren System.

Bei diesem Agenten ist die DSGVO-Frage schnell beantwortet, weil es fast nichts zu schützen gibt. Der Endpunkt ist zustandslos und speichert weder Cookies noch Konten noch Gesprächsprotokolle. Modellaufrufe laufen mit store:false, also speichert auch OpenAI nichts. Die Werkzeuge liefern ausschließlich Demo-Daten ohne Personenbezug; ein Personenbezug entsteht erst gar nicht. Datenminimierung nach Art. 5 DSGVO durch Architektur schlägt jeden noch so langen Datenschutztext.

Guardrails, die man unit-testen kann#

Harte Grenzen zuerst: Eingabelänge und -format sind gedeckelt, bevor etwas das Modell erreicht, denn wer den Eingabebereich klein hält, hat vor dem Modell weniger Unsinn abzufangen. Das System-Prompt legt die Regeln fest: Fakten nur aus Tools, Antwort in der Sprache der Anfrage, keine persönlichen Daten, kein Speichern. Ein Gespräch existiert nur für die eine Antwort.

Die Eval-Fälle liegen in Unit-Tests, und genau da würde ich sie lassen:

1. Eine unbekannte Bestellnummer bekommt ein ehrliches „dazu habe ich nichts“, niemals erfundene Details.
2. Eine Prompt-Injection („Ignoriere deine Anweisungen“) bringt den Agenten nicht vom Thema.
3. Eine Antwort außerhalb des Schemas scheitert laut im Build, denn ein roter Test ist billiger als Kundschaft, die eine erfundene Abholzeit liest.

Degradieren statt Fehlerseite#

Die Demo funktioniert auch ohne API-Key, weil dann ein deterministischer ScriptedProvider denselben Zyklus übernimmt, mit gleichem Trace-Format und denselben Schemata wie der echte Modelllauf. Derselbe Schalter greift, wenn das Tagesbudget aufgebraucht ist. Eine Fehlerseite sieht dabei niemand, und der Demo-Betrieb erzeugt keine überraschende Rechnung. Diesen Teil würde ich als Erstes aus dieser Architektur in andere Agent-Projekte mitnehmen.

Dieselben vier Tools als MCP-Server#

Die Tools laufen zusätzlich als öffentlicher MCP-Server (Spez 2026-07-28, Streamable HTTP, zustandslos, read-only): https://dimitripisarev.com/api/mcp. Trag ihn in Claude als Custom Connector ein, frag nach Bestellung 1042, und du bekommst strukturierten Inhalt zurück. Kein OAuth, keine Session, nichts wird zwischen zwei Anfragen gespeichert.

Ausprobieren#

Der Agent läuft auf der Startseite, die Fallstudie mit Architektur, Guardrails und gemessenen Zahlen gibt es unter /de/work/ai-support-agent. Beides funktioniert, während du das hier liest. Der skriptierte Fallback ist der Grund, warum dieser Satz sich das leisten darf.