This article explains Grok Bot's shift away from relying on its own models toward using external models such as Claude Opus 5.5. Grok Bot acts as the "harness," managing computers, logins, memory, and recurring tasks, while Opus 5.5 handles the reasoning. The article proposes using this combination to build specialist bots and automated routines, while maintaining strict, human-defined boundaries around data access and external actions.

1. Separating the Model from the Harness

The article explains that agents have generally bundled a model and execution environment from the same company. The harness is the computer, logins, memory, and routines an agent uses; the brain is the model making judgments and doing the work inside it.

According to the article, late on October 6 in the United States, Elon Musk posted on X that SpaceX would use whichever backend model best suited each task. Models and services mentioned included Claude Opus 5.5, Midjourney, and Suno. Musk described the selection criterion:

"We will use whatever is most likely to give the best results."

The article says that a few hours later, Lauren from the Grok Bot team clarified that all bots were powered by Opus 5.5 and could also launch cloud agents using Cursor models. On October 7, 9to5Mac reported the changes.

The article's central interpretation is that Grok Bot retained its harness while adopting an Anthropic model as the brain inside it. It cautions, however, about performance comparisons: the Grok model compared in Artificial Analysis data is Grok 4.6, and it was not measured at the same time as Grok 4.7. Even so, the article emphasizes a substantial gap on Terminal-Bench, which evaluates multistep agent tasks.

2. How Grok Bot Works and Creating Your First Bot

According to the article, Grok Bot is an app for Mac, iPhone, and iPad, rather than a browser tab. Users sign in with a Grok or Cursor account. It is described as included in some SuperGrok and paid Cursor plans rather than as a separate product.

The interface resembles a messaging app more than a chatbot: named bots appear on the left and conversations on the right. Each bot has its own cloud computer. If the Grok Bot team's explanation holds, Opus 5.5 is the default for every bot, so users do not need an additional Claude subscription or to switch models themselves.

The article recommends starting with one general-purpose bot called Chief, instead of creating many specialists immediately. Send Chief tasks when you do not yet know which specialist should own them. It also advises testing reliability with a small, real task whose result you can check in 30 seconds, rather than assigning something large from the start.

A prompt is a one-off request; a bot is described as something that holds a role, accumulates memories, and manages a domain of work. Thus it recommends job-oriented names such as Inbox Manager, Research Lead, or Sales Outbound, rather than merely asking it to answer questions.

3. Write a Charter Defining Roles and Authority

After creating a bot, define its role as you would brief a new employee. The article recommends specifying three things in its charter: what it owns, what a good result looks like, and when it must stop and ask a person.

It stresses that Opus 5.5 may handle longer tasks than the previous default model, but that should not mean broader authority. It describes Opus 5.5's API as supporting a one-million-token context window and up to 128,000 output tokens, while noting that the extent to which Grok Bot exposes these capabilities has not been disclosed.

Its research-bot example instructs the bot to find primary sources for a topic, open and verify pages it intends to cite, cross-check numbers against at least two sources, and write a 1,500-word report. Every number should have an adjacent link. Conflicting sources should be flagged rather than averaged. The finished document should be saved to a Drive folder instead of left in chat.

External publishing and email sending are prohibited, and the bot must stop and ask if it cannot resolve a discrepancy between two sources. The article's principle is clear:

"A smarter brain should take on more steps, not more permissions."

4. Limit Connected Services and Data Access

The article describes a panel for connecting plugins such as Notion, Slack, Google Drive, AWS Agents, AWS SageMaker, Browserbase, Composio, and Context7. Connections are account-wide: connect Gmail once, and newly created bots can use it too. This is convenient but can broaden what bots can access.

It also points out that data used by Opus 5.5 is sent to Anthropic. It says questions about opting out of data sharing under Musk's post remain unanswered and that SpaceXAI has not published terms explaining what is shared. The advice is therefore to limit what bots can open, even if users cannot choose where the model runs.

Every bot's charter should prohibit opening, reading, or summarizing legal and finance folders; emails from lawyers, accountants, and banks; and messages containing passwords, seed phrases, or two-factor authentication codes. If a task needs such information, the bot should stop and ask first. When handling documents, it should use only what the task requires.

"During the beta, every connection reaches every bot, and now multiple companies—not just one—process the data."

5. Services Without APIs and Safe Login

Much real-world business software has neither an API nor an MCP server. The article introduces a cloud browser with a user login handoff as a way for Grok Bot to work with these services.

The bot navigates in a cloud browser and hands the screen to the user when it reaches a login page. The user signs in personally and clicks Done; the bot then continues in the same browser session. This gives the bot an authenticated session rather than a password in chat.

The article emphasizes not pasting passwords into conversations, especially when an external model participates in the work.

"If any tool asks you to paste a password into a message, that is the wrong path."

6. Demonstrate a Task Once and Create a Recurring Routine

You can also teach a procedure by showing the bot the task once. As the user performs it on screen, the bot saves the steps, then executes them independently next time. The article recommends starting with work that repeats weekly, spans at least two apps, and has a stable procedure—something cumbersome to explain but quick to demonstrate.

It says routines can be scheduled or given triggers in natural language without a complex workflow builder. For example, at 7 a.m. on weekdays, a bot could check the calendar, inbox, and Slack's #launches channel and briefly summarize the day's schedule, items needing replies, and overnight changes. Or, when an email mentioning pricing arrives from a domain not in the user's contacts, it could draft a reply from a template and save it.

Another approach is to say, "Run this every week," after a task produces a good result. According to the article, Opus 5.5's strength is a greater likelihood of adapting and recovering when a website layout or input format changes and disrupts a routine.

7. Use Multiple Specialist Bots and Cursor Agents

The article recommends running domain-specific bots in parallel instead of assigning everything to one bot. Separate memories and context make it easier to identify where problems occur. It says SpaceXAI internally uses bots for sales outreach, marketing, office operations, and bug fixes. It also recommends dividing by domain, not task size. An Expense Manager handling only receipts, for example, can become familiar with that user's receipt-processing needs.

Another capability is launching cloud agents that use Cursor's different models. The article describes an Opus-powered bot planning the work and managing context, Cursor agents doing the coding in parallel, and the bot reviewing their results. It mentions SpaceX's acquisition of Cursor in a $60 billion deal in August as background to the connection.

Its example workflow begins with a GitHub issue labeled as a bug. The bot reproduces it, writes a failing test, asks a Cursor agent to fix it on a new branch, and runs the full test suite. It opens a draft PR containing the fix, tests, and a three-line summary, but does not merge or push to main. Changes involving authentication, payments, or database migrations are handed to a person.

The article says bots can also message one another to divide work and share context. In a SpaceXAI example, one engineering bot reproduces a bug and creates a ticket, then transfers the task to another bot better suited to debugging. This transfer of responsibility between bots is presented as a distinction from a single conversational tool. Since late September, teams have also reportedly been able to publish shared bots for colleagues to use in the app or Slack.

8. Give Group Bots a Goal Rather Than a Task List

For multiple bots in one group conversation, the article recommends a shared goal instead of a detailed task list. A list means the human has already divided the work; a goal lets bots break it down and assign suitable roles themselves.

For example, the goal could be, "Launch the October newsletter by Friday at 5 p.m." Research Lead owns facts and sources, Inbox Manager handles subscriber replies, and Chief manages the schedule and blockers. Let bots divide the work themselves, but require human review before anything is published externally.

9. Distinguish Reversible Work from Work Requiring Approval

Grok Bot's basic idea is that bots carry work through to completion and return only when human approval is needed. The article therefore stresses that people must clearly define what bots may do without approval.

The criterion is reversibility, not task size. Let bots perform and log easily reversible work such as drafting, classifying, summarizing, researching, preparing, and cross-checking. Escalate messaging people outside the company, spending or moving money, committing to prices, publishing, deleting important files, accepting terms, and signing up for services.

"If it cannot be undone within one minute, stop and ask."

The ideal state, according to the article, is a plentiful collection of drafts with nothing sent externally: complete every reversible step, then stop firmly just before an irreversible action.

10. Check Costs and Availability, Then Review Regularly

The article says Opus 5.5 is not a cheap model. Using API pricing, it gives an example of a small task with 30,000 input tokens and 8,000 output tokens costing about 28 cents on Opus 5.5 versus 11 cents on Grok. At very long context lengths, however, the relationship can reverse: the article says Grok's rates double above 200,000 tokens while Opus's remain flat.

Grok Bot includes usage in a plan rather than charging users directly per token, but the article says SpaceXAI has not disclosed whether Opus tasks consume plan limits faster. It advises observing usage during the first week before adding more routines.

Not every announced feature is immediately available. There is no availability schedule for Midjourney or Suno, and the article reports that one user's bot said it could not use Suno on launch day. It therefore recommends starting with confirmed Opus 5.5 functionality and waiting for actual availability of the rest.

Finally, it recommends a 15-minute weekly review in which bots report their work: how often each routine ran, what it produced, what it skipped or failed at, which judgments were guesses, and which escalations still await a human response. Because bots may have blind spots in evaluating themselves, a person should inspect one output from each routine.

The conclusion is that competition is shifting from simply selecting a model to the importance of the harness, the environment where that model works. Define the work, the limits of authority, and accessible data in a charter, then let a stronger model operate within those boundaries.