Lauren Tan's Grok Bot Workflow: Chief of Staff, Cloud Agents, and pstack

Lauren Tan's Grok Bot workflow is a useful case study in moving from an individual coding assistant to a team of agents with clear responsibilities. The public evidence supports a concrete system: Bots gather context and route tasks, Cursor Cloud Agents execute engineering work, and pstack supplies reusable methods for implementation and verification.

The headline numbers need more care. Lauren has publicly reported shipping 1,000 PRs in a month. The often-repeated claims that she runs exactly “20+ GrokBots,” or that “85% of engineers run 10+ Bots,” are not established by the first-party materials cited here. A self-reported output figure, a product capability, and a company-wide adoption statistic are different kinds of evidence.

For developers, the useful question is how a task moves from a bug report to a change that someone can confidently review. That is where this workflow becomes practical.

Cover image: promotional artwork for the MTS interview with Lauren Tan and Roshan Sadanani. The original artwork includes photographs of the guests.

What Lauren actually reported

In her public post about Cursor's cloud-agent release, Lauren says she built pstack and uses Grok Bot routines to collect Slack bugs, complaints on X, and feature ideas. She describes this as feeding her “outer loop”: deciding what deserves engineering attention next.

She also reports using /goal, /loop, and /swarm with a Full Autopilot playbook, with work continuing on cloud agents while she is asleep or her laptop is offline. Her 1,000-PR figure belongs in this self-reported context; the post does not provide a repository-level audit of PR size, complexity, or business impact.

Lauren Tan's speaker photograph, as supplied on the Maven workshop page.

Two videos explain different parts of the system

The 60-minute Maven workshop, How Cursor Turned AI Agents Into Better Engineers, is dated August 12, 2026. Its published chapters emphasize trust, verification skills, pstack, evaluations, refactoring, and CI. The Grok Bot segment begins at 55:58. Describing the whole session as a tutorial for assembling twenty Bots misrepresents its focus.

The MTS interview, also available on Spotify, is the more direct introduction to the team workflow. Useful points to inspect include:

In the bug-dispatch segment, she describes receiving PRs with screenshots and videos. Those artifacts make a useful handoff tangible: a reviewer has something to inspect beyond an agent's completion message.

Grok Bots coordinate; cloud agents execute engineering work

The clearest way to read the architecture is as two connected loops. The first discovers and defines useful work. The second turns a well-scoped task into a verified change.

AI IDE List's conceptual diagram, combining the public demo with the documented pstack workflow. It illustrates responsibilities rather than a literal export of Lauren's configuration.

The outer loop handles context and ownership. A recurring feedback scan might surface a reproducible export bug. A coordinator identifies the relevant feature owner, supplies the original report, and asks for the next action. The practical benefit is preserving the reason for the work as it moves between agents.

The inner loop handles execution. A coding agent receives the repository, the problem, acceptance criteria, and the required evidence. Implementation, tests, inspection of the running product, and PR preparation belong here. Cursor's August 19 harness update documents long-lived goals, cloud subscriptions, and subagents running in separate virtual machines.

A Chief of Staff is a coordination role, not a special root permission. The official Bot management documentation describes persistent roles and context, while collaboration documentation explains messages, groups, and handoffs. A useful coordinator needs to know who owns a task, which inputs are current, and what constitutes a completed handoff.

Keep the two computer models separate

The Grok Bot computer documentation states that Bots on one account share a cloud computer, including files and signed-in browser sessions. Separate Bot roles do not create separate credential boundaries.

Cursor's cloud subagents can use isolated virtual machines, according to the harness update. That is a different execution layer. When designing a team, specify both the logical owner of each task and where its files and credentials actually live.

What pstack adds to the workflow

pstack is listed in Cursor's official plugin marketplace. It packages engineering skills and playbooks for work that needs a repeatable method: deciding how to approach a change, implementing it, checking behavior, and handing off evidence.

The distinction between a role and a method matters. “Engineering Bot” says who owns the task. A verification skill says how that owner can demonstrate that the task is done. A repository-specific check might open the export screen, retry the same request, inspect the stored records, and verify that a duplicate was not created.

That example is an editorial suggestion, but it captures a useful design requirement: verification should observe the behavior that motivated the change. The pstack recipes and pitfalls guide explicitly warns against treating a successful build as proof of correctness.

Install pstack and run one bounded task

The current pstack setup guide specifies two commands in a Cursor chat:

/add-plugin pstack
/setup-pstack

Setup asks about model roles and writes the model configuration used by its skills. It also checks for an existing verification method and may offer to create a project-specific verification skill. Start a new chat after setup so the new model rule applies.

Then choose a real, small issue. Here is an original starter brief for an export retry bug:

/poteto-mode
Investigate duplicate exports when the same request is retried.
Repository: [REPOSITORY]. Reproduction: [STEPS_OR_ISSUE_LINK].

First reproduce the failure and identify where duplicates are stored.
Implement a focused fix and a regression check.
Verify a normal export and a retry in the running app.
Return the PR, the observed stored values, and the checks you ran.
Leave merging to me.

Replace the bracketed values with your project details. The important part is the acceptance condition: two attempts at the same logical export should produce the intended stored result. A screenshot can show the interface, while a data check establishes whether the duplicate is actually gone.

For the Grok Bot side, use the directory's setup walkthrough and connect only the inputs required by your first workflow. Nightly Audit Engineer and Researchy are useful places to inspect task-specific setup examples.

Understand /goal, /loop, and /swarm

These names describe capabilities from different parts of the stack. They should not be presented as three Grok Bot commands.

The ownership of /goal is explicit in the Cursor release notes. The pstack overnight guide identifies /loop as a Cursor capability. The swarm skill describes separate coverage assignments, competing attempts at the same task, and consolidated reports with evidence and unresolved gaps.

Parallelism helps when the work can be divided and checked independently. For example, three workers could exercise export behavior for a new request, an immediate retry, and a delayed retry. Their combined report should still state the exact application version and input conditions used by each worker.

Full Autopilot separates implementation from the merge verdict

The Autopilot-full playbook assigns one owner to each independent PR. That owner carries the implementation and its initial proof through the engineering workflow. Fresh verifier workers then inspect the merge-ready version, including live behavior and regression checks, before the root coordinator issues a verdict.

An owner cannot authorize a merge solely by declaring its own work correct. The playbook ties verification to the proposed commit, sends findings back for fixes, and requires a fresh verdict when a changed version invalidates the earlier result. Operator-reserved items continue to require the operator's action.

This also clarifies the permission model. Full Autopilot can include merging when the operator has granted that scope and the verification gate passes. It is not a blanket instruction to enable automatic merging on every project. A sensible first experiment is a review-ready PR with the final merge left to the human.

For your own workflow, ask the independent reviewer to reopen the actual branch, run the significant user journey, and describe what was observed. “The builder said the tests passed” does not add independent evidence.

A small team to start with

AI IDE List's suggested starting point is three responsibilities. These can become separate Bots as the handoffs become useful; they are not a claim about Lauren's exact roster.

Add a research specialist when finding the next task becomes a bottleneck. Add product or content roles when their outputs have clear consumers. An agent that produces a report nobody uses adds another queue for you to manage.

For an indie developer maintaining a SaaS, the first end-to-end run could be straightforward: collect one customer bug, reproduce it, prepare one fix, and have another reviewer test the retry case in the actual product. Evaluate the quality of that handoff before increasing the number of simultaneous tasks.

Make an overnight handoff reviewable

The overnight guide emphasizes a checkable finish condition, an isolated worktree, and a decision trail. A duration alone does not define success. “Work for six hours” leaves the agent without a useful completion test.

Here is an original handoff example for a bounded migration:

/poteto-mode
Migrate the callers in [PACKAGE] from [OLD_API] to [NEW_API].
Use a fresh worktree from [BASE_BRANCH].

Complete means:
- No old API calls remain in that package.
- The migration fixtures pass.
- The main user journey works in the running app.

Keep a decision log and preserve the observed test results.
You may commit and push the task branch. Do not merge or deploy.
Use /loop to revisit the completion checks.
If access or an unresolved dependency prevents progress,
stop and leave a clear blocker report.

On return, inspect the decision trail, the final diff, and the evidence for the completion criteria. Check whether any blocked source, missing fixture, or untested path was silently converted into an assumption. That review tells you what needs improving before the workflow earns more autonomy.

Measure the result you actually care about

PR count is an incomplete success measure. A more useful record for your own experiment includes the number of accepted fixes, review time, rework after review, escaped defects, and usage cost per accepted change. Those measurements make it possible to decide whether another worker improves throughput or simply produces more review work.

Lauren's public workflow offers a concrete pattern to borrow: preserve the context behind a task, give it an owner, encode how correctness will be checked, and keep the final handoff inspectable. Expand the team when those handoffs work reliably.

To explore the surrounding ecosystem, browse the Grok Bots developer directory, our Grok Bot introduction, and the marketplace guide. For the source material, pair the verification workshop with the MTS team demo, then follow the pstack setup documentation.