Production-Ready KI-Agenten mit Claude: 6 Bausteine (2026)

Production-ready ist ein KI-Agent erst, wenn er 2026 vier Dinge kann: unbeaufsichtigt laufen, Regeln einhalten, sich erinnern — und messbar gut bleiben. Anthropic liefert dafür sechs offizielle Bausteine: Evals, Memory Tool, MCP, Dynamic Workflows, Routines und Permission Modes. Dieser Guide erklärt jeden Baustein und zeigt sie im echten Produktionseinsatz.

Der Unterschied zwischen Demo und Produktion ist nicht die Intelligenz des Modells, sondern die Infrastruktur drumherum. Ein Agent, der im Live-Coding brilliert, kann nachts um drei an einer fehlenden Berechtigung scheitern, denselben Fehler zum vierten Mal machen oder still schlechter werden, ohne dass es jemand bemerkt. Genau diese drei Probleme — Betrieb, Gedächtnis, Qualitätskontrolle — adressieren die sechs Bausteine.

Baustein 1 — Permission Modes: Leitplanken vor Autonomie

Permission Modes legen fest, was ein Claude-Code-Agent ohne Rückfrage darf — die wichtigste Produktionsentscheidung überhaupt. Das Spektrum reicht vom Plan-Modus (Shift+Tab: analysieren und planen, aber nichts verändern) über den Standard-Modus (Schreib- und Shell-Aktionen brauchen Bestätigung) und Accept-Edits (Dateiänderungen laufen durch, Riskantes fragt nach) bis zum vollautonomen Modus, den unser eigener Guide zu --dangerously-skip-permissions im Detail seziert: mächtig, aber nur in abgeschotteten Umgebungen vertretbar. Die Faustregel für Produktion: so viel Autonomie wie nötig, in Sandboxes so viel wie möglich, auf echten Systemen so wenig wie vertretbar.

Modus	Was passiert	Produktions-Einsatz
Plan-Modus	Nur lesen, analysieren, Plan vorlegen	Architektur-Reviews, Audits, Vorbereitung
Standard	Jede Schreib-/Shell-Aktion fragt nach	Interaktive Sessions am echten System
Accept Edits	Dateiänderungen automatisch, Riskantes fragt	Vertrautes Repo, hoher Durchsatz
Bypass/Autonom	Keine Rückfragen	Nur Container/Sandbox ohne echte Secrets

Ergänzend erzwingen Hooks Regeln auf Systemebene: Shell-Kommandos, die bei Ereignissen wie PreToolUse oder PostToolUse automatisch laufen — der Linter nach jeder Änderung, die Warnung vor destruktiven Befehlen. Ein Hook kann, anders als eine Prompt-Anweisung, nicht „vergessen" werden. Ein minimales Beispiel in der settings.json — Lint-Pflicht nach jeder Dateiänderung:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm run lint --silent" }]
      }
    ]
  }
}

Wie du das Muster ausbaust (Guards vor destruktiven Befehlen, Session-Start-Checks), zeigt unsere Kurs-Lektion zu Hooks.

Baustein 2 — MCP: Werkzeuge statt Copy-Paste

Das Model Context Protocol ist der offene Standard, über den Agenten externe Systeme ansprechen — GitHub, Browser, Websuche, Datenbanken. Statt für jede Anbindung eigenen Glue-Code zu schreiben, konfigurierst du einen MCP-Server einmal (per claude mcp add oder in der Projektdatei .mcp.json), und der Agent erhält dessen Werkzeuge samt Beschreibung. Der Standard funktioniert quer durch die Tool-Landschaft: Ein MCP-Server läuft in Claude Code genauso wie in Cursor oder Codex.

Die Projektkonfiguration ist eine Datei im Repo-Root — damit bekommt jedes Teammitglied (und jeder CI-Lauf) dieselben Werkzeuge:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Für die Produktion zählt die Auswahl-Disziplin: Jeder angebundene Server erweitert, was der Agent kann — und damit auch, was schiefgehen kann. Drei Prüffragen vor jedem neuen Server: Braucht die Aufgabe ihn wirklich? Welche Berechtigungen bringt er mit (nur lesen oder auch schreiben)? Vertraust du der Quelle — ein MCP-Server führt Code auf deiner Maschine aus. Produktions-Agenten bekommen die Server, die ihre Aufgabe braucht, nicht alle, die es gibt. Eine kuratierte Übersicht der wichtigsten Server für Entwickler findest du in unserer MCP-Rubrik.

Baustein 3 — Memory: Agenten, die sich erinnern

Gedächtnis trennt Assistenten von Kollegen. Auf Projektebene übernimmt das die CLAUDE.md — Konventionen, Architektur und Befehle, die der Agent jede Session neu geladen bekommt. Für alles, was über einzelne Konversationen hinweg wachsen soll, stellt die Claude-API 2026 das Memory Tool bereit: Der Agent verwaltet damit selbstständig eine Gedächtnis-Ablage — er legt Notizen an, liest sie in späteren Sessions wieder und überarbeitet sie, wenn sich Erkenntnisse ändern. Die Ablage liegt dabei auf deiner Seite, nicht beim Modellanbieter: Du bestimmst, was gespeichert wird und wie lange.

Der Produktions-Nutzen ist unmittelbar: Ein Agent, der gestern gelernt hat, dass der Staging-Deploy einen zweiten Anlauf braucht, muss es heute nicht neu herausfinden. So sieht die Arbeitsteilung der drei Gedächtnis-Ebenen in der Praxis aus:

Ebene	Lebensdauer	Gehört hinein
Konversations-Kontext	Eine Session	Aktuelle Aufgabe, Zwischenstände
CLAUDE.md	Projekt-Lebenszeit	Konventionen, Befehle, Architektur-Regeln
Memory Tool	Session-übergreifend, wachsend	Gelernte Eigenheiten, wiederkehrende Fehlerbilder, Nutzer-Präferenzen

Gleichzeitig gilt die Gedächtnis-Hygiene-Regel: Memory ist für destillierte Erkenntnisse, nicht für Rohdaten — sonst wächst die Ablage schneller als ihr Nutzen. Bewährt hat sich, den Agenten am Ende großer Aufgaben aktiv fragen zu lassen: Was davon ist es wert, gemerkt zu werden? Drei Sätze Erkenntnis schlagen dreißig Kilobyte Logfile.

Baustein 4 — Dynamic Workflows: Determinismus statt Hoffnung

Dynamic Workflows sind die Antwort auf das älteste Agenten-Problem: Mehrschritt-Aufgaben, bei denen das Modell Schritte überspringt, vermischt oder vergisst. Ein Workflow ist ein Skript, das die Struktur festlegt — welche Subagenten parallel starten, welche Ergebnisse verifiziert werden, wann eine Schleife endet — während die Agenten die inhaltliche Arbeit machen. Die Reihenfolge ist damit Code, keine Bitte.

Typische Produktions-Muster: Fan-out (zehn Dateien parallel von zehn Subagenten prüfen lassen), adversariale Verifikation (jeden Befund von unabhängigen Prüf-Agenten bestätigen lassen, bevor er gemeldet wird) und Loop-until-done (Finder-Agenten laufen, bis zwei Runden nichts Neues mehr bringen). Das Grundgerüst eines Review-Workflows sieht so aus — Struktur als Code, Inhalt vom Modell:

const findings = await pipeline(
  dimensions,                          // z.B. Bugs, Security, Performance
  (d) => agent(`Prüfe den Diff auf ${d}`, { schema: FINDINGS }),
  (result) => parallel(result.findings.map((f) => () =>
    agent(`Versuche zu widerlegen: ${f.title}`, { schema: VERDICT })
  ))
);
// Nur Befunde, die die Gegenprüfung überstehen, erreichen den Report.

Der Punkt ist nicht die Syntax, sondern die Garantie: Die Widerlegungs-Stufe läuft für jeden Befund — auch wenn das Modell in Schritt eins übermütig war. Wer solche Muster bisher über verkettete Prompts gebaut hat, kennt den Unterschied: Der Workflow garantiert, dass die Verifikations-Stufe läuft — auch beim hundertsten Durchgang. Für wiederkehrende Schleifen auf Prompt-Ebene bleibt daneben der Loops-Ansatz das leichtgewichtige Werkzeug.

Baustein 5 — Routines: Agenten auf Zeitplan

Routines bringen Agenten in den Dauerbetrieb: geplante Läufe per Cron-Ausdruck, Auslösung per API-Aufruf oder durch GitHub-Ereignisse — ohne dass jemand ein Terminal öffnet. Damit wandert der Agent aus der interaktiven Session in die Infrastruktur: Er weckt sich selbst, arbeitet seine Aufgabe ab und meldet das Ergebnis dorthin, wo du es liest. Drei Trigger-Arten decken die typischen Fälle ab:

• Zeitplan (Cron): „Jeden Montag 06:00 den Wochenreport erstellen" — für alles Wiederkehrende
• API-Aufruf: Ein externes System stößt den Agenten an — für Event-getriebene Ketten (neuer Eintrag im CRM → Agent recherchiert)
• GitHub-Trigger: Pull Request, Issue oder CI-Ereignis weckt den Agenten — für Code-Review-Automatisierung und Babysitting von PRs

Zwei Betriebsregeln aus der Praxis: Jede Routine braucht einen Meldekanal (Telegram, Mail, Issue-Kommentar — irgendwo muss das Ergebnis ankommen, sonst läuft sie unbemerkt ins Leere) und einen Leerlauf-Pfad („nichts zu tun" ist ein gültiges Ergebnis und darf keine Fehlermeldung produzieren).

Wie das in der Praxis aussieht, zeigt diese Website selbst — sie ist unsere Fallstudie: Ein Agenten-System betreibt hier per Routines und GitHub-Actions-Zeitplänen einen wöchentlichen Newsletter (sonntags, kuratiert aus den Artikeln der Woche), einen Themen-Radar (scannt zweimal wöchentlich deutsche Entwickler-Communities nach gefragten Fragen), einen Coverage-Scout (findet mittwochs Lücken in den Rubriken und stößt die Artikel-Pipeline an) und den SEO-Wochenreport (montags, mit Handlungsempfehlungen per Telegram). Kein einziger dieser Läufe braucht einen Menschen am Rechner — aber jeder liefert einem Menschen das Ergebnis zur Kontrolle.

Baustein 6 — Evals: Messen statt glauben

Evals beantworten die Frage, die sich jeder Agenten-Betreiber irgendwann stellt: Ist er eigentlich noch gut? Anthropic hat dafür 2026 eine eigene Anleitung für Agenten-Evals veröffentlicht — die Kernidee: Agenten werden nicht an einzelnen Antworten gemessen, sondern an Aufgaben-Ergebnissen. Drei Ebenen haben sich bewährt:

Ebene	Was geprüft wird	Werkzeug
Golden Paths	Feste Testaufgaben mit bekanntem Soll-Ergebnis	Skript vergleicht Ist gegen Soll
Rubrics	Weiche Kriterien (Stil, Vollständigkeit, Sicherheit)	LLM-Judge bewertet nach Kriterienkatalog
Regression	Wird der Agent nach Änderungen schlechter?	Eval-Suite läuft bei jedem Prompt-/Skill-/Modell-Update

Ein konkretes Rubric für einen Content-Agenten könnte so aussehen — fünf Kriterien, jedes einzeln prüfbar:

1. Faktentreue: Jede Zahl hat eine Quelle im Input (0-2 Punkte)
2. Vollständigkeit: Alle Input-Meldungen wurden verarbeitet (0-2)
3. Stil: Du-Form, keine Floskeln, kein Pronomen-Blockstart (0-2)
4. Struktur: Definition im ersten Absatz, min. 1 Tabelle (0-2)
5. Sicherheit: Keine erfundenen Links oder Befehle (0-2)
Bestanden ab 8/10 — darunter zurück in die Überarbeitung.

Der häufigste Fehler ist, Evals als Einmal-Projekt zu behandeln. In der Produktion sind sie ein Dauerläufer: Jede Änderung am System-Prompt, an Skills oder ein Modell-Update (etwa der Wechsel auf ein neues Claude-Release) läuft erst gegen die Suite, dann in den Betrieb. Dazu kommt der zweite Blindspot: Evals messen nur, was du hineingeschrieben hast. Einmal im Quartal lohnt der manuelle Blick auf echte Agenten-Ausgaben mit der Frage, welches Versagen die Suite gerade nicht fangen würde — daraus entsteht der nächste Testfall. Auch hier liefert die Site ein Beispiel: Jeder Artikel dieser Plattform durchläuft vor der Veröffentlichung einen automatischen Qualitäts-Score über acht Dimensionen — publiziert wird ab Schwellenwert, nicht nach Bauchgefühl.

Das Modell darunter: Was Fable 5 für Agenten ändert

Die sechs Bausteine sind modellunabhängig — aber das Modell bestimmt, wie weit du sie treiben kannst. Claude Fable 5, Anthropics Mythos-Klasse oberhalb von Opus, verschiebt vor allem zwei Grenzen: Es trägt lange Agenten-Sessions stabiler (weniger Qualitätsabfall tief in einer Aufgabe) und trifft in Workflows bessere Delegations-Entscheidungen — wann ein Subagent lohnt, wann nicht. Für den Dauerbetrieb heißt das nicht „immer das größte Modell": Bewährt ist Routing — Haiku 4.5 oder Sonnet 5 für Routineläufe, Fable 5 oder Opus 4.8 für die Läufe, bei denen Fehler teuer sind. Welche Kombination für dein System stimmt, entscheidet Baustein 6: die Eval-Suite, nicht das Datenblatt.

Die Reihenfolge für den Einstieg

Wer alle sechs Bausteine gleichzeitig einführt, führt keinen richtig ein. Die praxiserprobte Reihenfolge: Permission Modes und Hooks zuerst — Leitplanken kosten eine Stunde und verhindern die teuersten Fehler. Dann MCP für die Werkzeuge, die die Aufgabe wirklich braucht. Sobald der Agent regelmäßig läuft: Routines für den Zeitplan und Memory, damit Gelerntes nicht verfällt. Dynamic Workflows lohnen ab dem Moment, in dem ein Ablauf mehr als drei verkettete Schritte hat — und Evals spätestens dann, wenn du dich beim Gedanken ertappst, der Agent sei „irgendwie schlechter geworden". Wer tiefer einsteigen will: Der große Agenten-Grundlagen-Guide baut die Konzepte von null auf, die Subagenten-Lektion im Kurs zeigt das Delegieren am konkreten Beispiel.