Work through this with the app open in the other window. The blocks run in the order the work actually arrives in, and the last one is the filter you should have applied before any of it.
App-specific details below are Grok Bot's (SpaceXAI, launched 11 August 2026). The rest is about how you cut the work up, which will outlive this app.
1. A list of jobs, not a list of agents
Don't name an agent yet. Open a blank page and write down what repeated in the last month: the review you keep redoing, the report you rebuild by hand every Monday, whatever you answer in more or less the same words each time it lands.
Jobs that repeated: 1. ______ 2. ______ 3. ______ 4. ______ 5. ______
- [ ] Every line is a task you actually did more than twice, not one you plan to.
- [ ] Each line fits in one sentence without needing the word "and".
- [ ] Split every line that needed "and" into two lines.
- [ ] For each line, you can say where the work comes in from.
- [ ] The number of agents you're about to create equals the number of lines left on the page.
If a job only reads as one job because you said "and" in the middle, it was two jobs and one agent will do both of them slightly worse.
2. The description that routes the work
When you create an agent you give it a name, a title, and a description. The description is the routing table. An agent facing a task it can't do reads every other agent's description, picks the one that fits, and messages it directly. Write it for a stranger deciding whether to hand over a task.
A working description holds three things in one sentence: the repeatable task, the data source, the boundary.
Handles ______ (the repeatable task), working from ______ (where the data lives), and does not ______ (the boundary).
Useless: helps with communication.
Working: handles Slack conversations about media and sponsorship, including the private partnership channels, and never sends anything to a partner without me.
- [ ] Every description names the repeatable task in words another agent could match against.
- [ ] Every description names where the data lives.
- [ ] Every description names one thing this agent does not do.
- [ ] No two of your descriptions could plausibly match the same incoming task.
- [ ] Read each one cold, as that stranger, and check you could decide where the task goes.
A bad description doesn't throw an error. It fails as silence: the task never reaches the agent, and you experience that as the system being stupid rather than as a sentence you wrote badly. When work goes nowhere, reread the description before you touch anything else.
3. What the team shares, what belongs to one agent
Skills and connectors are shared across all your agents, so one sign-in to a service serves the whole team. The machine and the description are per agent: each agent runs on its own computer in the cloud, with a browser, a file manager, and a terminal.
That split has one edge worth planning for. A connector is shared, but a logged-in browser session lives on one machine. Two agents that both need to be signed into the same account are two sign-ins, done twice, by hand if the site demands it.
- [ ] Sort your accounts into two piles: reached through a connector, and needing a real logged-in browser. - [ ] For each browser-session account, list which agents need it and count the sign-ins that implies. - [ ] Where a site throws a puzzle at sign-in, take the agent's browser over yourself, click through it, and leave the agent logged in. - [ ] Connect the repository or folder holding your notes, prompts, and working rules once, so every agent you create later inherits it. - [ ] Give each agent a revocable work account to sign in with, not your own main login. - [ ] You know which single sign-in to pull if you want one agent to stop reaching something.
Anything shared you set up once. Anything per agent you set up again for every agent you add, so count the per-agent work before you decide how many agents you want.
4. The routine: a clock or an event
A routine is a skill plus a rule about when it fires. Two kinds of rule, and the second one has a trap in it.
On a clock
- [ ] The days and the time are written down, and they match when you'd actually read the output.
- [ ] Ask for a sample run first and read what comes back.
- [ ] Open the instruction the agent wrote for itself and edit it in plain text.
- [ ] You know what arrives with your laptop shut, because the routine runs in the cloud.
On an event
- [ ] The trigger is one that exists today. Six shipped at launch. I expect that list to grow, but don't plan a workflow around a trigger that isn't there yet. - [ ] Name the exact place the event happens: which channel, which repository, which inbox. - [ ] The listener has been invited into that place. In Slack that means running /invite @cursor in the channel itself. - [ ] Ask the agent which channels it can really see, and read the answer rather than assuming. - [ ] Watch one real event fire from end to end, not just the setup confirmation.
The invite is the check that saves you an hour. An event trigger has two halves, the rule and the permission to observe, and only one of them lives in the agent. Skip the invite and everything looks configured while nothing ever fires.
5. Say where the result should land
Once your agents have machines of their own, "build me X" is an incomplete sentence. The missing half is the destination, and if you didn't say it, you don't get to be surprised by where the thing ends up.
Where this should end up: the agent's cloud machine / a repository / a file back to you / somewhere live ______
- [ ] Every build request you send names a destination. - [ ] Check where the last thing you asked for is actually running, your own laptop or the agent's machine. - [ ] The agent has a pointer to the source of truth for brand and for pricing. - [ ] That pointer lives in a description or a connected repository, not in a message you'd have to send again next time. - [ ] Templates you reuse sit somewhere the agent can read, not somewhere you paste from. - [ ] When a first version comes back wrong, check what it was pointed at before you rewrite the request.
An agent with no pointer to your standards will guess, and it will guess confidently. A prototype that comes back in a plausible invented color scheme costs a message to fix and nothing to prevent.
6. The filter you should have used first
Nothing in this block is about the tool. Run it before you create a single agent.
The constraint that costs you time this month: ______
The one narrow agent for exactly that: ______
Review date: ______
- [ ] The constraint is one you feel now, not one you've forecast.
- [ ] One agent covers it, with a description sharp enough to route to.
- [ ] The review date is a real date, roughly a week out, and it sits in your calendar.
- [ ] Write down what "it worked" will look like on that date.
- [ ] There's no agent on your list you couldn't attach a pain point to.
An agent built without a pain point behind it is a week spent playing with something clever.
The first week
Come back to these after the first run that happened while you weren't watching.
- [ ] After the first real run of a recorded skill, open the skill and read what it says now. The agent may have already patched a step you got wrong while recording. - [ ] Set permissions per action, and know which agent is allowed to act without asking. - [ ] Look at the weekly usage meter on the account. A routine firing more often than you meant shows up there before it shows up anywhere else. - [ ] Decide what stays at the desk. Two hours and a hard problem still belong in a desktop tool with your own setup around it.