Why we are building BotBento around people, not just bots
Today's agent workspaces put one person in charge of many bots. The bots talk to each other; the person supervises. BotBento starts from a different unit: a room that people and bots both belong to, with the same scoped permissions applied to everyone in it.
AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. Editorial policy.
Key takeaways
- Grok Bot's own documentation describes group chats as two to six Bots, and sharing a Bot as handing someone a separate copy rather than joining them to your conversation.
- A workspace where only one human can be present makes the coordination between colleagues invisible to the tools doing the work.
- BotBento is pre-release. Mixed human and bot rooms are the design it is being built against, not a feature you can rely on today.
The assumption almost every agent workspace makes
Look closely at the current generation of agent products and you find the same shape underneath: one human account, many agents, and a supervisory relationship between them. The person delegates, the agents work, the person approves. It is a genuine improvement on typing into a single chat box, and it is not the shape most work actually has.
xAI's design write-up for Grok Bot is unusually candid about this, because it explains the reasoning rather than only the features. The team describes moving the product's main objects from disposable chat sessions to a persistent roster of Bots, giving each one an avatar, a memory and its own computer. It closes on the principle behind the whole thing: as agents take on more responsibility, the interface should ask less of the person.
That is a coherent goal, and it produces a coherent product. It also quietly fixes the number of people in the picture at one.
Sources: Designing Grok Bot for a world of persistent agents.
What the documentation actually says
This is not an inference from marketing copy. Grok Bot's own documentation describes creating a group chat by selecting two to six Bots, and recommends a group when several Bots need one shared outcome with visible handoffs. The design post gives the same picture from the other side: a group is where a designer, engineer, PM and data scientist Bot share project context while keeping their separate memories.
Sharing follows the same boundary. The documented way to give a colleague one of your Bots is to share it as a template, and the person who accepts it gets their own copy. The documentation is explicit that they do not receive your computer, your logins or your conversation history. That is a sensible security decision. It also means the thing you hand over is a clone, not a seat in the room you were working in.
So the collaboration in these products is real, and it is collaboration between agents. The multiplayer part, the one where two people and three bots are looking at the same thread, is simply not what they were built to do yet.
Sources: Message and collaborate, Frequently asked questions, Designing Grok Bot for a world of persistent agents.
Why that boundary costs something
Most work that is worth automating is already shared before any agent touches it. A launch has a designer and an engineer disagreeing about scope. A support escalation has one person who spoke to the customer and another who owns the fix. A newsroom has an editor who will not run a story until a second person has checked it.
If the agent workspace can only hold one of those people, the handoffs between them happen somewhere else: a group chat in another app, a comment thread, a call. The bot sees the instruction it was given and none of the conversation that produced it. Every time context crosses that gap, a person has to carry it by hand, which is exactly the coordination work these products set out to remove.
The alternative is not to give bots more autonomy. It is to stop treating the human side of the work as something that happens off-screen.
What BotBento is building instead
BotBento starts from the room rather than the roster. A conversation can hold people, bots, or both, and the same scoped permission model applies to everyone in it. A bot in a shared room works under that room's authority, not under a private transcript belonging to whoever invited it, and it cannot reach back into a personal history it was never granted.
That single decision drives most of the rest. Membership has to be real, so there are invitations and directories rather than account-local fixtures. History has to be governed by the room, so shared threads carry their own access grants. Execution has to be explicit, so enrolling a runtime, running work in a shared room and controlling a machine are separate approvals rather than one switch. Routines belong to the server rather than to a phone that might be asleep.
None of that is more elegant than the single-operator design. It is considerably more work. It is the bet that the room, not the assistant, is the thing worth getting right.
Where this actually stands today
BotBento is pre-release, and the project's internal rule is that a visible control or a passing test is not proof a feature works. So: mixed rooms, shared threads, reactions, drafts and routines exist and pass their own checks. Real-account, native-device and live-provider acceptance remain open. A private cloud environment with a maintained runtime is planned and not purchasable.
There is no access gate on any of this. The blog is public, the newsletter is public, and the field notes here will keep describing what is being built, including the parts that are not finished. When something becomes genuinely usable, that will be said plainly and dated, not implied.
If the argument in this article is wrong, the useful version of being wrong is specific: tell us which shared workflow you would actually move into a room like this, and which one you would not.
Primary sources
Sources checked 2026-09-20. Standards and product documentation can change; follow the linked version when implementing.
BotBento is in development. Suggest a correction.