Die meisten Tutorials zu KI-Agenten beginnen mit der Tool-Konfiguration. Diesen MCP-Server verbinden. Jene Skill registrieren. Diese Prompts konfigurieren.
Dann wundern sich die Nutzer, warum ihr „Marketing-Direktor”-Agent an einem Tag E-Mails über SendGrid und am nächsten über Mailgun verschickt. Oder warum der „SEO-Analyst” mal Google Analytics abfragt, mal die Search Console — und manchmal einfach Metriken erfindet.
Die Agenten sind theoretisch leistungsfähig. Sie haben E-Mail-Tools. Sie haben Zugriff auf Analytics. Aber sie funktionieren nicht zuverlässig.
Das haben wir beim Entwickeln von 14 KI-Characters für TeamDay gelernt: Das Problem sind nicht die Tools. Das Problem ist die Methodik.
Die Abstraktionsfalle
Das KI-Agenten-Ökosystem liebt Taxonomien. Tools vs. MCP-Server vs. Skills vs. Plugins vs. Prompts. Entwickler verbringen Stunden damit zu debattieren: Sollte E-Mail ein MCP-Tool oder ein Bash-Skript-Skill sein?
Aus Sicht des Business-Nutzers sind diese Unterschiede bedeutungslos.
Wenn jemand seinen Marketing-Direktor bittet, „das wöchentliche Update zu senden”, ist es ihm egal, ob die E-Mail geht über:
- Ein MCP-Tool, das die Resend-API aufruft
- Eine Skill, die einen Bash-curl-Befehl ausführt
- Ein TypeScript-Skript mit Anmeldedaten aus Umgebungsvariablen
- Direktes SMTP via sendmail
Was zählt: Wird die E-Mail gesendet? Korrekt. Jedes Mal.
Entfernt man die Abstraktionen, bleiben genau zwei Primitive übrig:
1. Ausführbare Funktionen — Code, der läuft und ein Ergebnis zurückgibt (Tools, MCP-Tools, Bash-Befehle, Skripte)
2. Prompt-Text — Anweisungen, die die KI liest und befolgt (System-Prompts, Skills, CLAUDE.md-Dateien)
Alles andere ist Verpackung und Organisationsstruktur rund um diese beiden Primitive.
Die Abstraktionsfalle entsteht, wenn man für Taxonomie optimiert (Auswahl des Tool-Typs) statt für Zuverlässigkeit (funktioniert es wirklich?).
Das Prinzip des funktionierenden Beispiels
Hier ist die echte Einheit der KI-Agenten-Fähigkeit:
Ein funktionierendes Beispiel mit Anmeldedaten.
Keine Tool-Registrierung. Keine MCP-Server-Konfiguration. Keine Skill-Beschreibung.
Ein funktionierendes Beispiel sieht so aus:
# E-Mail über Resend senden
curl -X POST https://api.resend.com/emails \
-H "Authorization: Bearer $RESEND_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Wöchentliches Update",
"html": "<p>Inhalt hier</p>"
}'
# Erwartete Antwort:
# {"id": "abc-123", "status": "sent"}
# Anmeldedaten: RESEND_API_KEY in .env
# Zuletzt getestet: 2026-02-10
# Verantwortlich: Marketing-TeamOhne ein funktionierendes Beispiel wählt Claude willkürlich aus 1000 Optionen. Mit einem funktionierenden Beispiel folgt er jedes Mal dem bewährten Muster.
Der Unterschied zwischen „kann theoretisch E-Mails senden” und „sendet zuverlässig E-Mails über Resend mit unseren Anmeldedaten” ist ein getestetes, dokumentiertes funktionierendes Beispiel.
Das Rezept-Modell
Ein Rezept nennen wir ein getestetes, bewährtes funktionierendes Beispiel für eine bestimmte Aufgabe.
Unser Marketing-Direktor-Character hat folgende Rezepte:
- E-Mail über Resend senden (getestet, Anmeldedaten in env)
- Search Console API abfragen (getestet, OAuth konfiguriert)
- Keywords über Ahrefs analysieren (getestet, API-Schlüssel in env)
- Google Analytics-Daten abrufen (getestet, Property-ID dokumentiert)
Jedes Rezept enthält:
- Wann einsetzen — „Für das Senden von Transaktions-E-Mails”
- Anmeldedaten-Referenz — „API-Schlüssel: RESEND_API_KEY (in .env)”
- Funktionierendes Beispiel — Tatsächlicher curl-Befehl oder Code-Snippet, das funktioniert
- Erwartete Antwort — Wie Erfolg aussieht
- Zuletzt getestet — Datum, an dem wir verifiziert haben, dass es tatsächlich funktioniert
Rezepte sind keine abstrakten Tool-Definitionen. Sie sind konkrete, getestete Prozeduren, von denen wir wissen, dass sie funktionieren, weil wir sie ausgeführt haben.
Die Rezepte sind die atomaren Bausteine. Characters sind Kompositionen.
Bottom-up Character-Design
Hier ist die Methodik, die wirklich funktioniert:
Schritt 1: Wer ist dieser Character?
Keine abstrakten Fähigkeiten. Konkrete Rolle und Zweck.
Schlecht: „KI-Assistent mit Marketing-Fähigkeiten”
Gut: „Marketing-Direktor, der wöchentliche Performance-Updates an Stakeholder sendet”
Je klarer die Rolle, desto einfacher das Design.
Schritt 2: Welche Aufgaben erledigt diese Rolle tatsächlich?
Nicht was sie theoretisch tun könnte. Was sie buchstäblich am Dienstagmorgen tut.
Für den Marketing-Direktor:
- Kampagnen-Performance prüfen (montags um 9 Uhr)
- Trends bei organischem Traffic überprüfen (täglich)
- Wöchentliches Update an Stakeholder senden (freitags um 16 Uhr)
- Keyword-Rankings analysieren (auf Anfrage)
Beachten Sie: Das sind Aufgaben, keine Tools. „Kampagnen-Performance prüfen” ist eine zu erledigende Arbeit. Ob dazu die Google Ads API, die Search Console oder beides verwendet wird, ist ein Implementierungsdetail.
Schritt 3: Wie erledigen echte Menschen diese Aufgaben?
Hier werden die Anforderungen an den Tech-Stack konkret.
Für „Kampagnen-Performance prüfen”:
- Realer Mensch meldet sich bei Google Analytics an
- Zeigt die letzten 7 Tage Traffic an
- Vergleicht mit dem Vorjahreszeitraum
- Notiert wesentliche Änderungen
Technische Übersetzung:
- Google Analytics API abfragen
- Property-ID: 478766521
- Metriken: Sessions, Pageviews, Bounce Rate
- Zeitraum: Letzte 7 Tage vs. vorherige 7 Tage
- OAuth-Anmeldedaten erforderlich
Jetzt weiß man, welches Rezept zu entwickeln ist.
Schritt 4: Unterstützt unser Tech-Stack dies?
Können wir von unserer Laufzeitumgebung aus auf diese APIs zugreifen?
Prüfen:
- Haben wir Anmeldedaten? (Prüfen Sie .env, prüfen Sie OAuth-Setup)
- Können wir API-Aufrufe aus der Sandbox machen? (curl-Befehl testen)
- Sind erforderliche Pakete installiert? (Docker-Image prüfen oder bei Bedarf installieren)
Wenn die Antwort Nein ist, entweder:
- Die Fähigkeit zur Laufzeitumgebung hinzufügen (Pakete installieren, OAuth konfigurieren)
- Einen anderen Ansatz verwenden (MCP-Server bei schweren Abhängigkeiten)
- Die Rolle des Characters anpassen (Einschränkung eingestehen)
Die Laufzeit-Realität begrenzt das Mögliche. Wenn psql nicht in der Sandbox installiert ist, gibt kein noch so ausgefeiltes Prompt-Engineering Claude Datenbankzugriff.
Schritt 5: Rezepte schreiben und testen
Das ist der kritische Schritt, den die meisten überspringen.
Nicht schreiben:
Der Agent kann Google Analytics über die API abfragen.Stattdessen schreiben:
# Google Analytics abfragen — Traffic der letzten 7 Tage
curl -H "Authorization: Bearer $GA_ACCESS_TOKEN" \
"https://analyticsdata.googleapis.com/v1beta/properties/478766521:runReport" \
-d '{
"dateRanges": [{"startDate": "7daysAgo", "endDate": "today"}],
"metrics": [{"name": "sessions"}]
}'
# Zuletzt getestet: 2026-02-10 (hat funktioniert)
# Verantwortlich: Marketing-Team
# Anmeldedaten: GA_ACCESS_TOKEN aus OAuth (läuft nach 1 Std. ab)Dann tatsächlich ausführen. Überprüfen, dass es funktioniert. Beheben, was kaputt ist. Die funktionierende Version dokumentieren.
Das Rezept ist erst dann real, wenn es getestet ist.
Schritt 6: Den Character zusammensetzen
Jetzt hat man:
- Eine klare Rolle (Marketing-Direktor)
- Konkrete Aufgaben (wöchentliche Updates, Traffic-Analyse)
- Getestete Rezepte (Search Console, Analytics, Resend)
Der Character ist die Komposition:
# Marketing-Direktor Character
## Rolle
Sie sind TeamDays Marketing-Direktor. Sie überwachen die Performance,
analysieren Trends und kommunizieren Erkenntnisse an Stakeholder.
## Kernverantwortlichkeiten
- Wöchentliche Performance-Updates senden (freitags um 16 Uhr)
- Organischen Traffic täglich überwachen
- Keyword-Rankings auf Anfrage analysieren
## Verfügbare Rezepte
### E-Mail über Resend senden
Wann: Updates an Stakeholder senden
Rezept: /recipes/send-email-resend.md
### Search Console abfragen
Wann: Organischen Traffic oder Keywords analysieren
Rezept: /recipes/search-console-query.md
### Google Analytics abrufen
Wann: Gesamte Traffic-Trends prüfen
Rezept: /recipes/google-analytics-query.md
## Kommunikationsstil
- Direkt, ohne Unternehmenssprache
- Mit Zahlen beginnen („+15 % Traffic vs. letzte Woche")
- Erklären, was sich geändert hat und warum das wichtig istDer Character verweist auf Rezepte. Rezepte enthalten funktionierende Beispiele.
So entwickelt man Characters, die wirklich funktionieren.
Wiederverwendbarkeit durch Tech-Stack-Überschneidungen
Hier zahlt sich das Rezept-Modell aus.
Der Marketing-Direktor benötigt Zugriff auf die Search Console. Der SEO-Analyst benötigt Zugriff auf die Search Console. Dasselbe Rezept.
Der Vertriebsmitarbeiter muss E-Mails senden. Der Marketing-Direktor muss E-Mails senden. Dasselbe Rezept.
Die Rezepte werden naturgemäß zu einer Bibliothek:
/recipes/
├── send-email-resend.md
├── search-console-query.md
├── google-analytics-query.md
├── ahrefs-keyword-analysis.md
├── postgres-query.md
└── notion-page-create.mdJeder neue Character fügt vielleicht 1–2 neue Rezepte hinzu. Die meisten werden wiederverwendet.
Das funktioniert aber nur, wenn Rezepte getestete, funktionierende Beispiele sind. Wenn es abstrakte Tool-Definitionen sind, spielt Wiederverwendbarkeit keine Rolle, weil sie ohnehin nicht zuverlässig funktionieren.
Das Qualitäts-Gate
Die Fähigkeiten eines Characters sind nur so real wie seine getesteten Rezepte.
Zu stellende Fragen:
Nicht: „Hat dieser Character E-Mail konfiguriert?”
Fragen Sie: „Haben wir verifiziert, dass das E-Mail-Rezept tatsächlich eine E-Mail sendet?”
Nicht: „Kann dieser Character auf unsere Datenbank zugreifen?”
Fragen Sie: „Haben wir das Datenbank-Abfrage-Rezept mit echten Anmeldedaten getestet?”
Der Unterschied zwischen Characters, die Fassaden sind, und Characters, die liefern, sind getestete Rezepte.
Das haben wir auf die harte Tour gelernt. Wir entwickelten Characters für die /team-Seite unserer Marketing-Website. Sahen gut aus. 14 KI-Mitarbeiter, die man einstellen kann. Professionelle Beschreibungen. Beeindruckende Fähigkeiten.
Dann versuchten wir, sie für echte Arbeit einzusetzen. Die meisten funktionierten nicht vollständig. Fehlende Abhängigkeiten. Ungetestete Rezepte. Abstrakte Fähigkeiten ohne funktionierende Beispiele.
Das Qualitäts-Gate: Wenn wir es nicht getestet haben, liefern wir es nicht aus.
Laufzeit-Realität: Was tatsächlich möglich ist
Die Sandbox-Umgebung begrenzt das Mögliche. Diese Einschränkungen zu verstehen führt zu besserem Character-Design.
Was überall funktioniert
HTTP-APIs über curl:
curl -H "Authorization: Bearer $API_KEY" https://api.example.com/endpointJede Sandbox hat curl. Wenn man eine API über HTTP erreichen kann, kann man sie integrieren.
Bash-Skripte:
#!/bin/bash
# Jede Logik, die sich skripten lässt, funktioniert in der SandboxGängige CLI-Tools:
git, grep, sed, awk, jq, node, pythonWas Setup erfordert
Datenbank-Clients:
psqlodermysqlmuss installiert sein- Option 1: Im Docker-Image vorinstallieren
- Option 2: HTTP-API-Wrapper (pg-gateway)
- Option 3: MCP-Server für komplexe Abfragen
Schwere Pakete (Puppeteer, Playwright):
- Große Abhängigkeitsbäume
- Binäre Abhängigkeiten (Chrome)
- Option 1: Im Base-Image vorinstallieren (wenn häufig verwendet)
- Option 2: MCP-Server (isoliert, separat verwaltet)
OAuth-Flows:
- Interaktive Authentifizierung
- Token-Refresh-Logik
- Option 1: Tokens vorkonfigurieren (Umgebungsvariablen)
- Option 2: MCP-Server übernimmt Authentifizierung
Praktischer Entscheidungsbaum
- Geht es mit curl? → Rezept schreiben, testen, fertig
- Paket < 50 MB nötig? → Im Docker-Image installieren
- Schwere Abhängigkeiten nötig? → MCP-Server (letzter Ausweg)
- Interaktive Authentifizierung nötig? → MCP-Server oder vorkonfigurierte Tokens
Je einfacher die Laufzeit-Anforderungen, desto zuverlässiger der Character.
Der Unterschied zur üblichen Vorgehensweise
Top-down (verbreiteter Ansatz):
- KI-Agenten-Framework auswählen
- MCP-Server konfigurieren
- Skills und Tools hinzufügen
- System-Prompt schreiben
- Hoffen, dass es funktioniert
Probleme:
- Tools konfiguriert, aber nicht getestet
- Keine funktionierenden Beispiele, nur abstrakte Fähigkeiten
- Character kann theoretisch alles, macht zuverlässig nichts
- Erster echter Einsatz zeigt, dass es nicht wirklich funktioniert
Bottom-up (unser Ansatz):
- Konkrete Rolle und Aufgaben definieren
- Aufgaben auf echte menschliche Arbeitsabläufe abbilden
- Jeden Arbeitsablauf testen und verifizieren (Rezepte schreiben)
- Character aus getesteten Rezepten zusammensetzen
- Qualitäts-Gate: Jede Fähigkeit ist verifiziert
Ergebnis:
- Jedes Rezept ist getestet und bekannt funktionsfähig
- Character-Fähigkeiten entsprechen der getesteten Realität
- Erster Einsatz funktioniert, weil Rezepte verifiziert wurden
- Bei Problemen weiß man, welches Rezept zu korrigieren ist
Die Methodik kehrt den Prozess um: Von verifizierten Arbeitsabläufen starten, zu Characters hocharbeiten — nicht Tools von oben konfigurieren und hoffen.
Echtes Beispiel: Marketing-Direktor
Hier ist der tatsächliche Designprozess für einen unserer Characters.
Schritt 1: Rollendefinition
Wer: Marketing-Direktor von TeamDay Zweck: Marketing-Performance überwachen und Erkenntnisse kommunizieren
Schritt 2: Tatsächliche Aufgaben
Nach Beobachtung echter Marketing-Arbeit:
- Google Analytics auf Traffic-Trends prüfen (täglich)
- Search Console für organische Keyword-Rankings überwachen (wöchentlich)
- Performance-Updates an Stakeholder senden (wöchentlich)
- Spezifische Kampagnen auf Anfrage analysieren
Schritt 3: Echter menschlicher Arbeitsablauf
Für „wöchentliches Update senden”:
- Mensch meldet sich bei Google Analytics an
- Zeigt letzte 7 Tage an: Sessions, Pageviews, Top-Seiten
- Vergleicht mit Vorwoche
- Notiert wesentliche Änderungen
- Prüft Search Console auf Top-Suchanfragen
- Verfasst E-Mail mit Erkenntnissen
- Sendet über Gmail
Schritt 4: Tech-Stack-Prüfung
Google Analytics:
- ✅ API-Zugriff vorhanden
- ✅ Property-ID: 478766521
- ✅ OAuth konfiguriert
- ✅ Per curl abfragbar
Search Console:
- ✅ API-Zugriff vorhanden
- ✅ Website: teamday.ai
- ✅ OAuth konfiguriert
- ✅ Per curl abfragbar
E-Mail:
- ✅ Verwenden Resend (nicht Gmail)
- ✅ API-Schlüssel in env: RESEND_API_KEY
- ✅ Per curl sendbar
Schritt 5: Rezepte schreiben
Rezept 1: Google Analytics — Letzte 7 Tage
#!/bin/bash
# Letzten 7-Tage-Traffic aus Google Analytics abrufen
curl -H "Authorization: Bearer $GA_ACCESS_TOKEN" \
"https://analyticsdata.googleapis.com/v1beta/properties/478766521:runReport" \
-d '{
"dateRanges": [
{"startDate": "7daysAgo", "endDate": "today"},
{"startDate": "14daysAgo", "endDate": "8daysAgo"}
],
"metrics": [
{"name": "sessions"},
{"name": "totalUsers"},
{"name": "screenPageViews"}
],
"dimensions": [{"name": "pagePath"}]
}'
# Testergebnis (2026-02-10):
# {
# "rows": [
# {"dimensionValues": [{"value": "/"}],
# "metricValues": [{"value": "1243"}, {"value": "892"}, ...]}
# ]
# }
# Anmeldedaten: GA_ACCESS_TOKEN (OAuth, 1 Std. Gültigkeit)Getestet: ✅ Funktioniert Zuletzt verifiziert: 10.02.2026
Rezept 2: E-Mail über Resend senden
#!/bin/bash
# E-Mail über Resend API senden
TO="$1"
SUBJECT="$2"
BODY="$3"
curl -X POST https://api.resend.com/emails \
-H "Authorization: Bearer $RESEND_API_KEY" \
-H "Content-Type: application/json" \
-d "{
\"from\": \"[email protected]\",
\"to\": \"$TO\",
\"subject\": \"$SUBJECT\",
\"html\": \"$BODY\"
}"
# Testergebnis (2026-02-10):
# {"id": "abc-123", "status": "sent"}
# Anmeldedaten: RESEND_API_KEY in .envGetestet: ✅ Funktioniert Zuletzt verifiziert: 10.02.2026
Schritt 6: Character zusammensetzen
# Marketing-Direktor
Sie sind TeamDays Marketing-Direktor. Sie überwachen die Performance
und kommunizieren Erkenntnisse.
## Wöchentliche Update-Aufgabe
Jeden Freitag um 16 Uhr:
1. Google Analytics abfragen (letzte 7 Tage vs. vorherige)
Rezept: /recipes/google-analytics-7day.sh
2. Search Console abfragen (Top organische Suchanfragen)
Rezept: /recipes/search-console-top-queries.sh
3. E-Mail verfassen:
- Betreff: „TeamDay Marketing Update — Woche vom [Datum]"
- Format:
**Traffic:** [Sessions] ([+/-]% vs. Vorwoche)
**Top-Seiten:** [Top 3 auflisten]
**Top-Suchanfragen:** [Top 3 auflisten]
**Wesentliche Änderungen:** [alles mit >20 % Änderung]
4. Über Resend senden
Rezept: /recipes/send-email-resend.sh
An: jozo at teamday.aiErgebnis: Ein Character, der zuverlässig wöchentliche Updates sendet, weil jeder Schritt ein getestetes Rezept ist.
Was wir auf die harte Tour gelernt haben
1. „Getestet” bedeutet wirklich getestet
Wir dokumentierten Rezepte. Sie sahen gut aus. Wir lieferten Characters aus.
Dann versuchten wir, sie einzusetzen. Die Hälfte der Rezepte war nie ausgeführt worden. API-Endpunkte hatten sich geändert. Anmeldedaten waren falsch. Property-IDs waren veraltet.
Die Lösung: Jedes Rezept testen. Wirklich ausführen. Antwort verifizieren. Aktualisieren, wenn sich APIs ändern.
2. Rezepte veralten
APIs ändern sich. Anmeldedaten laufen ab. Dienste werden eingestellt.
Die Lösung: Jedes Rezept datieren. Wenn ein Character versagt, Rezept-Daten prüfen. Erneut testen und aktualisieren.
3. Laufzeit-Lücken sind real
Wir entwarfen einen SQL-Analyst-Character, der unsere Datenbank abfragt. Dann stellten wir fest, dass psql nicht in der Sandbox installiert war.
Die Lösung: Laufzeit-Fähigkeiten testen, bevor Characters entworfen werden. Wenn psql fehlt, entweder installieren oder einen HTTP-API-Wrapper verwenden.
4. Komposition schlägt Konfiguration
Wir verbrachten Wochen damit, MCP-Server für verschiedene Fähigkeiten zu konfigurieren. Komplexes Setup. Viele bewegliche Teile.
Dann schrieben wir einfache Bash-Skripte mit curl-Befehlen. Sie funktionierten sofort.
Die Erkenntnis: Einfach beginnen. Bash-Skripte mit curl bringen einen 80 % des Weges. Komplexität nur hinzufügen, wenn Einfaches nicht ausreicht.
Die Metaerkenntnis
Diese gesamte Methodik entstand beim Entwickeln von KI-Characters, die wirklich funktionieren mussten — nicht nur in Demos gut aussehen.
Wenn man für Demos entwickelt:
- Abstrakte Fähigkeiten sind in Ordnung
- „Kann E-Mails senden” reicht aus
- Konfigurations-Screenshots sehen beeindruckend aus
Wenn man für den Produktivbetrieb entwickelt:
- Getestete Rezepte sind Pflicht
- „Sendet zuverlässig E-Mails über Resend mit unseren Anmeldedaten” ist der Maßstab
- Funktionierende Beispiele sind wichtiger als Konfigurations-Komplexität
Der methodische Unterschied: Demos optimieren für Fähigkeitsbreite, Produktion optimiert für Zuverlässigkeitstiefe.
Wir entwickeln KI-Teams, in denen Characters echte Arbeit leisten. Das zwang uns, das Zuverlässigkeitsproblem zu lösen.
Die Bottom-up-Rezept-first-Methodik ist das Ergebnis.
Selbst ausprobieren
So entwickeln Sie einen Character, der wirklich funktioniert:
-
Eine konkrete Rolle definieren Nicht: „Marketing-KI” Sondern: „Marketing-Direktor, der wöchentliche Updates sendet”
-
3 konkrete Aufgaben auflisten Nicht: „Marketing-Daten analysieren” Sondern: „Traffic der letzten 7 Tage in Google Analytics prüfen”
-
Ein funktionierendes Beispiel schreiben Keine Tools dokumentieren. Einen curl-Befehl schreiben, der funktioniert. Testen. Antwort verifizieren.
-
Eine Rezept-Datei erstellen Das funktionierende Beispiel als
/recipes/aufgaben-name.mdspeichern Einschließen: wann einsetzen, Anmeldedaten, funktionierender Code, Datum des letzten Tests -
Aus dem Character referenzieren System-Prompt verweist auf Rezept-Datei Character weiß, wann und wie es einzusetzen ist
-
End-to-End testen Den Character wirklich für die Aufgabe einsetzen Beheben, was nicht funktioniert Das Rezept aktualisieren
Mit einer Aufgabe, einem Rezept, einem Character beginnen.
Sobald man einen entwickelt hat, der zuverlässig funktioniert, erschließt sich die Methodik. Dann auf weitere Rezepte und Characters ausweiten.
Auf unserer /team-Seite haben wir 14 KI-Characters. Sie sehen professionell aus. Beeindruckende Fähigkeiten. Aber wir haben gelernt: aussehen wie fähig und tatsächlich fähig sein sind verschiedene Dinge.
Die, die wirklich funktionieren, haben getestete Rezepte. Die Fassaden haben abstrakte Tool-Definitionen.
Die Methodik ist nicht kompliziert: Bottom-up von funktionierenden Beispielen, zu Characters zusammensetzen, End-to-End testen.
Aber sie kehrt die übliche Vorgehensweise beim Entwickeln von KI-Agenten um. Und genau diese Umkehrung macht Characters zuverlässig.
Von Rezepten aus entwickeln. Alles testen. Liefern, was funktioniert.