Run a Business Grok Bot While Your Computer Is Off

About this guide: it is based on Grok Bot's published documentation, checked in October 2026, and a constructed example. It does not report a tested run or a measured cost.

Decide what should be waiting in the morning

An owner closes the laptop after preparing a useful bot demonstration. The next morning, someone expects a new report. Nothing arrives because the demonstration depended on a file stored locally, an open session or an approval nobody could provide. The missing piece is a complete operating arrangement, not a more enthusiastic instruction to keep working.

Start with the deliverable. A modest first job might prepare a private note identifying which approved supplier notices require a person's attention. The bot reads a short list of permitted public pages, records what it could establish and saves a draft. It does not contact a supplier, accept terms, alter orders or announce that the business has complied with anything.

This article uses that constructed example to show what needs to be in place. It does not report a completed unattended run. Documented platform capability and evidence that one business workflow works are different things.

Separate the service from the particular starter

The product documented at docs.x.ai is called Grok Bot. Its guidance describes a persistent cloud computer that can use files, a browser and connected tools. It says cloud work can continue when the local app or laptop closes. That describes the service's intended behaviour, not a guarantee that every dependency in your job is reachable. Use the computer and apps.

If you begin from a published starter or template, treat it as separate from the service: it is the particular set of instructions, files and connections used to deliver your example. Record its publisher, source location and version. Do not substitute a similarly named repository found in a search, or assume that an older copy of your instructions is the version in use. Two projects with the same name can have different permissions and operating assumptions.

The documentation provides a starting route for creating a Bot with a focused job and giving it a task. Before following any installation or connection step, check the current official instructions and your organisation's permissions. This article does not prescribe an installer, account change or plan; the Get started page lists the eligible plans and requirements. Get started.

Make the cloud dependency chain visible

Write down where each part of the job lives. The source list and job instructions must be available to the cloud execution environment. The result must be saved somewhere the reviewer can open later. Any required access must work without borrowing a session that exists only on the laptop. A local shortcut in a prompt is not evidence that the cloud can read its target.

Keep a simple source map with the job. For each input, name its owner, location, permission and acceptable age. For each output, name the destination, intended reader and retention requirement. If an item cannot be reached, the run should report that gap. It must not quietly replace an approved source with a convenient search result.

The provider documentation says Bots on an account share the cloud computer, including files and signed-in sessions. Separate Bot names therefore do not create separate access boundaries. Review what the whole shared environment can reach before adding a connection. A narrowly worded role helps explain the task, but it does not isolate credentials technically. Use the computer and apps.

For the first pilot, use public or wholly invented inputs wherever possible. Do not copy employee records, customer exports, passwords or internal commercial material into the example simply to make it feel realistic. The business question can often be tested with a small fictional source pack while the organisation settles access and information-handling requirements separately.

Define a useful job before making it recurring

The fictional business is a small Australian supplier of workplace equipment. Its operations coordinator wants a draft supplier-notice review at 09:00 Australia/Sydney on selected business days. Three synthetic notices are supplied for the example: a changed collection window, an unchanged ordering page and a notice that cannot be retrieved. None represents an actual supplier announcement.

The bounded task is to compare each available notice with its recorded previous version and explain the difference. The expected draft identifies the changed collection window, records no difference for the ordering page and labels the third source unavailable. It must not infer a delivery commitment, calculate commercial exposure from missing information or reassure the reader that every supplier was checked.

The coordinator owns the next decision. They check the source and decide whether the collection change affects an order. The bot's output supports that review by keeping the original wording, retrieval status and source reference visible. It does not change an order or message another person. The private draft remains useful even when it ends with an unresolved question.

Give the job a stable reference and record the input version used for each run. A new run also needs its own identifier and timestamps. That lets a reviewer distinguish a current result from an older file with a similar name. These are proposed recordkeeping conventions for the example, not claims about fields automatically supplied by the product.

Test the method once, then the timing

Grok Bot's routines documentation distinguishes instructions for doing a task from the trigger that starts recurring work. It recommends making a one-time task reliable before automating it. Follow that sequence: first check whether the source-to-draft method works, then test the schedule and unattended access. Skills and routines.

For the one-time test, give the bot the constructed notices and the expected output format. Compare every statement with the supplied text. Confirm that the unavailable source stays unavailable and that the draft does not add a promise. Check the saved result by opening it from its destination, rather than relying only on the bot's completion message.

Only after that review should an authorised operator configure a recurring run. State the timezone and intended date clearly, then read back what the system actually saved. Do not assume that a natural-language request resulted in a schedule. A conversation about tomorrow's work is not proof that tomorrow's trigger exists or will have access to the inputs.

The timing test needs fresh evidence. Arrange an authorised future run after the authoring computer is off, and record the input available to that run. Afterward, inspect the routine's run history and retrieve the resulting file. The documentation says the app keeps only the 20 most recent run records for each routine, so copy the record you need into the job file. A draft generated before shutdown cannot prove that new work happened without the computer. Neither can a screenshot of a saved schedule.

Plan the missing-source case in advance

An unattended job will eventually encounter something it cannot finish. In the constructed example, one notice is deliberately unavailable. The expected result names the affected source, reports that the comparison could not be made and keeps the prior text labelled as prior, not current. It must not label the old result as current or describe missing evidence as no change.

Test that behaviour using a controlled fixture or an approved test destination. Do not damage a live supplier page or revoke production access merely to demonstrate a failure. The failure exercise should reveal whether the bot stops, records the limitation and brings the right person a useful exception. It should not create the business incident it is meant to prevent.

Authentication can also interrupt work. The provider's guidance describes human takeover for sensitive sign-in steps and approval boundaries for consequential actions. Keep those checkpoints in the design. The same page says an approval requested by work that started without you, such as a routine, expires after about 30 minutes and the action does not run, so plan for the run to end in a recorded hold. A workflow that pauses correctly for required approval has not demonstrated uninterrupted completion, but it may have demonstrated the intended boundary. Approvals, security, and privacy.

Write the handover so the reviewer knows what can resume and what needs a new decision. For example, the coordinator may confirm a replacement source for the next run while the current draft remains incomplete. Record the change to the source list instead of allowing the bot to broaden its search silently. That preserves the reason the next run behaves differently.

Keep retries from obscuring what happened

If the output cannot be confirmed, check its destination before starting again. A timeout may mean nothing was saved, or it may mean the response was lost after the write succeeded. The right next step depends on that evidence. Repeating a job immediately can produce two drafts that look like separate observations of the same period.

For this example, retain one run record per attempt and associate the saved draft with that record. An intentional rerun should identify which earlier attempt it replaces. The reviewer can then see whether the new output used new inputs or only repeated the same ones. This is a proposed operating convention, not a claim of built-in duplicate prevention.

Keep the pilot's permissions narrow enough that an uncertain draft save cannot also mean an uncertain external message or order change. If the business later wants the bot to prepare those actions, keep a person's approval on each message, order change, purchase or access change, and treat it as a separate scope with its own reconciliation method. Reliability in producing a private note does not establish reliability for every action that could follow it.

Measure costs over useful results

The provider FAQ describes account-dependent access and usage arrangements. It is not evidence of the balance or price available to your particular account. Check the current access and billing information before running a pilot, including whether additional usage can be charged. Do not infer unlimited unattended operation from an existing subscription. Frequently asked questions.

Keep a pilot cost sheet with separate entries for included allowance consumed, incremental provider charges, other service costs and review time. Record the currency shown by the provider and the measurement period. If you present an Australian dollar estimate, retain the dated exchange-rate source and distinguish that estimate from the actual billed amount.

Divide measured pilot cost by the number of usable reviewed outputs only when both values are known. A cheap run that produces an unsupported conclusion is not a useful result. Include failed and repeated attempts in the total so the estimate reflects the operating method being proposed. Do not turn a single successful example into a confident monthly forecast.

The constructed example has no measured costs or observed outcomes, so those cells stay blank in the worksheet until your own pilot fills them. Before activation, the owner must set a permitted spending boundary using the actual account controls and available evidence. A blank budget field is not permission for the bot to continue spending.

Give someone ownership of the next morning

Name a reviewer and a backup before making the job part of the business routine. They need to know when a result is expected, where to find it and what an exception means. A missing report deserves a different response from a completed report awaiting a commercial decision. Use the work state to explain the next action without monitoring anyone's personal activity.

Review the routine after a small, agreed pilot period. The documentation also says Grok Bot may pause routines after a long period away if nobody answers its prompt, so check for paused routines when the owner returns. Check whether the sources remained available, exceptions reached their owner and the drafts were worth reviewing. Where the process creates repeated ambiguity, reduce the task or improve the inputs. Adding more bots is not a remedy for an unresolved source or unclear decision boundary.

The first useful unattended workflow is a modest promise kept with evidence. Choose a bounded private deliverable, establish where its dependencies live and test a fresh run after the authoring computer is off. Retain the missing-source case and the actual cost record. Then decide, as a person responsible for the work, whether the result is ready to become routine.

Start with this job specification

Prepare a private supplier-notice review from the supplied synthetic source pack only.
Compare the current and prior text for each approved source reference.
Return source reference, observed change, retrieval status, uncertainty and reviewer question.
If a source is missing, say unavailable. Do not infer no change or replace it silently.
Do not use personal, customer, employee, confidential or credential data.
Do not send messages, publish, purchase, change orders, accept terms or change access.
Save only to the named private draft destination authorised for this test.
Report the actual saved output reference and inputs used. Do not claim approval or publication.
Stop for missing authority, required human authentication or an unset spending boundary.
The coordinator checks original sources and owns every commercial decision.

Use the source pack, readiness checklist and cost worksheet that accompany this article. They are constructed test materials, not a cloud deployment or a passed test.

Cloud bot job: reusable materials

Version 1.0. All scenario data below is invented. The source labels are fixture identifiers, not URLs of real supplier notices. No actual cloud run, source fetch, operational approval or billing observation is represented.

Fictional operations brief

Private Australian workplace-equipment supplier. Responsible role: operations coordinator. Desired result: a private supplier-notice comparison draft, for human review. Proposed time: 09:00 Australia/Sydney on operator-selected business days. A schedule has not been created. Commercial decisions and external communications remain human-owned.

Supplied source pack

No real operating dates or suppliers are implied. A live test would need genuine approved source locations and retrieval records.

Expected draft, constructed rather than observed

Run: [RUN_ID]; source pack: [VERSION]; observed start/end: [UNKNOWN UNTIL TEST]
S01: collection window differs from 09:00-11:00 to 10:00-12:00.
Limitation retained: confirm collection with the supplier.
Reviewer question: does any planned collection require a human follow-up?
S02: no textual change in the supplied current/prior versions.
Limitation retained: availability confirmed separately; no delivery commitment inferred.
S03: unavailable. Current comparison not completed. Prior notice is not a current result.
Overall state: draft with source gap; human review required.
External actions: none authorised.
Saved output: [ACTUAL DESTINATION/REFERENCE TO BE RECORDED AFTER TEST]

Ready-to-use prompt

Prepare one private comparison draft from only the supplied approved source pack.
Allowed inputs: source references, prior/current supplied notices, retrieval status and this brief.
Exclude all personal, employee, customer, confidential and credential data.
For each source, state the exact observed change, retained conditions, retrieval status and reviewer question.
If an input is missing, say unknown or unavailable. Do not infer no change or replace a source.
Do not make commercial decisions, confirm orders, send messages, publish, buy, accept terms or change access.
Save to only the operator-authorised private test destination.
Return the actual saved reference and inputs used; never invent a run, save, approval or publication result.
Stop for missing permission, human authentication or an unset spending boundary.
A human operations coordinator checks originals, confirms relevance and decides the next action.

Cloud readiness checklist

• [ ] Confirm the actual starter publisher, source location and version.
• [ ] Document the authorised private task and excluded actions.
• [ ] Verify input access from the intended cloud environment.
• [ ] Identify the output destination and test reviewer access.
• [ ] Set a spending boundary using supported account controls.
• [ ] Run the one-time source-to-draft test and inspect the saved result.
• [ ] Read back any authorised schedule, timezone and trigger.
• [ ] Run fresh work after the authoring computer is off.
• [ ] Retain run identifier, input version, start/end times and output readback.
• [ ] Exercise an unavailable-source case without changing production access.
• [ ] Confirm missing/old evidence is not reported as current or complete.
• [ ] Reconcile any uncertain save before a retry.
• [ ] Name the reviewer, backup and exception route.

Job record template

Job reference / owner / backup:
Starter source and version:
Authorised task / prohibited actions:
Approved input list and acceptable age:
Output destination and reviewer access:
Trigger / timezone / saved schedule evidence:
Spending boundary and enforcement evidence:
Run reference / input version / start / end:
Output location and readback result:
Unavailable sources:
Human decision needed:
Retry relation to previous attempt:
Approval evidence: pending until supplied

Pilot cost worksheet

Calculate cost per usable reviewed output only when the numerator and nonzero denominator are known. Keep original-currency amounts separate until conversion is supported. No spending limit, zero-cost claim or monthly forecast is invented.

Related reading

• The Leader's Case for Slowing an Agent Down, on where a person keeps the checkpoint in agent work
• AI Agents Just Went From Minutes to Hours. The Control Point Is Where They Run., on governing long-running agents by where they execute
• Run a Grok Bot in the Cloud for Your Business: A Plain-English Setup Guide, the step-by-step setup guide with invented starter files
• How Does a Hybrid Team See What Its Bots Are Doing?, the companion article for 11 November

References

1. xAI: Grok Bot, Use the computer and apps
2. xAI: Grok Bot, Get started
3. xAI: Grok Bot, Skills and routines
4. xAI: Grok Bot, Approvals, security, and privacy
5. xAI: Grok Bot, Frequently asked questions
6. Cursor: Grok Bot plans and billing

General information only. Not legal, compliance, financial, or professional advice.