HyperAgent Field Notes #3: Von der einzelnen Rolle zur Fleet

Field Notes Serie — Wir sind Teil der Closed Beta von HyperAgent. In Field Notes #1 ging's um den ersten Skill, in Field Notes #2 um den Sprung zur deploybaren Rolle. Heute: mehrere Rollen als Fleet.

In 30 Sekunden

• Drei Rollen, ein Outcome — die Watchlist-Rolle bekam Geschwister: ein Briefing-Writer und ein Slack-Responder.
• Hand-off-Verträge sind das, was Workflow-Tools nicht haben: explizite Schemas zwischen Rollen, nicht „die nächste liest schon irgendwie".
• Shared Memory ist Pflicht, sobald zwei Rollen denselben Kontext brauchen. Sonst zahlst du jede Recherche doppelt.
• Concurrency-Limit auf Fleet-Ebene verhindert, dass Trigger-Stürme dein Budget killen.
• Es gibt einen Fleet-Owner, nicht nur Rollen-Owner. Sonst kümmert sich keiner ums Ganze.

Wo wir stehen

Aus Field Notes #2: Die competitor-watchlist-Rolle läuft jeden Montag autonom mit 89 % Eval-Score. Slack-Posts kommen pünktlich, Budget hält, alle happy.

Heute machen wir den unbequemen nächsten Schritt: Wir hängen zwei weitere Rollen dran und schauen, ob das Ganze als System funktioniert – oder ob wir uns drei Rollen mit drei eigenen Logiken bauen, die nichts voneinander wissen.

Spoiler: erst Variante 2, dann Variante 1. Genau das ist die Lektion von Tag 3.

Die neue Fleet

Wir wollten testen, ob HyperAgent das Multi-Agent-Versprechen einlöst. Setup:

Rolle	Job	Trigger
competitor-watchlist-scan	Scan + strukturierte Findings (aus Field Notes #2)	Cron Mo 09:00
competitive-briefing-writer	Aus Findings ein Briefing-Doc bauen	Hand-off von Rolle 1
slack-question-responder	Fragen im Channel zu Findings beantworten	Slack-Mention @watchlist

Drei Rollen, ein gemeinsamer Outcome: das Team weiß Montag, was bei Wettbewerbern los ist – und kann dazu im Channel nachfragen.

Drei Rollen ≠ drei Skills + Multiplikation

Naiver Plan: Rolle 1 produziert JSON, Rolle 2 liest das JSON, Rolle 3 antwortet auf Fragen mit Zugriff auf das JSON. Klingt einfach.

In der Praxis lief der erste Versuch so:

• Rolle 1 schreibt Findings in einen Slack-Channel als formatierten Post.
• Rolle 2 wird getriggert, parsed den Slack-Post, baut ein Briefing-Doc – aber das Markdown-Parsing geht in 3 von 8 Domains schief, weil Rolle 1 die Format-Bullets unterschiedlich rendert.
• Rolle 3 antwortet auf Fragen, hat aber nur den Briefing-Doc-Stand, nicht die Roh-Findings. Wenn jemand fragt „Was war nochmal der genaue Pricing-Change bei X?" – Antwort: ¯\(ツ)/¯.

Das ist die Workflow-Tool-Falle in Reinform. „Wir verbinden halt die Outputs" reicht für Toy-Demos, aber nicht für eine Fleet, die in Prod ohne Babysitter läuft.

Vier Bausteine einer Fleet (vs. einer Rolle)

Aus dem Schmerz wurden vier Konstrukte, die HyperAgent für Fleets erzwingt:

1. Hand-off-Verträge — explizite Schemas zwischen Rollen

Statt „Rolle 1 postet, Rolle 2 liest" haben wir einen typisierten Hand-off definiert:

handoff: watchlist-findings
producer: competitor-watchlist-scan
consumer: competitive-briefing-writer
schema:
  findings:
    - domain: string
      change_type: enum[blog, pricing, changelog, ui]
      summary: string (max 200 chars)
      evidence_url: url
      raw_diff_ref: storage-key

Klingt nach Boilerplate, ist aber der Unterschied zwischen „funktioniert manchmal" und „funktioniert immer". Rolle 2 kann jetzt nicht mehr „den Slack-Post falsch parsen", weil sie den Slack-Post gar nicht mehr sieht – sie bekommt strukturierte Findings.

Bonus: HyperAgent validiert den Hand-off zur Laufzeit. Wenn Rolle 1 ein Schema-bruchhaftes Output produziert, fliegt das im Trace auf, bevor Rolle 2 startet.

2. Shared Memory — eine Wahrheitsquelle, drei Konsumenten

Hier ist die zweite große Erkenntnis: alle drei Rollen brauchen Zugriff auf dieselben Roh-Findings, nicht auf ein Aggregat-Artefakt.

Lösung: Rolle 1 schreibt die Findings in einen Shared Memory-Namespace (watchlist/findings/{week}), Rolle 2 baut das Briefing daraus, Rolle 3 hat lesenden Zugriff für Q&A.

Folge: wenn jemand im Channel fragt „Was war der genaue Pricing-Change bei X?", liest Rolle 3 direkt das raw_diff_ref aus dem Shared Memory. Eine Recherche, drei Konsumenten. Vorher hätten wir die Recherche in Rolle 3 wiederholt – mit doppelten Token-Kosten und ggf. abweichendem Ergebnis.

3. Concurrency-Limit — der Trigger-Sturm-Schutz

Erste Woche im Live-Betrieb: jemand testet @watchlist mit fünf Fragen kurz hintereinander. Rolle 3 wird fünfmal parallel getriggert. Jeder Run zieht das Shared Memory plus 2 Tool-Calls. Fleet-Budget verbrennt in 90 Sekunden.

Lösung: Concurrency-Limit auf Fleet-Ebene.

Limit	Wert	Was passiert
Max parallele Runs gesamt	3	Run 4 wartet in der Queue
Max parallele Runs pro Rolle	2	Verhindert, dass eine Rolle die ganze Fleet blockiert
Queue-Timeout	60 s	Drüber → freundliche „bin grade beschäftigt"-Antwort statt Timeout

Was sich in einer einzelnen Rolle in Field Notes #2 als Budget-Cap manifestierte, ist hier ein Concurrency-Problem. Andere Klasse von Schutz, gleiche Philosophie.

4. Fleet-Owner — jemand, der die Architektur besitzt

In Field Notes #2 hatten wir einen Rollen-Owner (Marketing). Das reicht nicht mehr.

Wenn drei Rollen miteinander reden, ist die Frage „warum ist das Briefing heute leer?" eine System-Frage, keine Rollen-Frage. Antwort kann sein:

• Rolle 1 hat 3 Domains nicht erreicht (Cookie-Banner-Update beim Wettbewerber)
• Rolle 1 hat geliefert, aber Hand-off-Schema hat sich geändert und Rolle 2 nimmt nichts an
• Rolle 2 läuft, aber Shared Memory war leer wegen Cache-Eviction
• Rolle 3 steht in der Queue wegen Concurrency-Limit

Ein einzelner Rollen-Owner sieht das nicht. Wir haben deshalb einen Fleet-Owner ergänzt, der Zugriff auf das Fleet-Dashboard hat (alle Rollen, alle Hand-offs, alle Shared-Memory-Reads/Writes, alle Queue-Zustände).

Bei uns: derselbe Mensch wie der Rollen-Owner für competitor-watchlist-scan, plus eine zweite Person aus dem Engineering-Team als Backup. Wichtig: nicht „Engineering owns die Fleet, weil sie technisch ist". Owner bleibt im Fachbereich, Engineering ist Sparringspartner.

Was nach 2 Wochen rauskam

Nach 14 Tagen Live-Betrieb der dreiteiligen Fleet:

• Eval-Score Rolle 1 (Findings): 91 % (vs. 89 % als Solo-Rolle – Nebeneffekt der besseren Outputs durch Schema-Zwang)
• Eval-Score Rolle 2 (Briefing): 84 % (Hauptmangel: zu lange Briefings, wir kürzen den System-Prompt)
• Eval-Score Rolle 3 (Q&A): 88 %
• Anzahl Doppel-Recherchen: 0 (vs. ~30 % im naiven Setup)
• Budget-Verbrauch: −18 % vs. drei isolierte Rollen, die alles dreimal machen

Das ist der Punkt, an dem aus „mehrere Agenten" eine Belegschaft wird.

Drei Erkenntnisse aus Tag 3

1. Workflow-Tools können das nicht — und das ist okay

n8n / Zapier / Lindy könnten die drei Rollen verkabeln, aber Hand-off-Verträge mit Schema-Validation, Shared Memory mit Audit-Log und Concurrency-Limits auf Fleet-Ebene sind eine andere Klasse von Plattform. Workflow-Tools verbinden Outputs. Agent-Plattformen koordinieren Rollen. Beides hat seinen Platz.

2. Eine Fleet ist nicht „mehr Rollen", sondern „andere Architektur"

Wer drei Solo-Rollen baut und hofft, dass das eine Fleet wird, hat in 2 Wochen Doppel-Recherchen, inkonsistente Outputs und unkontrollierbares Budget. Eine Fleet muss als System designt sein – mit Hand-offs, Memory und Concurrency.

3. Fleet-Owner ist die wichtigste Rolle, die du nie ausschreibst

Niemand bewirbt sich auf „Fleet-Owner". Aber ohne diese Rolle stirbt jede Fleet nach 6 Wochen am ersten Symptom, das niemand zuordnen kann.

Was als Nächstes kommt

In Field Notes #4 geht's um den Übergang von „funktioniert in Beta" zu „darf an Kunden-Daten ran" — also Prompt-Injection-Schutz, Datenklassifikation, Audit-Anforderungen. Die unsexy, aber überlebenskritische Seite.

→ HyperAgent Tool-Übersicht → Field Notes #1: Setup & erster Skill → Field Notes #2: Vom Skill zur deploybaren Rolle → HyperAgent Vollständiges Review → Agent-Swarm-Architekturen im Vergleich → Agentic Engineering – wie wir Teams begleiten