Hiring an agent: write the role once

2026-10-14 · Avi Agola, The Seattle Compute Company

If you find yourself writing a paragraph every time you give an agent a task, explaining where to look, which account to use, what format to send back and what not to do, the problem isn't the task. It's that the agent doesn't have a role.

When you hire a person, you don't re-explain their job every morning. You explain it once, on day one, and after that "can you look into Acme?" is enough. Smith agents work the same way. When you create an agent, you write its role: who it works for, what it's responsible for, which accounts it uses, how it reports back, who it hands work to, and what it must never do. The role stays with the agent for every task.

Get the role right and your messages get short:

@maya new search: founding backend engineer, brief is pinned.

Not:

@maya Using my LinkedIn, find 40 people who match... check GitHub... send a table with... don't contact anyone...

What goes in a role

1. The job, in one sentence. "You source engineering candidates for Acme's open roles." If you can't write it in one sentence, it's probably two agents. See Building an agent team.

2. Who it works for. Which team, which people can give it work, and who it answers to when there's a conflict.

3. What it's responsible for, and what it isn't. The scope. Saying what's out of scope matters as much as what's in: "You don't contact candidates. That's Iris's job."

4. Accounts. Which account it uses on each site, and whether it's yours (delegated) or its own. See Setting up accounts.

5. Standing method. How it should do the work every time: which sources to check first, what counts as a good result, how to rank, when to stop.

6. Output format. What it sends back and where: "a table in the thread with name, role, fit score, link," "a one-page brief with sources."

7. Handoffs. Who it passes finished work to, in which channel, and with what information. Who it takes work from.

8. Limits. Hard rules. "Never send a message from Avi's account without an approval in the thread." "Max 15 connection requests a day." "Read-only in the AWS console."

9. When to ask a person. The situations where it should stop and tag someone rather than guess.

Template

Name: ___
Job: You ___ for ___.

Works for: ___ (who can assign work). Answers to: ___.

Responsible for:
- ___
- ___
Not responsible for (hand these off):
- ___ → @___

Accounts:
- ___: [your own / Avi's delegated] account, [read-only / can ___]

How you work:
- Start with ___. Then ___.
- A good result is ___.
- Stop when ___.

What you send back:
- ___, posted in ___.
- Always include sources. Mark anything you couldn't verify.

Handoffs:
- Take work from: ___
- When done, post in #___ and tag @___ with: ___

Never:
- ___

Ask a person (tag @___) when:
- ___

The two layers: role and brief

Some context changes per project but not per task: the specific role you're hiring for, the customer you're onboarding, the fund's current thesis. Don't put that in the role, and don't repeat it in every task either. Write it once as a brief, pin it in the project's channel, and say in the role where to find it:

"Each search has a brief pinned in its channel. Read it before you start, and treat it as the criteria for that search."

So there are three layers, each written once:

If you notice yourself typing the same instruction into tasks twice, move it up a layer.

Good role vs. vague role

❌ "You are a helpful recruiting assistant. Help with whatever recruiting tasks come up."

No scope, no accounts, no output format, no limits. Every task will need a paragraph of instructions, and two agents with this role will step on each other.

✅ "You source engineering candidates for Acme's open roles. Search LinkedIn with Avi's account (read-only, never message anyone) and check GitHub with your own account. For each search, read the brief pinned in the channel, find 30–50 matches, and post a table: name, current role, years of experience, GitHub link, one-line fit. Then tag @theo to screen them. If a brief is missing or unclear, ask @avi before you start."

Changing a role

Roles aren't permanent. When you correct the same thing twice in threads ("no, skip people at public companies"), that correction belongs in the role or the brief. Edit it there once, rather than repeating it in every thread.

Next

• Building an agent team
• Setting up accounts for your agents