HyperAgent Field Notes #1: Setup, erster Skill und die Lektion aus Tag 1

Field Notes Serie — Wir sind Teil der Closed Beta von HyperAgent. In dieser Reihe teilen wir, was wir lernen, was funktioniert und was nicht. Heute: Tag 1.

In 30 Sekunden

• Onboarding läuft schnell: Workspace, erstes Modell-Routing, Slack-Integration ≈ 15 Minuten.
• Erster Skill ≠ erstes Wunschprojekt. Wir starten mit etwas Kleinem, Repetitivem, mit klarer "Definition of Done".
• Eval-Rubric VOR dem ersten Run anlegen. Sonst kannst du Verbesserung später nicht messen.
• Größter mentaler Shift: Du baust keinen Bot, du baust eine Rolle mit Stellenprofil.

Was wir gemacht haben

Wir hatten zwei Stunden Zeit für eine erste Session. Plan: Workspace einrichten, einen produktiven Use Case identifizieren, ersten Skill bauen, ersten Run produzieren.

1. Setup (≈ 15 Min)

• Workspace anlegen, Team einladen
• Default-Modell wählen (wir starten mit Claude für Reasoning, GPT-4-class für Tool-Calls)
• Slack-Workspace verbinden – wir wollen Trigger von Anfang an
• Ein Test-Run gegen einen Browse-Task: läuft, gibt sauberen Trace zurück

Bis hier nichts Spannendes. Die Plattform fühlt sich an wie eine sehr gut gemachte Studio-IDE für Agenten.

2. Use-Case-Auswahl: das war die wichtige Entscheidung

Unser erster Reflex: "Lass uns einen Sales-Research-Agenten bauen!" – also den ambitionierten Use Case, der einen Wow-Effekt erzeugt.

Wir haben ihn verworfen. Stattdessen haben wir gefragt:

Welche Aufgabe macht jemand in unserem Team mehrmals pro Woche manuell, mit klarem Output-Format und wenig Kontextabhängigkeit?

Antwort: Wettbewerbs-Watchlist-Update. Jeden Montag schauen wir uns 8 Konkurrenz-Domains an, prüfen Blog/Pricing/Changelog auf Veränderungen seit der letzten Woche, fassen das in eine kurze Slack-Nachricht.

Klein. Klar. Wiederholt. Perfekt für einen ersten Skill.

3. Der erste Skill

Wir haben einen Skill competitor-watchlist-scan definiert. Inhalt grob:

• Eingabe: Liste von URLs + letzter Scan-Timestamp
• Schritte: jede URL fetchen, gegen Snapshot vergleichen, "echte" Änderungen vs. dynamische Inhalte unterscheiden
• Ausgabe: strukturierte Liste { domain, change_type, summary, evidence_url }
• Definition of Done: Slack-Post mit max. 5 Bullet Points, jeder mit Link

Das Schreiben des Skills hat länger gedauert als erwartet (≈ 30 Min) – nicht wegen der Plattform, sondern weil wir merken: wir hatten den Prozess in unserem Kopf nie sauber dokumentiert. Genau das ist der Wert. HyperAgent zwingt dich, dein implizites Prozesswissen zu codifizieren.

4. Eval-Rubric vor dem ersten Run

Hier hätten wir fast einen Fehler gemacht: erst mal laufen lassen, dann gucken.

Stattdessen haben wir ein simples Rubric definiert:

Kriterium	Gewicht
Werden alle 8 Domains besucht?	20 %
Werden tatsächliche Änderungen erkannt (kein False Positive)?	40 %
Sind Quellen verlinkt und korrekt?	25 %
Ist die Zusammenfassung in unserer Tonalität?	15 %

LLM-as-Judge bewertet jeden Run gegen diese Rubric. Ergebnis: Wir können von Lauf zu Lauf objektiv messen, ob ein Skill-Update besser oder schlechter ist – statt zu raten.

5. Der erste echte Run

Erster Run: 78 % Score. Drei False Positives (CSS-Änderungen wurden als "Pricing-Update" gewertet), eine Domain wurde durch Cookie-Banner blockiert.

Beides klare Hinweise, was im Skill verbessert werden muss. Genau das ist der Loop, den wir uns gewünscht haben.

Drei Erkenntnisse aus Tag 1

1. Skills sind kein "fancy Prompt", sondern ein Prozessdokument

Wir haben unterschätzt, wie viel explizite Prozessbeschreibung ein guter Skill braucht. Die gute Nachricht: was du einmal aufschreibst, läuft danach 1.000 Mal automatisch ab. Skills sind Onboarding-Dokumente für Maschinen.

2. Eval first – sonst optimierst du blind

Ohne Rubric weißt du nach drei Runs nicht, ob du besser oder schlechter geworden bist. Mit Rubric siehst du Trends. Klingt banal, ist aber der größte Gamechanger.

3. Klein anfangen war richtig

Ein "kleiner" Skill, der jede Woche zuverlässig läuft, ist mehr wert als ein "großer" Skill, der einmal beeindruckt und dann nicht mehr läuft. Erst Konsistenz, dann Komplexität.

Was als Nächstes kommt

In Field Notes #2 geht's darum, wie aus diesem Skill eine deploybare Rolle wird – mit Slack-Trigger, Budget-Limit und Berechtigungs-Scope. In Field Notes #3 orchestrieren wir dann mehrere Rollen als Fleet mit Hand-off-Verträgen und Concurrency-Limits.

→ Field Notes #2: Vom Skill zur deploybaren Rolle → Field Notes #3: Von der Rolle zur Fleet → HyperAgent Tool-Übersicht → HyperAgent Vollständiges Review → Die 5 Bausteine eines KI-Agenten → Agentic Engineering – wie wir Teams begleiten