LearnGrokA Bot is not a smarter chat window. It signs in to your tools and does the work, then tells you what it did. That difference is the reason this page spends as much time on what it is allowed to do as on what you ask for.
By the end you will have one job (a real one) off your own list, running without you.
1. Pick the job
The first job should be all four of these:
- Something you have done yourself, recently. You need to recognise a bad result instantly.
- Repetitive. If it happens once, briefing it costs more than doing it.
- Reversible. Nothing that sends, pays, deletes or publishes on the first run.
- Checkable in under a minute. You will check every run at first.
Good first jobs: a Monday summary of last week's numbers, drafts for the unanswered messages in one inbox, a tidy-up of one folder, a weekly digest of what changed in a document.
Bad first jobs: anything with a customer at the other end, anything touching money, anything where "done" is a matter of taste.
2. Write the brief
A brief has five parts. Missing any one of them is where first attempts go wrong.
- The outcome, in a sentence. "Six draft replies in my drafts folder, none sent."
- The inputs, named. Which inbox, folder, sheet, date range. Do not make it guess which source you meant.
- The boundaries. Two explicit lists: what it may do, and what it must come back to you for.
- What done looks like. A state you can check. "Six drafts, none sent" is checkable. "Inbox handled" is not.
- What to do when blocked. Stop and ask, skip and note, or assume and record. Say which.
There is a longer walkthrough of each part in Giving a Bot its first task, and briefs you can copy in the Grok Bot task brief prompts.
3. Give it the narrowest access that works
Connect only the tool this job needs, and only the part of it the job touches. One inbox, not the whole account. One folder, not the whole drive.
The question to ask before every connection: if this went wrong in the worst plausible way, what would it reach? If the answer makes you uneasy, narrow it before you run, not after.
Connecting Bots to your tools safely goes through this properly, including what to do about shared accounts.
4. Run it once: watching
Run the job manually the first time and read the whole result, not the summary, the actual output. You are checking three things:
- Did it use the input you meant?
- Is the output right, in the way you would have done it?
- Did it stop where you told it to stop?
Whatever you had to correct goes straight back into the brief. A brief that absorbs its corrections gets better every week; one that does not will keep making the same mistake politely.
Checkpoint: one clean run you did not have to redo by hand.
5. Put it on a schedule
Only once a manual run has been clean two or three times in a row. Set it to run on the rhythm the job actually has: Monday morning, end of day, the first of the month.
Then keep the training wheels on for a while:
- Draft, do not send. Any job that ends in something irreversible should end one step earlier until you trust it.
- Read every run for the first few cycles, then spot-check.
- Give it a way to say it is stuck rather than guessing, and check that it actually does.
6. When it misbehaves
The common failures have specific fixes, and none of them are "write a better prompt":
- A scheduled routine did not run
- A Bot is stuck waiting, or acted without asking
- A website keeps asking a Bot to log in
- A Bot's plugin will not install or authenticate
The habit worth keeping
One job, running cleanly, is worth more than six half-briefed ones. When the first is boring; when you stop reading its output closely because it is always right, that is the signal to add the second.
For what a Bot is and how it differs from chatting, start with What Grok Bot is. For how to get it in the first place, see How you actually get Grok Bot.
