Deep dive
Setting up a Grok Bot agent team: descriptions, delegation and routines
The single most useful detail in this walkthrough is that an agent's description field is not documentation — it is the routing table. It is what the other agents read to decide whether to hand work over, so a vague description produces duplicated work and dropped tasks. The second is structural: rather than one mega-agent commanding everything, build a small executive layer you talk to, each of which knows the handful of specialists below it. Grok Bot entered beta on 2026-08-11 and is reached through SuperGrok Heavy or Cursor Ultra / Teams Premium — see our September 6 changelog for the model and pricing behind it.
"Build & Sell Grok Bots (2 Hour Course)" by Nate Herk — Watch on YouTube →
Step-by-Step Breakdown
-
Give every agent one job, and say so in the description
Each bot has a name, an optional label (a job title), and a description. The description is the important one: it is what other agents read to work out what this agent does and whether to delegate to it. The demonstrated agents each do exactly one thing — one watches X, one makes animations, one owns content strategy, one checks meeting transcripts.
-
Build an executive layer instead of one mega-agent
The failure mode named explicitly: a single agent that controls a swarm gets overwhelmed because it has too many candidates to pick between, and it gets messy as you scale. The recommended shape is you → a few executives → their operators, where each executive knows the two or three specialists it routes to. Add executives only as you find you need them.
-
Write the chief-of-staff description as a routing rule
The verbatim description used for the top agent is the template worth stealing, because it encodes delegate-first behaviour rather than assuming it. See the config block below.
-
Understand the screen-versus-computer split
Each bot has its own screen, but they share the same computer. The practical consequence: if one bot authenticates into a site, the others can reach that session too. That is convenient and it is also the security model — an authentication you grant to one agent is effectively granted to the team.
-
Put recurring work on routines, and know what can trigger them
Routines are scheduled agent tasks. The demonstrated one runs every Sunday night and archives the week's completed work items out of the active board into an archive board, so the working list stays clean. Routines can run on short intervals as well as weekly. Available triggers at the time of recording are limited — a Slack message and a Teams message are shown, with email and calendar triggers described as planned rather than present.
-
Run group chats for cross-functional work
A channel containing several agents lets them tag each other, read each other's answers, and converge. The demo puts four executive agents in a "leadership" channel with a quarterly planning question and they return a short list of agreed decisions. This is the mode where the one-job-per-agent discipline pays off — each contributes from its own area rather than all answering the same question.
-
Log work outside the agent so you can review it
Projects created inside Grok Bot are mirrored into an external task tool, which is what makes the Sunday archive routine possible and what lets a human comment on work after the fact. Agents can push items around that board; the executives are the ones responsible for keeping it clean.
Chief-of-staff agent description (from video)
Template shown in the video. Adapt to your project — do not copy verbatim without reviewing each line.
You are Nate's chief of staff. Klouse is the only bot that Nate talks to.
Before doing any task, check whether another Grok Bot owns it and delegate first.
Only do the work yourself if no specialist fits, and then bring the result back here.
Gotchas & Caveats
- This is a course-length video from a creator who sells AI education, and the framing includes selling Grok Bot setups to other businesses. We have summarised the setup mechanics and left the business pitch out.
- Shared computer, separate screens means credential blast radius is the whole team, not one agent. If a bot only needs read access to one system, that is not something the current model expresses.
- Trigger options were thin at the time of recording — Slack and Teams messages, with more described as coming. If your workflow depends on an email or calendar trigger, check whether it has shipped before designing around it.
- Agents talking to agents scales badly without the topology discipline: the named risks are duplicated work and holes in plans when two agents both think the other owns something.
Key Takeaways
- The description field is the routing table. Other agents read it to decide what to delegate — write it as an instruction, not a bio.
- One job per agent. Ten narrow agents beat one broad one, provided there is a layer above them doing the routing.
- Delegate-first is a rule you have to write down. The chief-of-staff description explicitly says to check whether a specialist owns the task before doing it, and to only do the work directly if none fits.
- Bots share one computer and one set of logins, with separate screens. Authenticating one agent authenticates the team.
- Routines are where the value compounds — a weekly archive sweep keeps the shared work log usable, and that is what makes the whole thing reviewable by a human later.
- Group chats let several agents converge on a decision, which only works if each has a genuinely distinct remit.





