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

> Vom Demo zum Dauerbetrieb: Evals, Memory Tool, MCP, Dynamic Workflows, Routines und Permission Modes – 6 Bausteine mit echter Fallstudie.

- URL: https://thevibe-coding.de/guides/production-ready-ki-agenten-claude-2026
- Typ: guides | Veroeffentlicht: 2026-07-18 | Aktualisiert: 2026-07-18
- Autor: Vita Legne | Site: VIBE CODING — thevibe-coding.de

---

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

**Production-ready** ist ein [KI-Agent](/glossar/ai-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](/guides/claude-dangerously-skip-permissions-guide)
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:

```json
{
  "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](/kurs/hooks-automatische-leitplanken).

## Baustein 2 — MCP: Werkzeuge statt Copy-Paste

Das [Model Context Protocol](/glossar/mcp) 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:

```json
{
  "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](/mcp).

## 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:

```javascript
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](/guides/anthropic-claude-code-loops-guide-2026) 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:

```markdown
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](/modelle/claude-fable-5-mythos-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](/guides/ki-agenten-von-grund-auf-dein-umfassender-guide)
baut die Konzepte von null auf, die
[Subagenten-Lektion im Kurs](/kurs/subagenten-agent-teams) zeigt das
Delegieren am konkreten Beispiel.

## FAQ

### Was unterscheidet einen production-ready Agenten von einem Demo-Agenten?

Ein Demo-Agent funktioniert, solange jemand zuschaut. Production-ready heißt: Er läuft unbeaufsichtigt (Routines), hält Regeln auch ohne Aufsicht ein (Permission Modes, Hooks), erinnert sich an frühere Arbeit (Memory), liefert reproduzierbare Abläufe (Workflows) — und seine Qualität wird gemessen statt vermutet (Evals).

### Brauche ich alle sechs Bausteine gleichzeitig?

Nein. Die sinnvolle Reihenfolge: Permission Modes und MCP zuerst (ohne Leitplanken und Werkzeuge geht nichts), dann Routines für die Automatisierung. Memory, Workflows und Evals kommen dazu, sobald der Agent regelmäßig läuft und Fehler teuer werden.

### Was ist der Unterschied zwischen Dynamic Workflows und einfachen Prompts?

Ein Prompt bittet das Modell, mehrere Schritte in der richtigen Reihenfolge zu erledigen — ob das passiert, entscheidet das Modell. Ein Dynamic Workflow legt die Schritte als Skript fest (parallele Subagenten, Verifikations-Stufen, Schleifen); das Modell füllt die Schritte aus, kann aber keinen überspringen.

### Wie evaluiere ich einen KI-Agenten konkret?

Mit drei Ebenen: feste Testaufgaben mit bekanntem Soll-Ergebnis (Golden Paths), Rubrics für weiche Kriterien (bewertet ein LLM-Judge), und Regressions-Checks nach jeder Änderung an Prompt, Skills oder Modellversion. Anthropic stellt dafür 2026 eine eigene Eval-Anleitung für Agenten bereit.

### Welches Claude-Modell eignet sich 2026 für Produktions-Agenten?

Claude Fable 5 ist das leistungsstärkste allgemein verfügbare Modell und trägt lange Agenten-Sessions; für Routineläufe sind Sonnet 5 oder Haiku 4.5 oft wirtschaftlicher. Bewährt hat sich Modell-Routing: Standard-Läufe klein, kritische Läufe groß — per Eval abgesichert.

## Quellen

- [Demystifying evals for AI agents](https://www.anthropic.com/engineering/evals-for-ai-agents) — Anthropic Engineering
- [Memory tool — Claude API Dokumentation](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/memory-tool) — Anthropic
- [Dynamic workflows in Claude Code](https://code.claude.com/docs/en/workflows) — Anthropic / Claude Code Docs
- [Routines — Claude Code Dokumentation](https://code.claude.com/docs/en/routines) — Anthropic / Claude Code Docs
- [Permission modes — Claude Code Dokumentation](https://code.claude.com/docs/en/permission-modes) — Anthropic / Claude Code Docs
- [Claude Fable 5 & Mythos 5 — Ankündigung](https://www.anthropic.com/news/claude-fable-5-mythos-5) — Anthropic