Grok Bot: always-on agent teams, and the credential problem the demos skip

The agent roster arrives

xAI has released Grok Bot, and the shape of it is more interesting than the model behind it. This is not one assistant in one window. It is a roster of persistent agents laid out like a messaging app, each with a name, a job title, a one-line description, and its own cloud computer. They run whether your laptop is open or not, they sync between desktop and phone, and they message each other.

It ships in beta on Mac and iPhone, with other platforms announced as imminent, and it is distributed jointly with Cursor, which is why setup runs through a Cursor plan and the Slack integration announces itself as the Cursor app. Pricing is reported around $120 per seat per month for teams, so this is squarely a professional tool rather than something to poke at idly.

We have spent enough time building agentic workflows to say the ergonomics here are a genuine step forward. We also think the most important detail in every Grok Bot walkthrough goes by in about four seconds, unremarked.

What Grok Bot actually provides

• A machine per agent. Each bot gets a persistent cloud environment: a real browser that keeps its logins, a file system, a terminal. You can take over the same session yourself, from a laptop or a phone, and the agent picks it back up. Close the lid mid-task and it keeps going.

• Recorded skills. Rather than writing a prompt, you perform the task once on the bot's machine and it is captured as a reusable, editable skill, runnable later like a slash command and shared across the whole roster.

• Routines on schedules and triggers. A morning briefing at seven on weekdays, or a run fired by a new message in a specific Slack channel or a repository event. Roughly what n8n gives you, set up in one sentence instead of fifteen minutes of wiring. The trigger list is short today and will obviously grow.

• Shared connectors. Authorise Gmail, Calendar, GitHub or Slack once, through the usual OAuth flow, and every agent can use it. Multiple accounts per service are supported.

Descriptions are the routing layer

Grok Bot's delegation model is elegant in its simplicity. Each agent carries a one-line description of what it is for, and agents scan those descriptions the way a model scans tool definitions. Ask an assistant bot about a marketing thread and it finds the bot whose description mentions Slack and media, messages it, and relays the answer back.

Two consequences follow. First, the description is not decoration, it is the routing key, so a vague one produces bad handoffs. Second, specialisation stops being a matter of taste. One agent doing twelve jobs gets confused; twelve agents doing one job each stay sharp, and the messaging layer stitches them together. Anyone who has structured work across sub-agents in a coding harness will find this immediately familiar.

Usefully, those inter-agent conversations are readable rather than hidden. If one bot asks another for something, both transcripts show it. An agent handoff you cannot inspect is a black box, and this one is not.

Skills that repair themselves

One reported behaviour deserves flagging. After running a recorded skill, a bot noticed its own procedure was ambiguous, could not reliably tell whether an item had already been actioned, and amended the skill definition to open each item first. Nobody asked it to.

That is a small thing with a long shadow. A workflow that edits itself after every run is either compounding quality or quietly drifting, and which one you get depends entirely on whether anybody reads the diffs.

The part the demos skip

Connectors are shared across the whole roster. Authorise Slack once and every bot, present and future, can read whatever that token can read: public channels, private channels, direct messages. The same holds for your inbox, your calendar and your repositories.

Convenience and blast radius are the same feature viewed from two angles.

Nothing here is negligent, and it is what most teams would build first. But an agent roster sharing one credential pool is the opposite of least privilege, and that becomes a real question the moment the data belongs to a client rather than to you. The controls that matter are per-agent scopes, an approval gate on outward actions, and a log you can audit. Grok Bot's current permission model is closer to "ask every time" or "always allow", which is a start rather than an answer.

How we think about this at Birdhouse

Our read is that this shape owns a specific slice of the day. Deep building work stays at the desk, in a harness where you pick the model and control the context. Grok Bot earns its place for the other half: triaging, checking in, drafting, reviewing, keeping things moving from a phone while the laptop is shut.

Three habits we would carry into any setup like it:

• Scope credentials per agent, not per account. If a media bot needs two channels, it should reach two channels.

• Gate anything outward-facing. Reading, summarising and drafting can run unattended. Sending, publishing and committing should not.

• Point agents at the source of truth early. One walkthrough produced an off-brand landing page purely because nobody told the bot where the brand assets lived. Context absent is context invented.

The right closing caution is the obvious one: build the agents your actual constraints demand. A roster of twelve bots solving problems you do not have is a very engaging way to get nothing done.