Compounding Grokbot Bots for Software Engineering Teams

Founders get crushed by work that is necessary but not the most important: call prep, support, product changes, competitor checks. Grokbot for founders, as Shub teaches it, is a squad of persistent bots with their own computer that take that work end to end and compound like employees.

You are not spinning up a chat, finishing a task, and throwing the agent away. You delegate the full flow — execution and verification — then keep the bot around, feed it what you learn, and let it get better the way a teammate would.

Set up specialist bots for customers, product, competitors, and feedback, connect them so context moves without you as the router, and protect the three jobs that actually make or break the company: focus, velocity, and the quality of your decisions.

Key takeaways

Treat Grokbot bots as staff you invest in, not ephemeral agents. Course-correct them. Do not delete them when context gets messy.
Prompt for the whole job, including verification. Partial handoffs leave the mental load on you.
Give each bot as much access as you are comfortable with — data, billing, calendar, the live product — or it cannot finish work end to end.
Group bots by expertise (customers, product, competitors, voice). Let them pull in other bots when they need help.
Spend one to two hours inventorying your day before you spin anything up. Intentional delegation beats hoping a bot invents a job.
Bias APIs over repeated browser use, and run routines on webhooks or real signals instead of every 15 minutes.
Keep a human in the loop for which feedback to ship, sensitive sends (draft first), and the customer conversations you actually want to steal back.
After two or three weeks of feeding call transcripts and outcomes back in, prep quality compounds; that is the point of keeping the bot.

Who this is for (and who should skip it)

This is for founders, and for a head of X who still owns a messy slice of execution. It assumes you have Grokbot, you can connect calendars, product telemetry, Linear or PRs, and at least one feedback channel, and you are willing to let a bot use a computer the way you would — including signing into tools.

Skip it if you only want throwaway chat sessions, if you will not connect the “risky” systems where support actually breaks (billing, accounts), or if you need hard enterprise determinism with no code. Models are not deterministic here. Shub’s workaround is to have bots write and call code, not to pretend the model is a rules engine.

Heads of functions who are not founders still get the same pattern: one expert bot per domain, compounding memory, end-to-end ownership.

Why Grokbot for founders beats throwaway agents

Shub’s curve is simple. Chatbots answered questions. Ephemeral agents finished a task and died. Bots stay. They automate a job, keep a device, learn from you, and — if you invest — start to look like a staff function you can scale.

Grokbot is the coworker you text like iMessage. It is proactive and ambitious because it has its own computer. It can use a direct connection when one exists, and it can use your tools the way you would when it does not. You assign work end to end so you are not babysitting.

Let your bots run free.

That is the operating rule. Access is the constraint. A bot that cannot see telemetry, billing, the live site, or your calendar will stop in the middle and hand the mental load back to you.

Founders specifically need this for three execution problems: a trillion distractions hitting focus, velocity across a team that now ships (and unships) constantly, and a fire hose of information that wrecks insight quality if you try to triage it yourself. Hand off the necessary-but-not-important layer. Keep the decisions.

Lingxi, an engineer on the team, is the in-room proof point Shub cites: he ships faster with Grokbot than he could before, including by kicking off cloud agents. The founder version of that is not “write more code.” It is “stop being the router for everything that is not a decision.”

Set up Grokbot bots as domain experts

Do not start by opening a blank bot and hoping. Shub wants one to two hours — even if you feel too busy — to inventory everything you actually do, then group that list into domains. Customers. Product. Competitors. Communications. A junk drawer for one-offs.

He groups bots by expertise so compounding stays clean. A customer bot gets everything customer-related. A data bot stays on data. Weird cross-benefits still show up inside a domain; they get noisy when you dump unrelated jobs on the same bot. Some people prefer a single chief-of-staff bot that abstracts the rest. Shub is not a fan. If you like control and training, run multiple experts and let them expand scope when you ask.

Write real skills, not “make this cooler.” Vague tasks stall and come back with questions. Intentional tasks repeat. Then give the bot a computer, cookies so it stays signed in, and the data it needs. Other bots should learn to loop in a specialist (especially a voice bot) instead of impersonating you badly.

What “good” looks like: you delegate, the bot finishes, you are not checking whether it finished, and after a few weeks it is using last week’s lessons without being told.

Close bot: the customer journey end to end

Close bot exists to do the unscalable customer work at scale: prep, follow-up, support, activation, pipeline, and calendar, with you stepping in only when you want the relationship.

Prepare telemetry for trial and usage, calendar access, Granola (or whatever transcript source the bot can actually pull), billing, and the live customer site. Shub’s demo company is Northwind; yours is whoever is on the calendar.

Ask the bot to prep the call. It researches the company, pulls usage, and walks their site.
Read the call-prep HTML five minutes before you join. It is for you, not the customer. Ugly is fine.
Use the usage graph to decide the conversation: accelerating (lean into a feature) vs declining (get to the objection).
After the call, have the same bot review the Granola transcript for what resonated and what did not, and write that into the next prep.
Connect support to product data and billing — the scary systems — or you will still be the support team.
Define an activation / wow event. When it fires, the bot sends the incentive without you watching the journey.
Let it work contracts, outbound pipeline, and calendar fill. Steal back the conversations you enjoy.

Good prep names who they are, what they build, what the site says they care about, screenshots, at least one concrete site issue (Shub’s recurring example: a cookie banner sitting on the submit button), activity that matches a 15–20 minute call, recommendations, and risks. Do this every time. Shub’s claim is that the bot finds a site issue without fail, which is a quality-of-life opener, not a metric you should treat as guaranteed.

Activation in the demo is extreme on purpose: a note-taking app, template shared with teammates, $1,000 in credits. Shub calls that a crazy example. The method is “enough incentive to cross the hump,” run as a campaign the bot owns.

Failure mode: you only automate prep and keep support, billing, and activation in your head. That is still two jobs. The other failure is emotional — the bot gets good enough that you have to take work back if you still want to talk to customers.

I no longer need to worry about 99% of this journey.

ProdBot: what shipped, what unshipped, what to decide

Engineers ship faster. Founders demo ghosts. Shub’s own miss: a sidebar feature came out, he still pointed at it on stage. ProdBot is the bot that makes “what is live?” a daily artifact instead of a panic.

In the demo he asks for a daily rundown of Flylow, a flights-and-booking surface. In real use, connect PRs, Linear issues, a logged-in product session, and metrics.

Have the bot walk the product end to end on its own computer — not just read tickets.
Demand shipped items, unshipped items, and micro-decisions the team did not mean to make at this speed.
Take the screenshots, and when you need to verify, ask for a video of the bot running the surface. Shub calls video the fastest way to see if the work is actually done.
Connect metrics so results of ships show up in the rundown instead of you living in a dashboard.

Good output is proactive: here is what changed, here is what disappeared, here is a decision to be more intentional about, here is what the numbers did. Failure mode is ticket-only awareness. If the bot cannot log in and click, it cannot save you from pointing at nothing.

StockBot: competitor pulses you do not babysit

Shipping is easy. Checking what everyone else shipped is not. StockBot finds competitors, signs up on its own, and returns a rundown: what they shipped, changelog, posts on X, who they are hiring (strong build signal), team, and priorities. Over time it compounds across more competitors and you get positioning and counterpositioning without tab-hopping.

Demo pulse: Notion and Craft, in parallel, against a hypothetical note-taking product. Routines run every few days. If nothing matters, the bot stays quiet. That ambient silence is a feature.

Name the competitors. Let it sign up with a throwaway email and authenticate.
Have it record the onboarding and core flow on video, then actually use the product (write a note in Craft, work inside its own Notion account).
Read hiring and changelog deltas, not vanity feature lists.
If you know from Salesforce or similar that a customer churned to a named tool, you can have the bot email them for why — insight, not an instant win-back. Shub flags this as something to do responsibly.

Good output is a teardown plus a walkthrough video plus signal (hiring, silence, a flow that differs from yours). Failure mode is running this as a high-frequency routine you stare at. It should interrupt you when something is relevant.

Shub shares this bot at the end of the session. Use it on his product if you want; he asked for that.

ProtoBot, Yap bot, and the junk drawer

ProtoBot turns a thought or a piece of customer feedback into a prototype, and often into a PR. It has its own Grokbot account — a separate entity — on its computer, so it can drive the real product, QA against the current UI, and kick off cloud agents. Pipe X, the support inbox, and other email signals into one pipeline that lands on this bot.

You still choose which feedback ships. That is the founder job. In the demo, a customer wants the share button for bot templates to pop; the bot starts working. Internally, Shub says some engineers already run feedback to ship to deploy in hours. Speed makes decision-making the bottleneck on purpose.

The main bottleneck should be your decision making.

Yap bot has one job: talk like you. It reads email, Slack, iMessage, and anything else you have sent, then retrains on a schedule (weekly, or whatever you set) from that day’s outbound. Other bots learn to pull Yap bot in when they need your voice on a surface. For sensitive mail, keep it on drafts. It should learn from the delta between the draft it wrote and what you actually sent.

The miscellaneous bot is a trash can. Random asks stay out of Close bot and ProdBot. If it learns something those bots need, you tell it to pass the file or the lesson over. Do not pollute an expert’s context with noise.

A final specialist Shub wants more people to run: a bot whose only job is to optimize the other bots — routines, repeated asks, failure patterns. Set it once.

How the squad hands off

The bots are stronger together. Close bot passes feedback to ProtoBot. ProdBot passes product decisions to Close bot so sales talk about what is actually live. Yap bot gets called when anyone needs to sound like you. You productize yourself and give away the Legos, including the ones you like.

Give away all of your Legos, no matter how delightful they are.

Use case	Bot / tool	Input needed	Output	Owner
Close customers	Close bot	Calendar, telemetry, Granola transcripts, billing, customer site	Call-prep HTML, recommendations, support, activation sends, pipeline/calendar	Founder (step in for deep conversations)
Stay across shipping	ProdBot	PRs, Linear, product login, metrics	Daily rundown, shipped/unshipped, screenshots, walkthrough video	Founder / PM
Competitor intel	StockBot	Competitor list, throwaway email, optional churn signal	Teardown, hiring/X/changelog pulse, product video, optional churn outreach	Founder
Feedback to prototype/PR	ProtoBot plus cloud agents	Feedback channels, product access, own Grokbot account	Prototype, PR, QA against live UI	Founder decides; bot executes
Sound like you	Yap bot	Email, Slack, iMessage, sent vs draft deltas	Outbound in your voice (drafts when sensitive)	Founder
One-offs without pollution	Misc bot	Random requests	Isolated answers; optional handoff to an expert bot	Founder

Prompts, bot instructions, and workflows

Shub did not paste system prompts. These are reconstructed from how he described each job. Paste them as starting instructions, then train by using the bot — do not treat them as finished magic.

Reconstructed from the speaker’s description — Close bot:

You own the customer journey end to end. Do the work and verify it.

Before every call: research the company and people; pull our telemetry and usage; walk their site; capture screenshots; note concrete UX/bugs; write a call-prep HTML file for me only (who they are, what they build, site walkthrough, relevant activity, conversation recommendations, risks). Run this daily against my calendar so prep exists five minutes before the meeting.

After every call: review the Granola transcript, note what resonated and what did not, and feed that into the next prep so we stop pitching features they rejected.

Support: use product data, billing, and the other sensitive systems required to actually resolve issues.

Activation: when the defined wow event fires, send the incentive without waiting for me.

Also handle contract back-and-forth, outbound pipeline, and filling my calendar. I will step in when I want the relationship, not for the default path.

Reconstructed from the speaker’s description — ProdBot:

Keep me current on what is live. Every day, rundown the product.

Read PRs and Linear, then log in and walk the product end to end on your computer. Report what shipped, what was unshipped, and micro-decisions we should be more intentional about. Include screenshots. When I need to verify, record a video of you running the surface.

Connect to our metrics and surface results of ships here so I am not living in the dashboard. Be proactive. Only interrupt with what is relevant.

Reconstructed from the speaker’s description — StockBot:

Run competitor pulses. Find the named competitors, sign up with a throwaway email, and go through the product yourself.

Return what they shipped, changelog, posts on X, hiring, team, and priorities. Record onboarding and core flows on video and actually use the product. Compare onboarding and UX to ours.

Run on a routine every few days. Stay silent if nothing is relevant. Over time, compound across more competitors and help me position and counterposition.

If we have churn signal that a customer left for a specific tool, reach out for why they left. Be responsible. Insight first, not a hard win-back.

Reconstructed from the speaker’s description — ProtoBot and Yap bot:

ProtoBot: You have your own product account and your own Grokbot. Pull the latest customer feedback from our pipeline (X, support inbox, email). Prototype against what the product looks like today. Kick off cloud agents, open PRs, and QA by driving the UI. I decide which feedback ships. You do the work once I choose.

Yap bot: Your only job is to talk like me. Learn from my email, Slack, iMessage, and other outbound. Retrain on a schedule from what I sent. Other bots should pull you in when they need my voice. For sensitive mail, leave drafts. Learn from the difference between your draft and what I actually sent.

Routing rule Shub actually uses: if a bot needs another domain, it should bring that bot in rather than stretching. If the junk-drawer bot learns something ProdBot needs, you explicitly tell it to pass the context over.

Optimization habit, in his words:

Always just ask your bot how to do it because it will figure it out for you.

Measurement and business impact

No controlled study, no token price list, no lead-count before/after. Judge the system the way Shub does.

Call prep: you walk in five minutes before, not after an hour and a half of research. After two or three weeks of transcript feedback, you stop tripping over features customers already rejected — including by leveraging other people’s calls, not only your own. Support and activation stop being the thing you leave for last while you still try to close.

Product: you are not surprised by unships, and you watch a bot video instead of clicking production yourself. Competitors: pulses every few days, interrupt only when relevant, hiring and churn as positioning signal. Feedback: the loop can move in hours; your checkpoint is whether you chose the work, not whether you did the work.

Token cost is the other scoreboard. A routine every 15 minutes is about 100 runs a day. Browser use stacked on that is how this gets expensive. Audit frequency. Prefer APIs. That is the measurement he kept coming back to when people said it costs too much.

He also claims you can scale to thousands of customers with bots instead of doing the journey yourself, and that internally they are close to automating a staff function. Treat those as his operating claims, not your forecast.

Power-user rules for Grokbot tokens and routines

Browser use unblocks work when there is no MCP or API. It is also expensive to repeat. Do the task once in the browser, have the bot watch network requests, then hit those APIs directly. Less time, fewer tokens. Be wary of browser use more than once if you can avoid it.

Headless browsing (commands against the DOM instead of screenshot-decide-repeat) is the other speed lever he names. Getting computer use as fast as a clean API is harder because you are stacking layers. Get close; do not assume you beat the API.

Routines are powerful and overused. Audit them — with a bot if you want. Prefer webhooks and inbound signals over blind schedules. Intentional and nifty beats “this is important so run it constantly.”

Import cookies from Chrome so the bot stays signed in and you stop taking over its computer. OnePassword via MCP is the example he gives for gathering secrets and connections. Make the voice bot. Group by expertise. Run an optimizer bot over the rest.

You can message a bot to forget something (“forget how we generated your profile picture”) when a slice of context is dominating. That is a token and quality fix.

Group chat with many bots: they are eager, they talk over each other, they get expensive. For most work, tag two bots separately instead of throwing the whole squad into one thread.

Cursor and Grokbot have a first-class integration in this stack. Grokbot can pass only relevant context to a cloud agent, the agent works independently, then Grokbot QAs if it can reach the environment — PR, UI, the shipped thing. Use a Cursor cloud agent (or Grokbuild) when the task is complicated, you want to pick the model, or you want to get in and change things. Specify the model default once. Try both until you have intuition; he will not draw a sharper line than that.

Local execution lives in settings if you want the bot on your machine (messages, driving your browser). He still biases to the bot’s computer: local apps pop up on your screen, they fight you for resources, and you cannot parallelize cleanly. Bots do not share memory. They share a filesystem on one VM with separate instances, like desktops. They can read each other’s files and will do that when a task needs it.

Pitfalls and guardrails

Starving the bot of access. If you withhold billing, production logins, or calendar, you get a research assistant, not a colleague.
Throwing the bot away. Agent instinct is “context polluted, start over.” Here the advantage is time spent. Course-correct. Invest.
Lazy skills. “Make this cooler” is how you get stuck.
Over-automation of relationships. Close bot can take 99% of the path. You may still want the hard conversations. Take them back on purpose.
Brand voice. Without Yap bot, other bots will speak for you. Use drafts on sensitive mail until the draft-vs-sent gap is small.
Customer-facing activation and support. Connect the risky systems or the bot will fail at the exact moment a human would have had to escalate anyway.
Competitor outreach. Signing up, walking the product, reading hiring and X is the core. Emailing churned customers is optional and easy to do sloppily. Be responsible.
Determinism. There is no policy layer outside the model. Workaround: bots write code, you give a flowchart or decision tree, the model calls that function. Asking another bot for permission is allowed; code you can verify is better.
Auth and ecosystem walls. Some products will fight bot logins. Ask Grokbot to figure it out. Be less prescriptive about tools — Shub landed on Granola because it was the easiest transcript form factor, not because of brand loyalty. An optimizer bot should swap sources when a first-party integration appears.
Multiple computers. This used to confuse bots. Shub says it should work a lot better now; if it does not, that is a product issue to raise, not a clever setup.
Marketplace trust. Internal marketplace at x.ai/bot/marketplace is hand-audited (humans and bots reviewing bots). Still ask a template bot what it does and how before you let it run. Trying it yourself is the real test.

Cross-account, cross-person bot talk is not a capability today. Do not design a company-wide bot mesh on that assumption.

7-day implementation plan

Day 1

Block one to two hours. Inventory the work that hits you. Circle the necessary-but-not-important layer. Group it into domains. Pick one expert bot to stand up first — usually customers if you are still in the funnel, or product if you are already embarrassed by what shipped. Decide what access you are actually willing to give. Write that down before you click anything.

Days 2–3

Create the first domain bot. Connect calendar, the live surface, and the data it needs. Write a specific skill (use the Close bot or ProdBot reconstruction, then cut it to your stack). Run one real job: a call prep or a product rundown. Inspect the artifact. Course-correct the bot; do not recreate it. If it will send anything external, force drafts.

Days 4–5

Add the second bot (StockBot or ProdBot, whichever you skipped). Set routines on a few-day cadence or on a webhook, not every 15 minutes. Do one browser task with network-request capture, then switch that path to APIs. Import cookies. If you have churn or competitor names, run one pulse and require silence when nothing changed.

Days 6–7

Stand up ProtoBot against one feedback channel and Yap bot against a week of your outbound. Tell the experts when to pull Yap bot. Add the misc bot so random asks stop polluting the squad. Turn on an optimizer bot to watch repeated asks and stupid routine frequency. Practice one handoff: Close bot feedback into ProtoBot, or ProdBot decisions into Close bot. Kick a cloud agent only for something you would actually ship, then let Grokbot QA it.

Get the first bot compounding

The outcome is not more chat. It is a founder who still makes the calls that matter while a small staff of bots — with computers, routines, and memory — handles the rest and gets better every week you refuse to throw them away. Start with one expert bot, give it real access, and run one end-to-end job tomorrow. Watch the walkthrough when you want the demos, the StockBot share, and the live Q&A texture behind this manual.

FAQ

Do I need Cursor if I already use Grokbot?

Not for everything. Shub uses Grokbot to orchestrate and QA, and Cursor cloud agents (or Grokbuild) when the work is a complicated ship, he wants a specific model, or he wants to reach in and change the result. Grokbot can pass only the relevant context, the agent works on its own, then Grokbot tests the PR or the UI if it has environment access. Spin up a few real ships; the intuition is the point.

Expert bots vs a chief-of-staff bot — which should I run?

Shub groups by domain (customers, finance, marketing) and lets experts stretch when asked. A single chief-of-staff bot that hides the rest is a valid preference if you want one conversation. He is not a fan. If you like getting into the weeds and training, multiple experts compound more cleanly.

How do I create the actual job for a bot?

Inventory the work, cluster it, assign one domain, and write a skill with enough intentionality that the bot can repeat it without a quiz. Then give it tools and access. Expand scope after it is good, the way you would with a hire. He wishes they had XP bars. They do not. Time spent is the XP bar.

Browser use vs APIs — which should Grokbot use?

Browser use when there is no connection. APIs when you can. Do the flow once, capture the network requests, then call those APIs. Headless DOM control is faster than screenshot loops. Repeated browser use is the expensive path people wander into without noticing.

Can Grokbot make deterministic enterprise decisions?

The model cannot. Have it write code with a decision tree and call that function every time, or give it a flowchart it must follow. You can require another bot’s permission. Verifiable code is the better cosplay of determinism.

Do Grokbot bots share memory? What about multiple computers?

They do not share context windows. They share a filesystem on one VM, with a separate instance per bot, and they can read each other’s files. Multiple computers used to confuse them; Shub says that should work much better now. Local execution is optional in settings and is jankier than the bot’s own computer.

Should I put all my Grokbot bots in a group chat?

Usually no. They all want to talk, they talk over each other, and the bill goes up. Tag the one or two bots you need. Save the group form for rare, genuinely multi-expert tasks.

How do I import my old agent setup into Grokbot?

There is no finished one-click importer in this session. Shub says they are working on a bot for it. Until then: one source of truth for MCPs and APIs, OnePassword via MCP, and imported browser cookies for sessions. Ask Grokbot to solve auth instead of over-specifying tools. Some products will still refuse bots; that is an ecosystem problem, not a prompt problem.