HyperAgent Field Notes #2: Vom Skill zur deploybaren Rolle

Field Notes Serie — Wir sind Teil der Closed Beta von HyperAgent. In Field Notes #1 haben wir den ersten Skill gebaut. Heute machen wir daraus eine deploybare Rolle.

In 30 Sekunden

• Ein Skill ist eine Fähigkeit. Eine Rolle ist ein Stellenprofil mit Trigger, Budget, Scope und Owner.
• Slack-Trigger via Slash-Command war in 10 Minuten konfiguriert. Cron-Trigger noch schneller.
• Budget-Limit ist nicht optional. Erster Lauf ohne Cap kostete uns 4× mehr als geplant.
• Permission-Scope ist die wichtigste Sicherheits-Hebel: "darf lesen, darf nicht posten" ist ein anderer Agent als "darf alles".
• Erste echte Rolle läuft jetzt 5× pro Woche autonom – mit Eval-Score 89 %.

Wo wir stehen

Aus Field Notes #1: Wir hatten einen Skill competitor-watchlist-scan. Lief manuell getriggert, lieferte saubere Outputs, Eval-Score bei 78 %.

Heute machen wir daraus etwas, das ohne uns läuft. Das war für uns der eigentliche "Aha"-Moment mit HyperAgent: Skills sind die Kür, Rollen sind das Produkt.

Die vier Bausteine einer Rolle

HyperAgent zwingt dich, vier Dinge explizit zu definieren, bevor eine Rolle deploybar wird:

1. Trigger – wann läuft die Rolle?

Drei Trigger-Typen, die wir benutzt haben:

• Cron – every Monday at 09:00. Klassisch, robust, langweilig (gut so).
• Slack-Slash-Command – /watchlist-scan mit optionalen Parametern. Praktisch für Ad-hoc-Runs.
• Webhook – wenn ein externes System (z. B. CMS-Update) den Agenten triggert.

Wir haben uns für eine Kombination entschieden: Cron als Default, Slash-Command für manuelle Re-Runs. Setup für beide zusammen ≈ 10 Minuten.

2. Budget – wie viel darf die Rolle verbrauchen?

Hier haben wir den ersten Fehler gemacht.

Erster produktiver Run ohne Budget-Cap: Der Agent hat sich in einem CSS-getriebenen Loop verfangen (eine Domain hatte einen rotierenden Hash im DOM, den er fälschlicherweise als "echte Änderung" interpretiert hat) und ist 4× durch alle 8 Domains gelaufen, bevor er fertig war. Kosten: ca. 4× das geplante Budget.

Konsequenz: Jede Rolle bekommt jetzt drei Budget-Grenzen:

Grenze	Was passiert beim Erreichen
Soft-Limit (80 %)	Slack-Notification an Owner
Hard-Limit (100 %)	Run wird abgebrochen, Owner wird informiert
Daily-Cap (Σ pro Tag)	Verhindert "viele kleine Runs" Overrun

Klingt nach Boring-Engineering. Ist es auch. Aber es ist der Unterschied zwischen "läuft in Prod" und "darf nicht in Prod".

3. Permission-Scope – was darf die Rolle?

Der wichtigste Hebel für Trust. Wir haben für unsere Rolle:

• ✅ Read auf 8 spezifische Domains (whitelist)
• ✅ Read auf unseren internen Snapshot-Storage
• ✅ Write in einen dedizierten Slack-Channel (#competitor-intel)
• ❌ Kein Zugriff auf Email, CRM, andere Slack-Channels
• ❌ Kein Zugriff auf "execute code" (auch wenn der Skill es theoretisch könnte)

Das Schreiben dieses Scopes hat uns gezwungen, eine Frage zu beantworten, die wir bei "klassischen" Automations selten so klar stellen: Was wäre der maximale Schaden, wenn diese Rolle gehackt oder fehlerhaft ist?

Antwort hier: ein Spam-Post in einem Channel. Akzeptables Risiko. Deploy.

4. Owner – wer ist verantwortlich?

Klingt trivial, ist es nicht. Eine Rolle ohne Owner ist ein Geist im System – läuft, funktioniert, aber niemand kümmert sich, wenn sie kippt.

HyperAgent zwingt dich, einen Owner zu setzen. Der Owner bekommt:

• Alle Soft/Hard-Limit Notifications
• Wöchentliche Eval-Score-Reports
• Failure-Alerts mit Trace-Link

Bei uns: Eine Person aus dem Marketing-Team ist Owner, nicht jemand aus Engineering. Genau richtig. Die Rolle dient einem Marketing-Outcome – also gehört sie auch dorthin.

Deploy: was tatsächlich passiert

Mit den vier Bausteinen war der Deploy einfacher als erwartet:

hyperagent deploy role competitor-watchlist
  --skill competitor-watchlist-scan
  --trigger cron:"0 9 * * MON" 
  --trigger slack-command:/watchlist-scan
  --budget soft=80% hard=100% daily=USD-15
  --scope from scope.yaml
  --owner marketing-team

(Das CLI ist optional, im Studio macht man dasselbe per Click.)

Nach dem Deploy: ein Dashboard-Card im Fleet-Overview mit Status, letztem Run-Score, Cost-Burndown und Permission-Audit-Log.

Erster autonomer Lauf

Montag 09:00, ohne dass jemand am Rechner saß:

• Trigger feuert
• Run startet, läuft 4 Min 12 Sek
• Slack-Post kommt automatisch in #competitor-intel
• Eval-Score: 89 % (vs. 78 % beim manuellen Run aus Field Notes #1)

Warum besser? Weil wir zwischen Field Notes #1 und #2 zwei kleine Skill-Updates gemacht haben (Cookie-Banner-Handling + besserer "Real Change"-Filter), und das Eval-Rubric uns objektiv gezeigt hat, dass beide Updates positiv waren.

Das ist der Loop, den wir in Field Notes #1 versprochen haben. Er funktioniert.

Drei Erkenntnisse aus Tag 2

1. Skill ohne Rolle ist eine Demo. Rolle ohne Skill geht nicht.

Beides braucht's. Aber die echte Arbeit liegt im Skill, die echte Reife in der Rolle. Teams, die nur Skills bauen, haben am Ende eine Sammlung von beeindruckenden Demos. Teams, die Rollen bauen, haben eine Belegschaft.

2. Budget-Limits sind kein Nice-to-have

Wer ohne Hard-Cap deployed, lernt es irgendwann teuer. Lieber einmal den 4×-Schmerz gehabt und dann nie wieder.

3. Owner-Frage entscheidet, ob eine Rolle überlebt

Eine Rolle ohne klaren Owner wird in 6 Wochen entweder still abgeschaltet oder produziert Müll, den keiner liest. Owner = Überlebensgarantie.

Was als Nächstes kommt

In Field Notes #3 geht's um den Sprung von einer Rolle zu einem Fleet – also wie man mehrere Rollen so orchestriert, dass sie sich gegenseitig nicht in die Quere kommen. Spoiler: Dort wird das Concept "Agent-Swarm" plötzlich praktisch relevant.

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