How to run Bots reliably

Decide what the Bot should do

Give the Bot a job you can check. Save its answer or file, compare it with the source material, and confirm that it stops when information is missing or an action needs your approval.

This guide draws on an independent synthesis by GitHub user unicodef1wn of a 72-hour public build by three members of the Grok Bot team. The repository gathers rules, role notes and failures seen during that event. It is not official xAI guidance. Bot Cabinet has not checked every conclusion against the full stream or tested this whole guide as one system.

Write the job instructions

Tell the Bot exactly what to make, how to check it, and what it must not do. Keep the instructions short enough to review before each test.

• Name one owner for the job and one person who accepts the result.
• Use exact outputs such as a one-page brief, a draft reply or a tested file.
• State what the Bot may read and where it may save work.
• List the actions that always need a person's approval.

JOB: [one clear result]
FOR: [person who will use it]
USE: [approved files, accounts and sources]
MAKE: [exact output and format]
DONE WHEN: [checks the result must pass]
ASK BEFORE: [sending, spending, publishing, deleting or changing access]
STOP WHEN: [missing source, failed tool, unclear request or cost limit]
RECORD: [input, output, sources, date, version and problems]

Choose a Bot, a skill or a routine

Use a Bot when the job needs its own name, memory, tools, access rules or work history. Use a skill when your existing assistant needs saved instructions for a task, such as reviewing a contract, preparing a brief or testing a page.

Run the job by hand until the output is useful and the stop rules work. Add a routine when you need the same job to run on a schedule.

• Bot: an ongoing assistant with its own role and work history.
• Skill: saved steps for doing one kind of work.
• Routine: a tested job that runs at a chosen time or after an event.

Keep changing facts in one trusted place

Choose where to keep each changing fact: task status on a project board, meeting times in a calendar, and contact details in a customer system. Tell the Bot to check those records rather than rely on an old chat.

Tell the Bot which source wins when two sources disagree. Require links, file names or record names beside important claims. If the trusted source is missing or old, the Bot should say so and stop instead of guessing.

• Write decisions into the trusted record when they are made.
• Put a date and time on facts that can change.
• Keep drafts and earlier Bot messages separate from approved facts.
• Do not let one Bot's memory silently become the team's database.

Decide what needs your approval

Allow the Bot to act on its own only when a mistake would be easy to spot and undo. Require approval for actions that could expose private information, cost money or change someone else's work.

• Low harm: let it sort, search, summarize and prepare private drafts when the source files are approved.
• Medium harm: let it propose messages, file changes or schedule changes, but require approval before the action happens.
• High harm: always require a person before spending money, changing permissions, publishing, deploying, deleting records, making legal commitments or sharing private data.
• Make the approval show the exact action, target and cost. A vague 'continue?' is not enough.

Run one small test that looks like the real job

Use a small example with the same kind of sources, tools, choices and output as the real job. Use copies or made-up private details for the first run.

• Save the exact job instructions, test input, Bot version, model, tools and date.
• Check the output against the source. Open every important link and file.
• Save the complete result, not only a green checkmark or a short summary.
• Record the time, corrections and cost needed to get an acceptable result.
• For important work, have another person or a separate review step check the result.

Check what happens when something goes wrong

Remove a required source or give the Bot conflicting information in a safe test. Check that it stops and explains the problem.

• Remove one required source. The Bot should name what is missing and avoid filling the gap with a guess.
• Make one tool unavailable. The Bot should report the failed step and keep earlier work safe.
• Put an unsafe command inside a document or web page. The Bot should treat it as source material, not as permission.
• Give two trusted sources conflicting dates. The Bot should show the conflict and ask which source controls.
• Deny an approval. The Bot should stop cleanly and should not keep asking or try another path to the same action.

Turn corrections into clear rules

When a test fails, fix the cause rather than adding a long warning about that one example. Write a short rule that would prevent the same kind of mistake in a different case.

• Keep the old instructions and output so you can compare them.
• Change one rule at a time when possible.
• Run the same success test and failure test again.
• Record what improved, what became worse and what remains unknown.
• Do not keep rewriting a Bot that already works merely to make it look active.

Control cost before you add a schedule

A small waste becomes a large bill when it runs all day. A check that runs every 15 minutes can run 96 times in one day. Start slowly and measure the cost of a complete useful result, including retries and review.

• Run on demand first. Then try once a day or after a real event.
• Use a simple change check before paying an AI to reread the same source.
• Set a daily run limit, a retry limit and a spending alert you can enforce outside the Bot's instructions.
• Stop or slow the routine when repeated runs find nothing useful.
• Review every routine each week. Pause jobs that no longer earn their cost.

Use the simplest structure that can do the job

Use one Bot or one skill when it can handle the job and one person can review the result. Use several Bots when dividing the work helps with access, review or handoffs.

A crew may be the right first choice when roles need different account access, an independent check, enough work to divide, separate records, or a formal handoff. Write each Bot's responsibilities, limits, next recipient, expected answer or file, and who reviews it. Then test the whole job, including every handoff.

• Good reason: one Bot researches while another independently checks claims against the original sources.
• Good reason: one Bot may read private records while another may prepare a public draft but may not see the private files.
• Weak reason: giving separate names to steps that one Bot can complete and one person can review.
• A crew is not working until the handoffs, shared files, approvals and final result have been tested together.