If you try to use AI bots to run a business by imagining the whole platform first, you will invent features you do not need. The team in this session ran the opposite play: stand up a software factory, get a landing page taking emails, then do the real work of finding venues, people, and demand by hand so the bots only wrap loops the humans have already felt.
You will be able to connect GitHub and Cursor cloud agents, put pull-request review and bug triage on Slack, add a verification skill so agents are not blocked waiting for you to click around the app, and spin specialized bots from a bot factory while a small team still owns calls, merges, and brand voice.
The method is factory first, dogfood the business, automate second. Do not wait for a polished product to start operating.
Key takeaways
- Use AI bots to run a business in parallel with shipping: research, outreach lists, design, docs, and PR review can move while the product is still a prototype.
- Start workflows in Grokbot, then move implementation into Cursor. Auth the org, pick the repos that matter, and re-auth or install the GitHub CLI on the bot’s machine when repo access gets flaky.
- Copy the ops pattern from a high-functioning engineering Slack: a PR review channel and a bug reports channel, each with an automation that fires on every post.
- A verification skill is not optional. Without it, agents keep handing the app back to you to click around, which makes the loop slow.
- Do the work manually before you automate it. If you are not yet a domain expert, building the platform from imagination wastes the factory.
- Use Dr. Eggbot as a bot factory: one bot that creates more bots (research, outreach, knowledge base, marketing) instead of stuffing every job into a single agent.
- Treat Notion like a git log, not a dump. A knowledge base manager should wait to be called, check with a human, and update selectively so other bots can read shared context without spam.
- Keep the prototype scrappy. Skip lint rules, exotic stacks, and full auth until the loop you are dogfooding is real. API keys are still often manual.
Who this is for when you use AI bots to run a business
This is for a founder, operator, marketer, or eng lead on a tiny team that already lives in Slack and GitHub and is willing to run Cursor cloud agents. The working example is a three-person crew with titles on paper (CEO, CPO, CTO) and a swarm of bots doing the rest. You should be comfortable pasting long instructions, reviewing PRs, and making real-world calls yourself.
Skip it if you need a finished SaaS playbook, conversion metrics, or a no-code-only stack. The session does not give budgets, retainers, or proof that the pop-up or the platform made money. It also assumes you will keep a human on customer-facing email, phone, and merge decisions.
Stand up the AI bot software factory first
The goal is not a restaurant app. The goal is a factory that can post work, review it, and keep moving while you figure out the business. Lauren’s reference point is the SpaceX AI Slack: automations that review PRs and triage bug reports. Matt’s default path is Grokbot for direction, then Cursor for the repo.
Connect GitHub and Cursor cloud agents
Auth the org in Cursor. Select the repositories you are actually shipping — here, a Thursday repo and a company repo — and confirm the agents can see both. If a bot cannot access the repo, do not keep prompting into the void. The failure modes they hit were a wrong connector, stale auth, and missing GitHub CLI on the bot’s computer. Re-auth, install the CLI, and tell the agent to use it.
Good looks like agents opening PRs against the right repo without you babysitting credentials. Failure looks like stuck jobs and a pile of prototypes you forgot you asked for.
Start in Grokbot, then hand off to Cursor
Do not begin every task as a blank Cursor chat. Use Grokbot to research, prioritize, and write the job; then let Cursor implement against the repo. That split keeps strategy and code from collapsing into one noisy thread.
Use Dr. Eggbot as a bot factory
Dr. Eggbot is a marketplace bot for making more bots. Instead of one generalist, spin a prioritizer, an operator-research bot, a host finder, a marketing bot, a menu bot, a knowledge base manager. Each bot gets a job, a place to write (Slack, Notion, a PR), and a human owner.
I do the work manually first before I automate it.
That rule applies to the factory itself. Do not skip the ugly manual pass because the bots are available.
Put PR review and bug triage on Slack
You are trying to make review a channel habit, not a meeting. Create a PR review channel. You or your bots post PR links there. Pair it with a Cursor automation that runs on every post in that channel.
What the PR automation should check
Lauren’s first version was “pretty unsophisticated”: a prompt in the automation, using P-stack, looking at correctness, risk, and missing tests. She did not treat the prompt as finished. Iterate it once you see what the agents get wrong.
Good looks like every PR landing in one place with a consistent review pass. Failure looks like PRs stacking while videos, screenshots, or evals are missing — in this session they had more than a dozen PRs, including prototype branches they had forgotten they requested, and several jobs that looked stuck.
Add a bug reports channel before you have bugs
Stand up a second channel with a similar automation even if the app barely exists. The point is the factory, not the ticket volume. Later you can pipe public feedback (they mentioned pulling from X once a page is live) into the same channel, auto-open PRs, and triage. Do not wait for production traffic to design that path.
Build a verification skill so agents are not blocked
Verification is a really important part of using bots well.
Without a verification skill, the bot finishes a change and asks you to run the app, click around, and report whether it works. That back-and-forth is the bottleneck. With verification, the agent can run the application, take traces, keep snapshots, and debug without waiting on you.
What to prepare
Use P-stack and run the skill that creates a verification skill. In this session that work was delegated to Tater bot. Expect it to take a while. While it runs, keep shipping the lander and waitlist; do not sit on the skill.
Two parts that make the skill useful
Lauren’s rule of thumb: the skill needs a CLI, script, or other tool so bots interact with the app in a reliable, deterministic way, plus a feature map so agents know what exists, how to reach it, and any keyboard shortcuts.
Agents can write one-off scripts. That burns tokens and is not reproducible — every bot invents its own harness. A standard CLI is the point. The feature map matters more once you actually have features; on a near-empty app it can wait, but the CLI should not.
Always-on visual proof
After the first pass, they made the verification skill more generic and always applied. Agents should include visual proof when the change has visual impact (cloud agents can produce videos; those can go in the PR description or Slack if you tell them to). Backend changes still need verification, even if there is nothing to screenshot.
Good looks like a PR you can review from the recording and the checklist, not a conversation that asks you to click. Failure looks like missing videos and a skill that is not actually invoked.
Dogfood the business before you automate the platform
This is how you use AI bots to run operations before the product exists. The stretch goal was a San Francisco pop-up, then turning the software that made the pop-up possible into something you could sell. Day-three revenue was named as ambitious, not a forecast. Ship-by-Thursday was the working cadence, not a metric.
Lock a date and a hero use case
Do not start with a dozen platform objects. Pick a date so outreach has a sentence. They used October 15 as a conservative, about-a-month-out stake, and wrote it into Notion as the business plan.
The hero use case they first described: a person or group wants to create a restaurant pop-up, find a place to serve food, hire staff, coordinate a menu, plan a run of show, invite people, and manage attendees (ticketed or not). Then they cut it. Name, start time, and end time may be enough for an event object. Everything else is a product you might never need.
Ask which user flow you will actually run this week. If the answer is “find a kitchen and a room, then get emails,” that is the product. Not staff permissions, not a places marketplace, not OAuth.
Landing page and waitlist first
You are blocked on booking until the site collects emails and states when the thing happens. Wire a domain, a form, and a database before you advertise details.
What they used: a live domain, PlanetScale for storage, Resend for email (Loops was praised, Resend was chosen because it is simple and agents handle it well), confirmation mail from a real domain once DNS is verified. The first form was a throwaway prototype. Do not collect junk just because the hook is live. Redesign around the audience: primary path is guest email signup logged to the database; secondary path is a control for restaurateurs, proprietors, or other people who can help make the event happen.
Design direction from Matt: much more minimal, professional enough to send, waitlist in the main flow. Use the repo as the source of truth for the look once something is checked in, so flyer bots and lander bots are not inventing separate brands.
Auth and admin: keep it dumb on purpose
They talked through GitHub login, Clerk, WorkOS, and Vercel. Clerk has a hobby tier and an MCP that looked agent-friendly. For a prototype they did not trust yet, they chose Vercel deployment protection rather than building OAuth. Only the core team needed access. Do not overbuild auth before you know the prototype is any good.
Do outreach by hand, then wrap a tool around it
The four operational pieces they named: people who can help, a date, a location, and a way to feed guests. Food service and a room are the blockers; guests come after. Finding a caterer about a month out felt more feasible than finding a location.
Matt’s bot path: get a shortlist of businesses with emails and phone numbers (he pulled about 15 kitchen/catering names in Grokbot), configure email so messages come from a human, not a “crazy” agent voice, and start calling. Lauren’s software path: a scrappy venue-finder prototype — map, search, cuisine/location filters, a way to look up the humans behind the restaurant, and a fast path to place a call. OpenStreetMap was the candidate to avoid waiting on a Google Maps key; they could switch later.
A prior Bland MCP voice-agent setup came up. The guidance was not to spam people. Use bots to find numbers; a human should get on the line, or take over immediately.
When you call, capture details by hand at first. That data is how a venue finder gets smarter — size, contacts, whether the vendor already has an alcohol license. Do not pretend the tool has that layer until you have typed it in.
Venue criteria worth encoding
Start from human knowledge, then pattern-match. Matt used places he already trusts (the Pearl, Dogpatch Studios): can they take about 100 guests, and can you control the environment? Avoid government or NPS facilities when the calendar is tight; Fort Mason-style review was cited at 4 to 15 business days and can stretch into weeks. Prefer a venue or caterer that already holds the alcohol license so you are not the one waiting on it. Event insurance plus a venue may be enough if you drop in-house food service.
Budget is unknown until you call. Do not let a bot invent a number.
Cut scope when the domain fights you
Mid-session they considered pivoting from a dining pop-up to an art exhibition: warehouse-flexible space, fewer food and liquor hurdles, local artists, maybe Grokbot-themed work, digital gallery plus in-person show. That is not a growth hack. It is what happens when licensing, staffing, and menu complexity show up before you have a room. Lock the idea before bots keep building the old one. Tell the agents the plan changed.
Marketing follows the same honesty. Nobody cares about your pop-up yet, and nobody wants to hear that it was made with AI. Sell a first-time, time-limited night. Headlines they tested leaned on spontaneity, not features. Guerrilla ideas included top street corners in San Francisco for flyers, limited merch, and an on-site game or experience — parked in a marketing Notion section, not all built at once.
How the bots map to the work
| Use case | Bot / tool | Input needed | Output | Owner |
|---|---|---|---|---|
| PR review | Slack channel + Cursor automation + P-stack | PR links posted to the channel | Review for correctness, risk, missing tests | Engineering |
| Bug triage | Slack bug channel + similar automation | Reports; later, public feedback | Triaged issues, path to PRs | Engineering |
| Verification | P-stack create-verification skill, Tater bot | App under test | CLI, traces, snapshots, later videos | Engineering |
| Bot factory | Dr. Eggbot | A job description for a new bot | Specialized bots | Whoever is dispatching work |
| Operator research | Grokbot research bots | Similar pop-ups, SF restaurants, caterers | Shortlists, emails, phones, Notion notes | CEO / ops |
| Waitlist | Resend (or Loops) + PlanetScale | Guest email; later, helper requests | Database rows, confirmation email | Product |
| Shared memory | Knowledge base manager + Notion | Other bot threads, human decisions | Selective Notion updates | Ops, with a human gate |
| Design / guerrilla | Design bot, marketing bot | Headline, date, repo styles | Lander polish, flyers, street-corner lists | Marketing / CEO |
| Venue finder prototype | Cloud agent (potato mode in-session) | Cuisine, location, call workflow | Scrappy map/search tool, PR videos | Engineering, reviewed by ops |
Prompts, bot instructions, and workflows
These are reconstructed from spoken instructions, not copied from a screen. Keep the “restate in your own words before executing” step. Long voice prompts were already a problem in-session.
Rule to prepend
Restate this in your own words before executing.PR review automation
Reconstructed from the speaker’s description.
When a pull request link is posted in this channel, review it with P-stack.
Check correctness, risk, and missing tests.
Leave a structured review. Iterate this checklist as we see repeated agent mistakes.Create a verification skill
Reconstructed from the speaker’s description.
Use P-stack to run the create verification skill.
Build a standard CLI or script so agents can reliably and deterministically
interact with the application. Do not rely on each bot writing its own script.
Also create a feature map: what features exist, how to reach them, keyboard
shortcuts. Prefer a shared harness so verification is reproducible and cheaper
on tokens.Always-on verification
Reconstructed from the speaker’s description.
Update the verification skill so it is always applied.
If a change has visual impact, agents must include video or screenshots
in the PR. For backend changes, still verify the work even without UI.Waitlist lander
Reconstructed from the speaker’s description.
Redesign the UI to be much more minimalist. It looks bad now.
Orient the page around collecting guests for the pop-up.
Primary: email signup for people who want to join. Log them in the database.
Secondary: a top-right control for restaurateurs, proprietors, or others
who can help us make this happen, so they can submit a request.
Do not keep the current throwaway fields. Collect information that is
actually useful for guests vs helpers.Knowledge base manager
Reconstructed from the speaker’s description.
You are the knowledge base manager.
Watch the other bot conversations. Do not act unless specifically called on.
Wait for messages to come to you.
Update Notion selectively. Do not dump everything.
Check with me first. Use the queue to keep Notion up to date.
Treat the log like a git log, not a transcript dump.Host / venue finder context
Reconstructed from the speaker’s description.
The most important thing when finding a venue is to start from what we know,
pattern match on high quality, then work backwards.
Examples I trust: the Pearl; Dogpatch Studios. Find similar spaces.
Target about 100 guests. The space must fit them and let us control
the experience.
Avoid government-run or NPS facilities; permitting can take a month.
Prefer a venue or caterer that already has an alcohol license so we
are not waiting on that ourselves.
We are also considering a large warehouse / mixed-use space if this
becomes an art pop-up rather than a dining pop-up.Venue-finder prototype
Reconstructed from the speaker’s description.
Using potato mode, create prototypes for a tool that helps us find
restaurants or venues.
It should be easy to make phone calls.
Include a way to look up the people behind the place (manager, etc.).
Imagine a map and search by cuisine or location.
This does not need to look good. It is an internal tool.
Restate in your own words before executing.What to measure while you use AI bots to run the business
The session does not give hours saved, cost per lead, or conversion rates. Use the same qualitative checkpoints they used.
- Are PRs appearing in the review channel with a consistent automated pass, including videos when the UI changed?
- Can an agent verify without asking a human to click through the app?
- Is the waitlist actually writing to the database, and is confirmation email sending from your domain?
- Do research bots produce call lists you would dial (they had ~15 catering names and a street-corner list) rather than generic essays?
- Is Notion gaining a few durable decisions (date, guest count, venue pattern, pivot) instead of a firehose?
- Are agents stuck on auth, connectors, or missing GitHub CLI? That is factory downtime, not model failure.
- Are you still doing the first of each operational loop by hand — the call, the flyer headline, the merge?
If those are red, do not add more bots.
Pitfalls and guardrails
Over-automation is the main failure mode. Voice agents finding numbers is useful; auto-dialing strangers is how you become spam. Emails must sound like a named human. Customer-facing copy should not lead with “we built this with AI.”
Brand and product risk: a vibe-coded form will collect the wrong fields. A lander that never states the date cannot convert. Prototype auth that is open to the world is a problem; prototype auth that takes a week to build is also a problem. They chose the scrappy lock.
Engineering risk: your codebase is memory for the agents. Architecture and stack constraints make them smarter by default. That is not permission to rewrite everything in Rust on day one, add lint rules before you have PRs, or design staff permissions for a platform with no events. Lauren’s bias: it is easier to add strictness later than to over-predict. TypeScript stayed because they already had it and agents work well in it. Go was called a strong agent language; Rust compile times were treated as too slow for this pace. UI stayed out of that experiment.
Your codebase is a form of memory.
Ops risk: government venues and alcohol licensing can blow a one-month date. If the calendar is tight, push licensing onto a vendor or change the format. Scope is the other bomb — each of location, staff, menu, run of show, and ticketing could be its own product.
Memory risk: bots posting into Notion helps other bots, until it is spam. Gate updates. Record decisions (even a voice note fed to a bot) so engineering is not interrupting ops for context.
Humans stay in the loop for: merges, live calls, Notion writes, headline and brand, pivot calls, API key creation, and anything that hits a real inbox or phone.
7-day implementation plan
This follows their ship-by-Thursday cadence and dogfood-first rule, not a generic sprint.
Day 1
Auth Cursor to the org. Connect only the repos you will ship. Create Slack channels for PR review and bug reports. Add the first unsophisticated review automation. Install Dr. Eggbot. Create one research bot and one knowledge base manager with a human gate. Put the working date and the one-sentence offer in Notion.
Days 2–3
Ship a minimal lander: email capture, database, confirmation email. Do not advertise throwaway fields. Start the verification skill so agents can run the app without you. Begin manual research: a shortlist of people and places you would actually call. Stretch goal of making money by day three is optional and was not demonstrated.
Days 4–5
Call. Take notes by hand. Feed venue criteria and objections back into the host-finder bot. Dispatch design and marketing bots only against the repo’s look and the locked date. Configure DNS so outreach can come from your domain. Keep auth dumb (deployment protection is enough if only the team should see admin).
Days 6–7
Review the PR pile with videos on. Tighten the verification skill so it is always on. Kill prototype branches you did not mean to spawn. Only then wrap a tool around a loop you have already done twice — a venue shortlist, a waitlist email, a flyer. If the domain (food licensing, permits, demand) is fighting you, change the offer before you change the schema.
Get the factory taking real operational load this week. Watch the walkthrough for the Slack automations and verification skill, then start with one bot.
FAQ
Do I need a finished product to use AI bots to run a business?
No. The working method is to run the business by hand and only build tools when the manual loop is clear. A waitlist and a call list are enough to start. Building event owners, hosts, maps, and merch before you have a date and a room is how scope explodes.
Grokbot vs Cursor: where should work start?
Start in Grokbot for research, priorities, and job definitions, then move implementation into Cursor against GitHub. That was Matt’s default path. Lauren lived more in Cursor cloud agents, Slack automations, and P-stack. Use both; do not make Cursor your only planner or Grokbot your only coder.
Do I need Clerk or WorkOS for a prototype?
Not at first. They discussed GitHub login, Clerk (hobby tier, agent-friendly MCP), WorkOS, and Vercel. For a prototype they might throw away, they preferred Vercel deployment protection so only the team could see admin. Add a real auth provider when the tool is worth locking properly.
Loops vs Resend for waitlist email?
Both were named. Loops was called a strong platform. Resend was the one they started with because it is simple to stand up and agents handle it well. They also needed domain verification so mail could come from the project domain. Pick the one you can wire today; the session does not compare deliverability.
What is a verification skill and why does it matter?
It is a shared way for agents to run your app, take traces and snapshots, and check their own work. Lauren wanted a standard CLI plus a feature map, not one-off scripts. Without it, every task ends with the bot asking you to click around, which she described as very slow.
Should I automate cold calls with a voice agent?
Not as a spam cannon. A prior Bland MCP setup was mentioned for placing calls. The recommendation in this session was to have bots find phone numbers and research, then have a human dial or take over. Do not skip the manual conversations if you are not yet a domain expert.
How do I keep Notion from turning into spam?
Give a knowledge base bot a narrow job: wait to be called, extract only important details, check with a human, and write selectively. They compared it to a git log. Other bots reading Notion is useful; unfiltered dumps are not.
When should I add lint rules or a stricter stack?
Later. The team treated early lint and a Rust rewrite as overcooking. Watch incoming PRs for repeated agent mistakes, then add constraints. A codebase with clear architecture helps agents, but predicting every rule before you have users is how you slow the factory down.