Guide

Grok Bot for PMs: our templates, plus the official guide in brief

By Atlas AI Resources · Published October 16, 2026 · How we make these guides

Most product managers manage a product, not people. They work across design, engineering, data, marketing, and support, but nobody reports to them. This page summarizes how one PM runs a small team of Grok Bots that does report to the author: a chief of staff that keeps an “attention list,” an engineering manager bot that delegates to engineer bots, a data analyst, and a product sidekick. Then it adds our own fill-in templates for an attention list, a brief for an engineering manager bot, and a data question. In the guide, the PM keeps final review on external emails, purchases, and deletes, and we suggest you do the same.

It is based on the official guide Grok Bot for PMs (August 15, 2026) by Kevin Niparko, who works in product at SpaceXSI and used Grok Bot internally for a few months before launch. The workflows below are summarized in our words; read the guide for the author’s full account.

1. A team that reports to the PM

The guide starts from a familiar problem: the “mini-CEO of the product” has no one who has to listen to them. The author describes Grok Bot as a team of always-on agents with their own computer that can learn and amplify your work, so a PM can, perhaps for the first time, have a team of agents that reports directly to them and helps them ship. The author calls it the biggest change to their workflow this year, and is upfront that it comes with a learning curve.

2. Three PM use cases from the guide

• Priorities become an attention list. Weekly goals or priorities quickly go stale. Instead, the author’s chief of staff follows the author’s attention across Slack, email, meetings (Granola), and calendar, and keeps a short list of the projects the author is actually focused on, their current state, and what needs to happen next. Agents then use that list as a filter to point the author to relevant threads, and the author can compare stated priorities with where the time really went. The guide calls this “a new type of work primitive.”
• Research across customer context. The raw material for product decisions is spread out: recorded customer meetings in Granola and Gong, feedback in customer Slack channels, a user-research database, usage and subscription data in Databricks, support tickets in Plain or Intercom, and decision docs in Notion. Agents can synthesize across those sources to answer questions such as which recently onboarded enterprise customers use a feature, or where customers get stuck in the funnel. The setup step: enable plugins for the tools where customer context lives, and log in on the bot’s computer for any system that has no MCP server.
• Shipping software. The part that surprised the author most. Grok Bot agents can use Cloud Agents that run in an environment with the codebase, dependencies, secrets, and what they need to test their work. Instead of juggling many agent threads, a PM can give a bigger goal to one bot that breaks it down, hands parts to other agents, and reviews and combines what comes back. The author writes that Grok Bot “now represents a double-digit percent of our internal merged PRs.”

The guide gives three example requests for the attention list: one that sets it up as an hourly review of email, Slack, Granola, and calendar, and two follow-ups: archiving emails that don’t fit your focus, and asking where you spent time this week that an agent could take over. Our guide on Grok Bot for engineering covers a fuller fleet of engineer bots managing cloud agents.

3. The author’s bot team

• Chief of Staff. On the author’s calendar, Slack, and inbox; the only generalist, and it stays quiet when nothing changed. It owns the attention list. In the author’s example, it archives Gmail every hour unless a thread names the author and maps to the focus list, and when it sent calendar holds, it asked the author to pick a start time and then moved the hold to match.
• Engineering manager (named Emily in the guide). Does not code. It breaks technical work down, delegates to engineer bots, and checks their output against the goal. The author onboarded it by having it read a colleague’s Slack messages to learn what great looks like.
• Engineers (five of them). Each takes work from the engineering manager, runs Cloud Agents under the hood, tests and validates the output, and coordinates with the others. “It’s agents all the way down.”
• Data analyst (named Ashley). The bot the author uses most. It is connected to the data warehouse, tracks goals, reviews the dashboard every morning, and mostly answers in well-synthesized charts. Questions that used to go unanswered because asking was too much friction now get answered. The author is clear this does not replace the data science team: hard, ambiguous questions still need people with taste; the bot handles tactical questions and refreshes of earlier answers.
• PM Pete. A product sidekick for new ideas, research, feedback, and docs. One example: turning a Slack channel, thread, or DM debate about a feature into an RFC with P0–P2 priorities and quotes. It even helped with a hardware side project, researching a missing Raspberry Pi part, ordering it from Amazon, and explaining how to wire it up.
• Recruiter. Finds undiscovered talent and manages recruiting loops. Our Grok Bot for recruiting page covers that job in depth.

Emily, Ashley, and Pete are the author’s names for bots, not people. The chief of staff and the engineering manager both coordinate: one keeps the PM’s day in order, the other turns a goal into tasks for specialists and checks the result. The guide also shares a writing trick for the chief of staff: have it build a personal style guide from your sent mail and Slack messages, then read the exact thread before drafting, so replies sound like you.

4. Why not one agent?

The author calls this probably the biggest design question, and the author’s answer cuts against the single general-purpose chat box. The author splits work across specialized agents for three reasons:

• Referenceability: you know who does what.
• Parallelism: many agents work at once on separate tasks and coordinate on shared ones.
• Scoped memory: each agent learns different things on the job.

The author generally finds a named team more fun to work with. Our guide on small AI fleets and handoffs covers giving each stage a single owner.

5. The guide’s four lessons, in brief

• Named agents, separate memory. Each agent has a broad mission but memory scoped to its kind of work. The chief of staff should not be debugging evals, and the eval agent should not be archiving your mail.
• Agents learn on the job. They can learn from your past work, and you can keep teaching them. The author calls “Read my past Slack messages and develop a Slack style guide for me” the highest-leverage instruction the author has found.
• Agents shouldn’t be noisy. They bias to action but can over-communicate. Ask them to stay quiet unless something needs your attention.
• Human on the important stuff. For now, the author still sends most messages and edits most docs, both to “de-slopify” and because people want to know the sender thought the ask through.

6. Atlas’s advice: three fill-in templates

What follows is Atlas’s own advice, not the guide’s. Adapt the wording to your team and your tools.

Atlas’s advice: an attention list entry

Ask your chief of staff bot to keep one entry per project, link the thread or meeting behind each line, and write “no new signal” rather than guess:

• Project: ____ (one line).
• Why it’s on the list: where your attention showed up (channels, threads, meetings), with links.
• Current state: ____ (as of the latest source, with its date).
• Next step and owner: ____.
• Waiting on you: ____ (reviews, decisions, replies).
• Stated priority? yes or no, so you can see the gap between plan and practice.

If the list is used as a filter for archiving, start with the bot suggesting what to archive, or labeling instead, until a few weeks of its picks match yours. A thread being off your list today does not make it safe to hide.

Atlas’s advice: a brief for an engineering manager bot

• Goal: ____ (the user-facing outcome, not the tasks).
• Done looks like: ____ (what you will check, such as screenshots, a test, or a demo link).
• Out of scope: ____.
• Split: the bot proposes tasks and which engineer bot owns each, before work starts.
• Stop points: ask before merging, changing production, or touching secrets.
• Report back: what shipped, with proof, plus what it checked against the goal and what is still open.

A merged PR is not the same as a solved problem. Judge the team by goals met with proof, not by how many PRs or agents it started.

Atlas’s advice: a data question

• Question: ____ (one sentence).
• Metric definition: ____ (how it is counted).
• Time window and segment: ____.
• Source: the table, query, or dashboard used, linked.
• Answer: one chart plus a two-line takeaway.
• Caveats: missing data, small samples, or anything it couldn’t check.

A clean chart can still be wrong. Spot-check new kinds of questions against a number you already trust before you share the chart with anyone. For ready-made prompts, see weekly status update for turning the week’s notes into an update, and the anti-slop pass for keeping drafts in your voice.

7. Keep sends, purchases, and deletes behind your yes

The author keeps final review for any external email send, any purchase, and destructive actions such as deletes. Grok Bot’s guardrails are plain-language rules checked by a review agent, not code. The 101 guide puts them in Settings > General > Agent, with allow and block lists steering the reviewer. The current docs call this Settings → General → Auto-review: Ask first rules always stop matching actions for you, and Allow automatically rules let matching actions proceed only when the automated review does not identify another reason to stop. Auto Review is model-based, so the docs say to use it alongside least privilege and explicit approval boundaries, not instead of them. Our advice: spell out each bot’s stop points (“draft only,” “ask before any purchase,” “suggest, don’t archive”). An approval controls the action it is attached to; it does not undo work already done.

Our advice: all of your bots share one computer, and the 101 guide notes that a login one bot uses is reachable by the others. If any bot can reach a store login, any bot could technically buy, so decide up front which bot may place an order, and require your yes first.

Our advice: PM bots read a lot of text written by other people: customer Slack channels, support tickets, call transcripts, and feedback. Any of it can contain instructions aimed at your bot, so treat that content as data to read, not orders to follow. Our guide on keeping AI agents safe from prompt injection covers this in more depth.

General architecture advice, not a description of how Grok Bot works: if you also run your own scripts against your warehouse, repo, or email, enforce hard limits such as read-only credentials, protected branches, and spending caps with exact checks in that code.

8. Our advice: where to start

• Start with one read-only job. An attention list or a data analyst that answers questions in charts is a low-risk first bot because it reads and reports. Add actions like archiving later.
• Connect sources read-only first, then add write access one system at a time.
• Have it build your style guide early, and keep messages as drafts while you note each correction as a standing rule.
• Save what works as a skill, then schedule it. An hourly attention list is a routine that runs often, so consider limiting it to working hours, and use safe inputs for the test run, since a test run does real work. Our guides on skills before routines and scheduling AI agent routines walk through this.
• Add the engineering manager and engineers once you have a repo and an environment the agents can test in, and give each new bot one lane.
• Judge it by finished work: questions answered, RFCs you would actually circulate, and goals shipped with proof, not how many messages the bots sent.

Read the author’s full account in Grok Bot for PMs.

Useful public resources

Related: Grok Bot for engineering · Grok Bot for recruiting · Grok Bot for SDRs · Small AI fleets: handoffs · Skills before routines · Keeping AI agents safe from prompt injection · Complete Grok Bot setup guide · Grok Bot for Work · Grok Bot for design · Running multiple teams of Grok Bots