Grok Bot Setup: Write the Contract, Not the Job Title
You open a new Grok Bot It asks for a name, a label, a description You type "Research Assistant" Then you spend the next week repeating the same three rules in every message That field is not a label
Article
Job breakdowns
You open a new Grok Bot
It asks for a name, a label, a description
You type "Research Assistant"
Then you spend the next week repeating the same three rules in every message
That field is not a label
The description is the only instruction your Bot keeps between tasks
Everything else you type lives in one conversation and stays there
The five surfaces, and what each one is for
Most confusion about Grok Bot comes from putting the wrong text in the wrong place
There are five surfaces. Each has one job
xAI's own documentation draws the line between the first two explicitly
Use the conversation for task-specific instructions. Use the description for rules that should remain true - docs.x.ai/grok-bot/bots
The same page gives the example: description holds "Never send external messages without approval." The message holds "Draft follow-ups for these twelve accounts"
One is a rule. One is a job
Swap them and you get a Bot that needs reminding
Write a contract, not a title
A title names a person
A contract names behaviour
This is what the docs call an operational description:
Own the weekly account-health review. Pull product usage and support signals, flag evidence of churn or expansion, and produce a linked watch list for the customer-success team. Never contact a customer or change an account without approval - docs.x.ai/grok-bot/bots
Notice the shape
Ownership. Sources. Output. Boundary
Here is the same shape as a template you can paste and fill:
Six lines
That is the whole contract
Here is the same Bot before and after, so the difference is concrete
Same Bot
One of them needs reminding every week
Why "Research Assistant" quietly costs you
The docs are blunt about generic roles
A job such as General Helper gives the Bot less guidance and makes its saved context harder to reuse - docs.x.ai/grok-bot/bots
A title tells the Bot what to call itself
It says nothing about sources, format, boundaries, or what to do when data is missing
So the Bot picks defaults
Then you correct it in chat
Then the correction stays in that chat, and the next task starts from zero again
Every repeated instruction is a missing rule
Here is the fastest diagnostic in this whole article
Open your last five conversations with one Bot and count how many times you typed the same instruction
Each one is a line that belongs in the description
The docs treat this as normal maintenance, not a fix for a broken Bot:
Update the description when you discover a durable preference, boundary, or responsibility that should shape future work - docs.x.ai/grok-bot/bots
The test is one question:
Will this still be true next month?
If yes, it is a rule. Put it in the description
If no, it is a task. Leave it in the message
The task request: five parts, every time
A clean description fixes half the problem
The other half is how you hand over the work
The official getting-started guide names five parts of a strong request
Outcome. Sources. Constraints. Deliverable. Review point - docs.x.ai/grok-bot/get-started
Outcome. Sources. Constraints. Deliverable. Review point - docs.x.ai/grok-bot/get-started
One of those is the one people leave out: the review point
Without it the Bot decides for itself when it is finished
Copy this:
Five lines again
A task written this way takes ninety seconds and removes most of the follow-up
Skills: the validation line is the one people skip
A skill is the method for one job, saved so you can run it again
The docs require six parts
- When to use it. 2. Required inputs and access. 3. The sequence of work. 4. How to validate the result. 5. What to return. 6. What requires approval - docs.x.ai/grok-bot/skills-routines-and-automations
Part four is the one that gets left empty
A skill without a validation step is a way to repeat the same mistake on a schedule
This is the ask that fills it in:
The last line matters
The docs warn that a taught skill arrives as a draft:
The learned skill is a draft. Add decision rules, failure handling, and approval boundaries that may not be obvious from one example
Lauren Tan runs the same order in practice
Peter Yang interviewed her and Peng Zheng, the engineering and design leads on Grok Bot
Complete a task with a bot manually, build a skill to capture best practices, then make it a routine. Lauren watches the first run, corrects mistakes, and turns what worked into a skill
Manual run first
Skill second
Routine last, and only once the skill works in one shot
Show it once, or tell it once
Teach a Task records you doing the job
It is fast, and it is the wrong tool more often than people expect
The recording limit is documented: ten minutes, visible browser interaction, no microphone audio
And the warning that matters:
Avoid exposing secrets during the demonstration; use the secure handoff flow for credentials
If your workflow includes a login screen, write the skill instead
When a second Bot earns its place
Every guide tells you to build a team
The docs are more conservative
Start with the smallest useful roster - docs.x.ai/grok-bot/bots
Start with the smallest useful roster - docs.x.ai/grok-bot/bots
Their test for a separate Bot is five things: a distinct goal, a distinct set of tools, a distinct working style, a distinct approval boundary, a distinct schedule
If two jobs share all five, they are one Bot with two tasks
Adding a @bot is cheap
Maintaining a contract for it is the actual cost
There is one more reason that has nothing to do with workload
A second Bot earns its place when more than one person needs it
That is what a Team Bot is for
Routines: one owner, and hard edges
A routine belongs to a single Bot
Skills are shared across your Bots. Routines are owned
That asymmetry has consequences, so write them down before you schedule anything
The gap between schedules is a floor
It is easy to schedule straight through it
Lauren Tan, engineering lead on Grok Bot, made this her first tip
my number 1 tip for controlling your grok @bot usage is to avoid scheduled routines that run too frequently. for example, a 15 min routine runs almost 100 times a day, and every run consumes tokens
She adds the part most people miss: the length of the chat makes every run more expensive
Her fix is to hand recurring work to a fresh Bot and keep the long conversation with your main one
And the one that prevents the worst week:
The no-data line is straight from the official example
If the source data is unavailable, report the failure instead of using old data
Memory is context, never a source
Your Bot remembers preferences, facts, and summaries of past work
That is useful
It is also the most confident source of stale information you own
The docs say it directly:
Memory is not a substitute for an authoritative source - docs.x.ai/grok-bot/bots
Memory is not a substitute for an authoritative source - docs.x.ai/grok-bot/bots
Their four rules:
-
Keep changing facts in the source system
-
Ask the Bot to cite or reopen current data for consequential decisions
-
Correct stale assumptions directly
-
Put explicit safety boundaries in the Bot description
The last one closes the loop back to the start of this article
Boundaries live in the description, because the description is the part that persists
The reversibility rule
Grok Bot has no undo
So one rule covers almost every approval decision:
If you can take it back, let the Bot do it
If you cannot, it asks first
The docs list the actions that belong behind approval: sending, purchasing, deleting, publishing, and changing production systems
Everything else is preparation, and preparation is safe to automate
Five minutes, every Bot
Do this once for each Bot you own
-
Open Edit Profile and read the description out loud. If it names a job title, rewrite it as a contract
-
Add the two rules you have typed most often in chat
-
Check that one line says what needs approval
-
Check that one line says what to do when a source is missing
-
Open View conversation details → Routines and read the last few runs
Five minutes per Bot
Most people find two missing lines
The setup I would ship first
-
Rewrite one Bot's description as a contract today. Pick the Bot you talk to most
-
Move your most repeated instruction out of chat and into that description
-
Run its main task once with all five parts: outcome, sources, constraints, deliverable, review point
-
Save that run as a skill and fill in the validation step before anything else
-
Add a no-data policy to one routine. Just one. See what changes
If you still reading
Bookmark this before you create your next Bot and type a job title into the description field
The expensive mistake is a roster of well-named Bots that each need reminding
-> Bookmark and retweet this article
-> Follow @silentguyy66
Published on grokbot.sh. Cite the public log, not a prompt pack.