Original video in Chinese.
Key Takeaway
- Grok Bot is centered on Bots rather than Chat: for the same kind of need, you keep going back to the same Bot, and context accumulates over time. Bots can also message and collaborate with one another, which is the biggest difference between it and products like Codex, and the source of that “alive” AI employee feeling.
- Two classic ways to collaborate: chaining (a pipeline, where one Bot completes a step and hands it off to the next) and parallelization (splitting tasks up and sending them to different Bots at the same time). Usually there is one central control Bot (like CHIEF) responsible for splitting, assigning, collecting, and delivering, with conditional branches added when needed.
- Don’t create a group chat unless necessary: group chats are suitable for situations where alignment is needed and everyone must see all the information; one-to-one messages are lighter. Too much information increases the context burden on every Bot. In most cases, “one central controller + a group of underlings” is enough.
When using Grok Bot, you can first set up Bots around stable responsibilities, and then have one central controller handle task splitting and result collection. Use chaining when there are clear upstream and downstream dependencies, parallelization when tasks are independent, and group chats only when shared alignment is truly needed. What I’m recording here is my own way of using it; the key is to make every handoff’s input, output, and reviewer clear, rather than creating as many Bots as possible first.
The biggest difference between Grok Bot and other Agent products, such as Codex, is that it is centered on Bots rather than Chat.
In other words, you no longer create one chat window after another; for the same kind of need, you keep talking to the same Bot again and again.
And because they are Bots—robots—they are no longer “dead” chat windows. They can collaborate with each other, and the potential is enormous.
In this episode, I’ll explain some of the basic ways to use Grok Bot in detail. Over the past few days, I’ve been posting these topics in the Knowledge Planet newtype. Some friends have already started using it. If you also want to discuss and learn together with others, you’re welcome to join our community.
Once you start using Grok Bot, you’ll quickly discover the first little surprise: Bots can actually send messages to each other!
For example, I tell one Bot: go tell the other Bots that from now on, when replying to me, they should keep things as simple and easy to understand as possible, and there should be no spaces before or after English letters and numbers, and punctuation should be in Chinese format (unless it’s English content). Then this Bot will send a Message to the other Bots to pass along that information and have them carry it out.
You see, this is the biggest difference between Bots and Chat—they are “alive.” Not only can they execute on their own, they can also collaborate with each other.
So, I created a Bot called CHIEF. Most of the time, I chat with it. It decides who should handle the task. Only when the requirement is very specific—say, something investment-related—do I go to the corresponding Bot.
Once you understand this, a whole new world opens up. Since Bots can message each other, you can use the following two classic collaboration patterns.
The first is chaining. That means, like a production line, one Bot completes one step and then passes it to the next Bot.
The second is parallelization. That means you do the splitting up from the start, then send the subtasks to different Bots to execute at the same time.
Both of these collaboration methods are managed by one Bot acting as the central controller, such as CHIEF on my side. It is responsible for splitting and assigning, and also for collecting and delivering.
On top of these two, you can design more complex workflows depending on the situation, such as various conditional branches, with the Bot deciding for itself which route to take.
At this point, some friends may ask: why not just create a group chat and be done with it? Why make it so complicated?
One-to-one messaging and group chats are completely different things, because the context visible to the participants is different.
Think back: in a company, when do you create a group chat or have everyone attend a meeting together?
When alignment is needed.
That is, everyone has to know all the project information and all the progress, including what others have done and how things are going. It works the same way with Bots.
But you can’t run every project like this. Because the amount of information is too large, every colleague would be exhausted, and during the meeting they’d definitely be cursing inside. Likewise, for Bots, once you create a group chat, the context burden becomes heavy too.
So the basic principle is: don’t create a group chat unless necessary.
In most cases, one central controller with a group of underlings, using either chaining or parallelization, is enough.
In these last two pieces of content, the previous one was an overall introduction to Grok Bot, and this one is about concrete usage ideas. Once you understand it, you’ll know how to incorporate this product into your personal sovereign AI system.
Messaging and group chats, chaining and parallelization—putting these together really has enormous potential. I also said in the Planet that right now the official Marketplace only shares individual Bots, but later they may add entire collaboration networks as well, and that would be amazing! If I discover more later, I’ll continue sharing inside the Planet.
OK, that’s it for this episode. If you want to understand AI, want to reclaim individual sovereignty, and want to find like-minded people, come join the newtype community. See you next time!
How to Make a Bot Collaboration Verifiable
The checklist below is organized from this article’s practices for central control, chaining, and parallelization. It is a workflow suggestion and does not mean the product guarantees it automatically:
| Handoff item | What to make clear | How to check |
|---|---|---|
| Task | What problem this run is meant to solve | The subtasks did not expand into something else |
| Input | Which materials and which context can be used | The receiver really got the materials |
| Output | The file, conclusion, or options waiting for confirmation | You can open the actual output, not just see a “done” message |
| Boundaries | What not to do, and where to stop and confirm | Nothing was published on its own, permissions changed, or scope expanded |
| Collection | Who consolidates, who decides it is finished | The central controller checks for conflicts and omissions |
Chaining is suitable for workflows with upstream and downstream dependencies, such as “collect → verify → write draft”; parallelization is suitable for independently sourced materials. Before multiple Bots write the same file, you should first isolate the outputs or designate a single merger. Message delivery, task execution, and result verification should be recorded as three separate states.
This article did not additionally test throughput, long-term online rate, or functional differences among accounts. The experience described in the original still corresponds to the practice at the time of writing; this checklist was organized on 2026-09-27, and does not disguise a maintenance date as a fresh product test date.
Continue reading: Two Practical Grok Bot Tips, Let Agents Automatically Gather Daily News, Wiki: Multi-Agent Orchestration.