Subscribe to Newsletter

Module 2: Engineering Workflows

This module shows how engineers at SpaceXAI run Grok Bot. Each lesson solves one problem, from the first outer-loop Bot around your coding agents to a team of Bots that runs while you sleep.

Start module Module 2 of 3 · 7 lessons

2.1

Set Up An Outer-Loop Bot That Manages Your Coding Agents

You already run coding agents. Each run still needs you to gather context, write the prompt, watch the run, review the result, and merge.

Matt Palmer, who works on Cursor and Grok Bot at SpaceXAI, moved that whole loop into one Bot he calls Loops. “I talk to Loops, and Loops talks to a coding agent.”

The loop you are handing over

Matt published Loops as a template. It describes itself as a generalized engineering outer loop that sits above coding agents and runs five stages.

The template adds one rule about scope. “You name the repo; it never guesses.”

Bot edit · test coding agent Gather Prompt Launch Review Merge OUTER LOOP: THE BOT · INNER LOOP: THE AGENT
Scroll sideways →Loops owns the outer ring. The coding agent keeps its own inner cycle.

Gather: the Bot builds context before anyone codes

Matt’s example is an update to the Cursor website. He asks Loops to look at contributions from three named teammates to learn their patterns.

He asks it to read competitors’ documentation for how they handle the same problems. He asks how the team can verify the solution. Once the Bot has that context, it drafts the prompt.

Prompt: a draft you edit, not a prompt you write

Loops provides a draft prompt and kicks off cloud agents. At that point Matt’s workflow shifts from Grok Bot to Cursor.

He writes prompts in a style he calls pstack, with heavy use of /goal and loops. The template describes it through three reference points, how, why, and unslop, and says the prompts carry testable proof. None of the sources define the format further.

Lingxi Li, an engineer at SpaceXAI, describes the same stage from his own Bots. When a Bot receives a task, from him or from Slack, it kicks off a cloud agent with his skills invoked.

His Bots also pick extra skills from his personal guidance:

  • A design skill for visual work
  • A React Native skill for code quality audits
  • A review skill for architecture
  • A product skill for opinionated product decisions

The prompt the Bot writes has the same shape as the five-part request you learned to write yourself.

Launch and watch: the Bot stays on the run so you don’t

Lingxi’s Bots create Cursor cloud agents, read transcripts, and review proofs attached to PRs.

Grok Bot monitors the transcript and artifacts such as screenshots. It notifies you when the run finishes, queues messages, or interrupts if anything goes wrong.

TRANSCRIPT PULL REQUEST before after proof attached Bot Notify you Queue a message Interrupt the run
Scroll sideways →The Bot stays on the run so you do not have to.

You describe what you need in plain words. Lingxi’s example:

Ask for proof
You must verify the screenshot includes the changes I asked for, with
proof showing before vs. after.

Grok Bot continues until it meets that goal. “Everything is now just a message away. Want them to keep pushing 10 times before handing off to you? Just say so.”

Review and merge: what comes back to you

Lingxi’s Bots check each PR’s proof against the request. If the review is highly confident and the blast radius is low, the Bot merges automatically. Otherwise the PR waits for him.

The review rules, the 30-minute check, and the shared task board are in the lesson on the PR pipeline.

Start with one repo and one loop

The fastest start is to install the loops template. Templates copy a Bot’s skills, memories, and plugins without any private data. Matt compares them to a recipe: the same dish, in your kitchen, with your ingredients.

The template needs the GitHub and Cursor plugins, and a named repo.

If you build the Bot yourself, create one narrow Bot and give it one job. Run one task end to end before you add routines.

Watch: Templates in Grok Bot, by Matt Palmer. How to install a template, and what a template does and does not copy.
FIRST LOOP REPO the one repo this Bot owns · it never guesses CODING AGENT Cursor cloud agent, GitHub plugin PROOF EXPECTED before-and-after screenshots HAND BACK TO ME when the proof is attached and CI is green
Scroll sideways →Four lines are enough to start the first loop.
TRY THIS IN GROK BOT

Goal: Run one outer loop end to end on one repo.

  1. Install the loops template, or create a Bot with the GitHub and Cursor plugins.
  2. Name one repo in its description. The Bot never guesses one.
  3. Send one task that states the proof you expect, such as before-and-after screenshots.
  4. When the Bot reports back, check the returned proof against your request.

Expected result: A PR with proof attached, and a Bot that waited for you at the review point you named.

2.2

Write A Bot’s Job Description

The Bot from the last lesson works, but its instructions live in one long chat. A written job description keeps the Bot on its lane, survives new conversations, and gives you a template for the next Bot.

Four parts of a working description

SpaceXAI publishes an x.ai guide by an engineer who runs a mobile game studio, Rank’em, with six Bots.

The studio builds a game, not a code tool. Its four-part format fits a code Bot without change.

1 · Job description who the Bot is · the lane it owns · the work it refuses 2 · Connections what it can reach · ask before working around a missing one 3 · A computer in the cloud where it works · runs whether or not your laptop is on 4 · Routines when it acts · schedule or event
Scroll sideways →Rules that stay true live in these four parts. Task instructions live in the conversation.

Here is the full configuration of the studio’s Analytics Bot from the guide:

Analytics Bot, Rank’em
1. Job description
You are the analytics and user acquisition seat for Rank'em, a mobile
game studio run by six bots. You own paid acquisition end to end. Read
what players actually did, not what I hoped they would. You are the
only bot allowed to declare a finding. You never write creative and you
never touch app code.

2. Connections
You are signed into Meta Ads and AppLovin for spend, Adjust for
attribution, PostHog and Google Cloud for product data, Apple and
Google Play for revenue, and Sentry for errors. If a tool you need is
not connected, ask me before working around it.

3. A computer in the cloud
Do this work on your own computer. Sign into Meta Ads Manager and click
through campaign setup yourself. Run on schedule whether or not my
laptop is on.

4. Routines
Every night at 7:10 PM CT: recap spend, installs, and CPI across Meta
and AppLovin. Name winners and losers.

The job line says what the Bot owns and what it refuses

The guide defines a job description as a system prompt that reads like a role, “the lane it owns, and the work it refuses.”

Each of the studio’s Bots carries a refusal.

BotOwnsRefuses
AnalyticsThe only Bot allowed to declare a findingNever writes creative, never touches app code
CreativesTurns findings into ad specsNever buys the media itself
EngineerTakes a finding as a specNot as a suggestion
DeployCerts, deploys, and rollbacksNothing reaches players without it
Bug FixFixes what is obviousEscalates what is not

Rules go in the description, tasks go in the conversation

According to SpaceXAI, the description holds rules that should remain true. The conversation holds task-specific instructions. Their pair of examples:

  • Description: “Never send external messages without approval.”
  • Message: “Draft follow-ups for these twelve accounts.”

Update the description when you discover a durable preference, boundary, or responsibility. Put explicit safety boundaries there too.

Name the connections, and say what to do when one is missing

The Rank’em connections block names each tool with its purpose. Then it ends with one rule. “If a tool you need is not connected, ask me before working around it.”

The author hit that case when the Meta Ads API failed verification. Rather than wait on support, they recorded one upload through the Meta web UI. The Bot kept the click-path for every creative after that.

One specialist per code area beats one general helper

Lingxi Li at SpaceXAI runs five engineer Bots, each with its own area.

They can work across each other’s areas. But each has a different memory and limited context, so they perform best inside one domain.

Baltata iOS · shared layer Shaoruru desktop · CI/CD Hogan infrastructure Craig Android Quill harness One shared repo different memory · limited context · best inside one domain
Scroll sideways →One specialist per code area. They can cross over, but their context is sharpest at home.

Grow the roster one stable role at a time

  1. Give one Bot ownership of an end-to-end outcome.
  2. Add another Bot only when the work has a stable specialist role.
  3. Put Bots in a group chat when the handoff itself needs to be visible.
  4. Keep external actions behind a clear approval boundary.

That is SpaceXAI’s advice. Your existing Bots can propose a focused Bot when a job needs a long-lived owner. Ask them to check with you first if you want the roster small.

To reuse a role for a new scope, duplicate the Bot. The copy carries the profile, settings, skills, routines, and avatar, but not the conversation history or learned memory.

TRY THIS IN GROK BOT

Goal: Give your outer-loop Bot a written job description.

  1. Start from the four-part format: job, connections, computer, routines.
  2. Add the refusal line and the ask-first line.
  3. Move every rule that stays true from the chat into the description. Leave task instructions in the conversation.

Expected result: A Bot that holds its lane in a fresh conversation, and a description you can duplicate for the next role.

2.3

Give Agents A Complete Feedback Loop

A coding agent that cannot see the result of its own change stalls, guesses, or reports a success it never checked.

Lingxi Li at SpaceXAI names the fix as one key to a Bot engineering team that does not stop. Give the cloud agents a complete feedback loop, so they get signals about what to do next without you.

Agent changes code Launches dev instance Captures proof Bot compares to request Bot sends next step no human in the loop
Scroll sideways →The agent must see its own result. The Bot closes the loop without you.

Launch a dev instance and drive the stack end to end

Lingxi’s rule is that agents should be able to launch a dev instance and drive the stack end to end. He names three surfaces.

If the agents cannot do that yet, ask them to work out how to run the flow themselves.

Ask for proof in the prompt

Cloud agents can take screenshots. Grok Bot uses its multimodality to confirm the agent applied the change, and pushes back when the result does not match the request.

Matt Palmer does the same for a Bot that tries out new technologies each morning. He gave it explicit verification parameters, screenshots and videos, and he inspects them from inside Grok Bot.

Those screenshots come from inside the Cursor agent that writes the code. Grok Bot can use the agent’s computer as well as its own.

Matt keeps his demos in one repo on Cloudflare, so each project gets a preview deployment the Bot can see. That gives him three ways to check a result.

  • See a quick preview live in Grok Bot
  • Open the app and play with it in his browser
  • Drill into the code or continue to iterate in Cursor

Test what you cannot screenshot

Lingxi’s team hooked SpaceXAI’s voice API into the cloud agent’s system audio. The agent has both the spoken word and the transcript, so it can test speech-to-speech features across the product lineup.

Unblock aggressively

An agent that hits environment flakiness stalls until someone sends a follow-up. Grok Bot stays on the run and unblocks it as aggressively as it can.

One-off flakiness rarely reaches Lingxi any more. The exception is when Grok Bot lacks the security permission to fix it. Put the same rule in your prompt.

Run stalls Attempt 1 Attempt 2 Attempt 3 the Bot, on its own you only if the Bot lacks the permission flakiness rarely reaches you
Scroll sideways →The Bot unblocks the agent aggressively. You hear about it only when permissions stop it.

Package what the agent learns as a repo skill

Once an agent works out how to run the flow, Lingxi has it package what it learned into a reusable repo skill. The next agent starts from that skill. It does not repeat the discovery.

TRY THIS IN GROK BOT

Goal: Close the loop so an agent can verify its own work.

  1. Confirm the agent can launch a dev instance and drive it end to end through DevTools, the CLI, or Accessibility.
  2. In your next task, ask for proof: before-and-after screenshots or a short video.
  3. Tell the agent to unblock itself as aggressively as it can.
  4. Tell it to save what it learns as a repo skill.

Expected result: A run that reaches proof without a follow-up prompt from you, and a repo skill the next agent starts from.

2.4

Automate The PR Pipeline And Nightly Audits

Your outer-loop Bot handles one task at a time in one chat. Once it runs twenty PRs, it loses track past the context limit, and you scroll long threads to find status. Routines and a shared board fix both.

Track work outside the chat

Lingxi Li at SpaceXAI has each engineer Bot manage a shared Notion database.

Each task is a row. The Bot moves it between states such as Working and Ready for Review, so he scans progress without a scroll through long chats.

WORKING READY FOR REVIEW MERGED Task row the Bot moves the row · back to Working on a failed check
Scroll sideways →The board outlives the context window. Scan it instead of the chat.

The 30-minute PR check

Every 30 minutes, Lingxi’s Bots review the database and check each PR for three things.

  • Bugbot comments or security findings, with a check on whether each one is legitimate
  • Failing CI runs
  • Merge conflicts

If they find anything off, they follow up with the cloud agent at once. The row moves back to Working.

If everything looks good, the Bot marks the task Ready for Review and starts a code review run. If the review is highly confident and the blast radius is low, it merges automatically.

Otherwise Lingxi reviews the code and the proof when he is back. Almost every morning he finds tasks ready to merge, with proofs that show what the agents tested.

Nightly audits keep the codebase clean

Every night at 3 a.m., Lingxi’s engineer Bots are awake. They clean up the codebase, sweep out dead logic, speed up app load time, and reduce bundle size.

Every morning he gets a fresh set of PRs. His list of more nightly audit ideas:

  • Security audits to catch issues the team may have overlooked
  • CI/CD build-time audits to keep build times short
  • Internationalization audits to close gaps when features ship in only one language
  • Parity audits to avoid drift when features land on only one of several clients, such as iOS versus desktop
  • Catch-up audits that monitor PRs merged in the past 24 hours for one area, then hand back a summary and a curated list of PRs to review

And his favourite prompt of all:

“You have six hours tonight. Build whatever you want. Have fun!”
Source: Lingxi Li, Grok Bot for Engineering.

The P0 urgency routine

Cloud agents can be slow. When Lingxi says a task is P0, his Bots start a temporary routine. It checks the transcript every five minutes and steers the cloud agent when it starts to burn unnecessary time.

It works for codebase research and critical bug fixes alike. His warning: it burns tokens much faster than you think, so use it only for true urgency.

Write the routine so the Bot can run it unattended

To create a routine, SpaceXAI says to ask the Bot that should own the recurring job:

Scheduled routine
Every weekday at 8:00 AM, run the Daily customer-risk skill against the
current account list. Post a linked watch list in this conversation. Do
not contact customers. If the source data is unavailable, report the
failure instead of using old data.
CONFIRM BEFORE YOU SEND
  1. The owning Bot
  2. The schedule and time zone
  3. The input source
  4. The expected result
  5. The approval boundary
  6. What should happen when a source is missing

Background routines run while your laptop stays shut. A Bot can own up to 50 routines, and the app keeps the 20 most recent run records for each.

Start a routine from a Slack message or a GitHub notification

Account integrations can start a routine from an event. The docs note these are separate from the Slack and GitHub plugins and may need their own connection flow.

Define a narrow matching rule and a clear response:

Event-triggered routine
When a message in #customer-escalations contains a support ticket link
and the phrase "needs repro," open the ticket, reproduce the issue in
staging, and post a repro pack in this conversation. Never post back to
Slack without approval.

Avoid broad listeners such as every new message. They create noise, consume usage, and raise the chance of action on irrelevant input.

This is the mechanism behind Lingxi’s Bots, which take tasks from Slack as well as from him.

Test before you enable

Use Test run after you create or edit a routine. A test run performs real work, so use safe inputs and keep write actions behind approval.

Review the run against the list below, then hold the routine to SpaceXAI’s rules before you enable it.

After the test run, SpaceXAI says to review
Rules for a routine you can trust
0 / 12

Tick each item against your routine. This browser remembers your ticks.

One-time task Skill Routine Event trigger test run before enable narrow matching rule · safe inputs · writes behind approval
Scroll sideways →Climb one rung at a time. Test run is the gate before anything runs unattended.

After a long period away, Grok Bot may ask whether to keep routines active. If there is no response, it pauses them. Review paused routines when you return.

TRY THIS IN GROK BOT

Goal: Put the PR pipeline on a routine you can trust.

  1. Create a shared board with Working and Ready for Review columns, and tell the Bot to keep it current.
  2. Ask the Bot to create the 30-minute PR check routine. Confirm the six things above before you send.
  3. Run Test run with safe inputs. Confirm it stops at the approval point.
  4. Schedule one nightly audit.

Expected result: You wake up to a PR marked Ready for Review, with proof attached and the board already updated.

The Code: Your daily unfair advantage in software engineering.

Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.

Subscribe to Newsletter
2.5

Run A Team Of Bots

You have several specialist Bots and one outer-loop Bot, and every task still routes through you.

The practitioners in this lesson add three layers that take you out of the middle. A manager that delegates, an ops Bot that keeps the team aligned, and a channel per project.

A manager that delegates but never codes

Kevin Niparko, product lead at SpaceXAI and former product lead at Cursor, runs an engineering manager Bot named Emily. The EM “is NOT supposed code...just manage.”

Emily breaks down technical work, delegates to five IC engineering agents, and validates outputs against the goal. To onboard, she read all of one senior engineer’s Slack messages to learn what great looks like.

The IC agents use Cursor cloud agents under the hood. They manage many at once and coordinate with each other. “It’s agents all the way down!”

you Manager Bot never codes IC Bot 1 IC Bot 2 IC Bot 3 IC Bot 4 IC Bot 5 cloud agents · many per IC Bot
Scroll sideways →Agents all the way down. The manager never codes.

An ops Bot that runs 1:1s and postmortems

Lingxi Li at SpaceXAI has operational chores across his Bot org. New engineer Bots need onboarding, knowledge needs to reach the right Bot, incidents need postmortems, and the team needs daily meetings.

That is all Jenny’s job. She is his head of operations and the only Bot on the team that does not write code.

Every morning at 5 a.m., Jenny meets 1:1 with every Bot. They review the playbook, surface blockers, and reinforce the working style Lingxi wants.

The context limit cannot fit everything. A daily repeat of the key points is the nudge that keeps complex workflows in his Bots’ memory, even after many weeks.

One project, one channel, one roster

A second x.ai guide, by a SpaceXAI engineer, describes what happens when separate chats no longer scale. Several projects at once make it hard to separate signal from noise and keep the Bots in sync.

The author copied how human teams coordinate. Each project gets a Grok Bot channel and a row in a Notion Projects database, with a Tasks database beside it.

A Manager Bot with a Project Ops skill creates the project, opens the channel, and staffs it. The author calls it an experimental pattern.

The guide’s three staffing rules:

  1. Reuse existing Bots first, such as a Coder, Researcher, or Writer already defined.
  2. Propose at most five Bots besides the PM. Each channel holds at most six Bots.
  3. Create a new Bot only when nothing on the bench fits, and only after the author says yes.
#PROJECT CHANNEL Manager Coder Researcher Writer Reviewer Ephemeral at most six Bots · plus you DOING BLOCKED DONE card ping
Scroll sideways →One project, one channel, one board. A Blocked card is the only thing that needs you.

Once the channel exists, the author scopes the project’s tasks with the roster. The PM watches progress and keeps the databases current.

When a Bot gets stuck, it marks its task Blocked and pings the author in the channel. Often the Bots accomplish a lot on their own, and the author just watches the cards move.

It is the same board idea as Lingxi’s PR database, one level up.

Kick off a group and hand work between Bots

According to SpaceXAI, use a group when several Bots need one shared outcome and visible handoffs. Describe the outcome and who owns the next step:

Group kickoff
@Researcher gather the source material and link every claim. @Writer
turn the findings into a launch draft. @Reviewer check the draft
against the sources and list only blocking issues. Do not publish
anything.

Mention one Bot when it owns the request. Mention several only when the request needs each of them, and use @everyone sparingly.

A Bot can also message another Bot directly. The receiver wakes, does the work, and replies later. Handoff messages are text-only, so a Bot should send an image directly to the teammate that must inspect it.

One owner per stage

The docs list four cases where a handoff helps.

  • One Bot owns a source system and another owns the deliverable
  • A specialist should review a draft
  • A blocker belongs to another role
  • A long-running job should continue without you as the coordinator

Ask for a single owner at each stage. You keep control from outside the group. A direct message from you takes priority and can redirect the current turn, and “Stop now” ends work at once.

TRY THIS IN GROK BOT

Goal: Take yourself out of the middle of the roster.

  1. Give one Bot the manager job, with a rule in its description that it never codes.
  2. Open one channel for one project with at most six Bots, and name a single owner for each stage.
  3. Send the kickoff message above, adapted to your project.

Expected result: Handoffs you can see in the channel, and a Blocked card that pings you only when a Bot needs input.

2.6

Cut Token Spend And Speed Things Up

Your Bots now run routines every 30 minutes and audits every night. Every browser click in those runs costs tokens, and the browser is the slowest way to do anything.

Four tactics cut the bill and the wait.

Turn one browser run into a script

Sam Sokolin, who builds Grok Bot at SpaceXAI, asks the Bot to reverse engineer expensive browser tasks into scripts.

The Bot captures the network requests from one computer-use run. Next time, it skips the UI and hits the APIs directly with the same auth. A script is also far faster than a Bot that clicks around in a GUI.

RUN ONE RUN TWO Bot Web app UI click · click · click Records requests Bot API same auth · one call Script reverse engineered tokens tokens
Scroll sideways →Record the clicks once. Hit the API forever after.

Sam later shared a Bot that does this conversion for you. Not My Tempo audits your other Bots’ inefficient routines and converts expensive computer-use tasks into scripts and connectors.

The Bot directory lists ready-made Bots like it.

Prefer a connector, fall back to the browser

According to SpaceXAI, a connector is often more reliable than clicks through a website. Use the browser only for services without a connector, or for visual workflows a connector does not expose.

To add one:

  1. Open Settings, then Plugins.
  2. Browse the available connectors and choose Add.
  3. Complete authentication in your browser if requested.
  4. In chat, type @ to attach the connector to the task.

Installed connectors are account-wide. Every Bot on your account can use them.

Teach by demonstration when the API is blocked

Some services block both paths. In the x.ai Rank’em guide, the Meta Ads API failed verification, so the author recorded one upload through the Meta web UI.

The Bot remembered the click-path. From then on it uploaded and tested at least one new creative per day.

This is the case the ask-first line in the job description lesson covers.

Run several Bots in parallel, and use a private worker for special setups

Each Bot gets its own screen on the shared computer, so several Bots can use browser and desktop tools at the same time. Cloud work continues when you close the app or the laptop.

Some workflows need VPN access or a special machine. For those, Lingxi Li makes a spare Mac mini a Cursor Cloud private worker and asks Grok Bot to run cloud agents there.

That unlocks the iOS Simulator, with screenshots back from the agents. You no longer need a dedicated machine at home that runs around the clock.

Grok Bot CLOUD COMPUTER cloud agents default · always on PRIVATE WORKER · MAC MINI VPN iOS Simulator screenshots come back
Scroll sideways →Special setups run on your own machine as a private worker. The Bot dispatches to both.

The five-minute P0 check is the fastest way to move one task. Lingxi’s warning stands. It burns tokens much faster than you think, so keep it for true urgency.

TRY THIS IN GROK BOT

Goal: Cut the cost of one repeated browser task.

  1. Pick the routine that clicks through a web app most often.
  2. Ask the Bot to capture the network requests from one computer-use run.
  3. Ask it to turn those requests into a script that hits the API with the same auth.
  4. If a connector exists for that service, add it from Settings, then Plugins, and prefer it.

Expected result: The next run of that routine finishes faster and shows a smaller token cost.

2.7

Your Engineering Checklist

Here is the whole system as fifteen actions, in the order the module taught them. Each group maps to one lesson, so go back to that lesson if an item is unclear.

Tick each item when you complete it. Item 12 is the sign that the system runs without you. This browser remembers your ticks.

0 / 15

Tick the items above as you complete them.

END OF MODULE 2

By this point you should have:

  • One outer-loop Bot on one repo that gathers context, drafts the prompt, launches the agent, and checks the proof
  • A written job description with a refusal line and an ask-first line
  • Agents that run the stack themselves, unblock themselves, and save what they learn as repo skills
  • A 30-minute PR check and a nightly audit that run while you sleep
  • A manager Bot and one channel per project, once the roster grows
  • One browser task converted to a script