HyperAgent Field Notes #2: From Skill to Deployable Role

Field Notes series — We're part of the closed beta of HyperAgent. In Field Notes #1 we built the first skill. Today we turn it into a deployable role.

In 30 Seconds

• A skill is a capability. A role is a job description with trigger, budget, scope, and owner.
• Slack trigger via slash command: 10 minutes to configure. Cron trigger: even faster.
• Budget cap is not optional. First run without a cap cost us 4× our planned budget.
• Permission scope is the most important safety lever: "may read, may not post" is a different agent than "may do anything".
• The first real role now runs 5× per week autonomously – with an eval score of 89%.

Where we are

From Field Notes #1: we had a skill called competitor-watchlist-scan. It ran manually, produced clean outputs, eval score 78%.

Today we make it run without us. This was the actual "aha" moment with HyperAgent for us: skills are the craft, roles are the product.

The four building blocks of a role

HyperAgent forces you to define four things explicitly before a role becomes deployable:

1. Trigger – when does the role run?

Three trigger types we used:

• Cron – every Monday at 09:00. Classic, robust, boring (good).
• Slack slash command – /watchlist-scan with optional parameters. Useful for ad-hoc runs.
• Webhook – when an external system (e.g. a CMS update) triggers the agent.

We picked a combination: cron as default, slash command for manual reruns. Setup for both ≈ 10 minutes.

2. Budget – how much can the role spend?

This is where we made the first mistake.

First production run without a budget cap: the agent got stuck in a CSS-driven loop (one domain had a rotating hash in the DOM that it misread as a "real change") and went through all 8 domains 4× before finishing. Cost: roughly 4× the planned budget.

Lesson: every role now has three budget limits:

Sounds like boring engineering. It is. But this is the difference between "runs in prod" and "not allowed in prod".

3. Permission scope – what is the role allowed to do?

The most important lever for trust. For our role we set:

• ✅ Read on 8 specific domains (whitelist)
• ✅ Read on our internal snapshot storage
• ✅ Write to one dedicated Slack channel (#competitor-intel)
• ❌ No access to email, CRM, other Slack channels
• ❌ No "execute code" capability (even though the skill could technically use it)

Writing this scope forced us to answer a question we rarely ask so clearly with classic automations: what's the maximum damage if this role is hacked or misbehaves?

Answer here: a spam post in one channel. Acceptable risk. Deploy.

4. Owner – who is accountable?

Sounds trivial. Isn't. A role without an owner is a ghost in the system – running, working, but no one cares when it tips over.

HyperAgent forces you to set an owner. The owner gets:

• All soft/hard limit notifications
• Weekly eval-score reports
• Failure alerts with a trace link

For us: someone from the marketing team owns this role, not someone from engineering. Exactly right. The role serves a marketing outcome – so it belongs there.

Deploy: what actually happens

With the four building blocks in place, the deploy was simpler than expected:

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

(The CLI is optional, you do the same in the studio with clicks.)

After deploy: a dashboard card in the fleet overview with status, last run score, cost burndown, and permission audit log.

First autonomous run

Monday 09:00, no one at the keyboard:

• Trigger fires
• Run starts, takes 4 min 12 sec
• Slack post lands automatically in #competitor-intel
• Eval score: 89% (vs. 78% on the manual run from Field Notes #1)

Why better? Because between Field Notes #1 and #2 we made two small skill updates (cookie-banner handling + a better "real change" filter), and the eval rubric showed us objectively that both updates were positive.

This is the loop we promised in Field Notes #1. It works.

Three takeaways from day two

1. Skill without a role is a demo. Role without a skill doesn't exist.

You need both. But the real craft is in the skill, the real maturity in the role. Teams that only build skills end up with a collection of impressive demos. Teams that build roles end up with a workforce.

2. Budget caps are not nice-to-have

If you deploy without a hard cap, you'll learn it the expensive way eventually. Better to feel the 4× pain once and never again.

3. The owner question decides whether a role survives

A role without a clear owner is either silently switched off in 6 weeks or producing garbage no one reads. Owner = survival guarantee.

What's next

In Field Notes #3 we cover the jump from a single role to a fleet – how to orchestrate multiple roles so they don't step on each other. Spoiler: that's where "agent swarm" suddenly becomes practically relevant.

→ Field Notes #1: Setup & first skill → Field Notes #3: From role to fleet → HyperAgent tool overview → HyperAgent full review → Agent swarm architectures compared → Agentic Engineering – how we partner with teams