Skip to content
Bot jobsJob breakdowns

Don't Chat With It, Staff It: How I Get Real Work Out of Grok Bot

I build TypeAide, an AI keyboard for iPhone and iPad. Working alone means I'm also the marketing department, the support desk, the release manager, and the person who's supposed to keep an X account

Fd Imported from X15 min read
richomigax article
See this runHouse 556 · 00774

Article

Job breakdowns

I build TypeAide, an AI keyboard for iPhone and iPad. Working alone means I'm also the marketing department, the support desk, the release manager, and the person who's supposed to keep an X account alive. Most of those jobs don't get done well. They get done when I find the time.

For the past few weeks I've been handing a lot of that work to Grok Bot. I didn't get much out of it the first few days, because I used it like a chatbot: type a question, read the answer, copy the parts I liked. Things changed once I started treating it like staff. A few bots, each with a clear job, sharing one computer and doing the work all the way through.

For the past few weeks I've been handing a lot of that work to Grok Bot. I didn't get much out of it the first few days, because I used it like a chatbot: type a question, read the answer, copy the parts I liked. Things changed once I started treating it like staff. A few bots, each with a clear job, sharing one computer and doing the work all the way through.

This is the playbook I wish I'd had on day one. It isn't a feature tour, and I've tried to stick to things I've done myself or things the official docs say. Where I'm guessing, I'll tell you.

This is the playbook I wish I'd had on day one. It isn't a feature tour, and I've tried to stick to things I've done myself or things the official docs say. Where I'm guessing, I'll tell you.

The mental model: a team with a shared computer, not a chatbot

Here's the one idea that matters most.

In Grok Bot you create Bots: named teammates, each with its own chat, its own memory, and its own job. The docs describe them as "AI teammates with names, jobs, and context that compounds over time." Each Bot works on a persistent cloud computer with a browser, a filesystem, and a terminal. That computer keeps running when your laptop is closed.

In Grok Bot you create Bots: named teammates, each with its own chat, its own memory, and its own job. The docs describe them as "AI teammates with names, jobs, and context that compounds over time." Each Bot works on a persistent cloud computer with a browser, a filesystem, and a terminal. That computer keeps running when your laptop is closed.

The part that took me a while to get: all of your Bots share that one computer. Files, browser sessions, and logins are shared. Each Bot gets its own screen on it, so several can browse at once without stepping on each other. Bots can also message each other and hand work off, so you don't end up copying notes between chats.

So the right picture isn't "a smarter search box." It's a small office. There's one shared machine in the corner, a few specialists who each own a lane, and you as the manager who sets direction and signs anything that goes out the door. The launch post says the same thing in its own words: "a chief of staff sits on top, with a specialist for each lane."

So the right picture isn't "a smarter search box." It's a small office. There's one shared machine in the corner, a few specialists who each own a lane, and you as the manager who sets direction and signs anything that goes out the door. The launch post says the same thing in its own words: "a chief of staff sits on top, with a specialist for each lane."

Once that clicked, the useful habits mostly followed from it.

11 practices that actually made a difference

  1. Give each bot one job

My current roster:

  • One bot per Mac. Each one handles work on its own machine, so I always know which machine I'm talking to.

  • A GitHub bot for repo and issue work.

  • An X research bot that digs through public posts and accounts.

  • A design bot for app appearance: icons, screenshots, visual polish.

  • A growth bot whose only job is growing my X account. It's the one that helped write this.

Grok Bot's getting-started guide recommends this directly: give each Bot "one primary job in its first message," because "a focused Bot builds more useful context than one catch-all helper." In practice, a focused bot gets better over time. My growth bot already knows the account, its voice, and its history. When I ask for a post, I don't have to explain any of that again.

Grok Bot's getting-started guide recommends this directly: give each Bot "one primary job in its first message," because "a focused Bot builds more useful context than one catch-all helper." In practice, a focused bot gets better over time. My growth bot already knows the account, its voice, and its history. When I ask for a post, I don't have to explain any of that again.

One caveat from the docs that's worth repeating: separate bots are not a security boundary. They share the computer, so anything one bot can reach, the others can reach too. Split bots by job, not by secrecy.

  1. Write your lasting preferences down once

Bots keep stable preferences across chats. The FAQ says a Bot "can retain stable preferences, role context, and summaries of prior work."

Bots keep stable preferences across chats. The FAQ says a Bot "can retain stable preferences, role context, and summaries of prior work."

So I state the rules that shouldn't change, once, and ask the bot to remember them. My X persona is English-only, and all long-form content is in English. I often think and type in Chinese, so I told the growth bot: even when I ask in Chinese, everything for this account is written in English. I haven't had to repeat it since.

Good candidates for preferences you write once: voice and tone, language, what you never say publicly, what counts as done, and what always needs your sign-off.

  1. Hand over outcomes, not steps

The worst prompt I wrote early on was a numbered list of clicks. The best ones read like a brief to a contractor: what I want, why, what good looks like, and where to stop.

Here's a real one. I asked my growth bot to audit my X account using only public data. I didn't tell it what to look at. It came back with things I'd been too close to notice:

  • My bio didn't match what the account actually posts about.

  • I had no pinned post, so new visitors had nothing to start with.

  • Some of my posts were in Chinese or political, which is off-persona for an English-language indie dev account.

  • The surprising one: early replies under big accounts got about 13x the reach of my normal posts. One reply got 441 impressions. My typical post gets around 34.

That last finding changed how I spend my time on X. It's a small sample from one account, so I treat it as a hypothesis to test, not a law. But I'd never have pulled it out myself, because I'd never have sat down and lined up my own numbers.

  1. Connect the tools you really use

Bots work best when they can reach your actual tools instead of guessing. Grok Bot supports connectors for things like Gmail, Google Calendar, Slack, Notion, GitHub, Figma, Google Docs, Sheets, and Slides, Firebase, and X. The Connect apps help page explains the model: a connector "uses the account you authorize" and "can do only what that account can already do."

Bots work best when they can reach your actual tools instead of guessing. Grok Bot supports connectors for things like Gmail, Google Calendar, Slack, Notion, GitHub, Figma, Google Docs, Sheets, and Slides, Firebase, and X. The Connect apps help page explains the model: a connector "uses the account you authorize" and "can do only what that account can already do."

Two things worth knowing. Connections are account-wide, so every Bot can use them. And Gmail connects one mailbox at a time. If a bot shouldn't touch a mailbox, don't connect it.

The docs also say to prefer a connector when one exists, because it's "often more reliable than clicking through a website." That matches what I've seen.

  1. Use its computer for sites without a connector

For everything else, there's the browser on the bot's computer. It can sign in and work on websites that have no clean API. The launch post calls these "platforms with no clean API or MCP."

You don't hand over your passwords to make this work. When a site needs a login, the bot either gives you control of the computer so you can sign in yourself, or shows a secure form in the chat. The approvals and security docs are explicit: don't paste passwords or one-time codes into the chat. When my bot tried to sign into X, it used an in-chat form, so I never pasted a credential into the conversation. Once you're signed in, the session stays on that computer for next time.

You don't hand over your passwords to make this work. When a site needs a login, the bot either gives you control of the computer so you can sign in yourself, or shows a secure form in the chat. The approvals and security docs are explicit: don't paste passwords or one-time codes into the chat. When my bot tried to sign into X, it used an in-chat form, so I never pasted a credential into the conversation. Once you're signed in, the session stays on that computer for next time.

You can watch it, too. Click the bot's name in the chat header (or press Cmd+Shift+I) to open its info pane. It shows a live preview of that bot's computer, and clicking the preview opens the full screen.

  1. Let it work in parallel, and change course mid-flight

A bot isn't a one-request-at-a-time terminal. While I was working with my growth bot, I had it running two tasks at once. Partway through, I switched the language I was writing in. It switched with me and kept both tasks going without losing track of either.

Across bots it's the same. My X research bot can be digging through accounts while the design bot works on screenshots and the growth bot drafts posts. Each one is on its own screen on the shared computer, and they can message each other when their work overlaps.

The habit to build: don't wait. If a task will take a while, start the next one in another bot, or in the same one. Check back when it reports.

  1. Turn repeat work into routines

A routine tells one Bot when to run a job: on a schedule, or when something happens. The routines help page lists triggers like Slack messages, GitHub events, email, and webhooks. You set one up by asking in plain language, for example: "Every weekday at 9:00 AM, summarize new support tickets in this chat." Routines run in the cloud while your laptop is closed.

A routine tells one Bot when to run a job: on a schedule, or when something happens. The routines help page lists triggers like Slack messages, GitHub events, email, and webhooks. You set one up by asking in plain language, for example: "Every weekday at 9:00 AM, summarize new support tickets in this chat." Routines run in the cloud while your laptop is closed.

Daily digests and monitors are the obvious place to start. Each bot's routines show up in its info pane, under the computer preview.

Two pieces of advice from the skills and routines docs that I'd underline:

Two pieces of advice from the skills and routines docs that I'd underline:

  • Automate preparation before execution. Have the routine draft, summarize, or recommend. Don't have it send.

  • Watch the frequency. Every run uses part of your weekly usage. The docs warn that an hourly schedule or a busy Slack trigger "can use a week of usage in a day." If usage drops fast, check Settings → Usage & Billing, then widen schedules and narrow triggers.

  1. Save workflows that work as skills

A skill is a reusable set of instructions for how to do a task: steps, decision rules, expected output, and what needs approval. Skills are shared across all your Bots. The docs suggest an order I now follow: "Start with a one-time task. Make it reliable, save the method as a skill, and only then automate it."

So when a task goes well, my next message is often: "Save what we just did as a skill. Include the inputs, the checks, the output format, and the rule that nothing goes out without my approval." The next time I or any of my bots does it, the method is already written down.

You can also show a bot how you do something by walking through it once, and it turns the demo into a draft skill. That feature is rolling out gradually, according to the docs, so you may not see it yet.

  1. Keep a human on every send

This is the rule I won't bend. Anything that goes out under my name, whether it's a post, an email, or a Slack message, waits for me.

The good news is that Grok Bot leans this way already. My bots ask before anything goes out under my name, and they draft by default. For email and Slack, the conversation shows an editable draft card: you check the recipients and the text, then choose Send or Discard (docs).

The good news is that Grok Bot leans this way already. My bots ask before anything goes out under my name, and they draft by default. For email and Slack, the conversation shows an editable draft card: you check the recipients and the text, then choose Send or Discard (docs).

You can make it stricter. Open Settings (Cmd+,) → General → Auto-review and add narrow Ask first rules. The docs' own example is "Ask first before sending any external email." And put boundaries in the request itself: draft it, don't post it; show me before and after. One line in the security docs is worth remembering: an approval "does not reverse work already completed." So set the boundary before the bot does the work, not after.

  1. Ask for sources, then verify

A bot that writes fluently can be fluently wrong. So I make sourcing part of the brief.

When I had my growth bot research Felix Rieseberg's post How to be more ambitious and write a stronger response, I asked for a sourced essay. I got back about 4,000 words with every number and quote linked to a source, plus a promo post and a thread. Two things made me trust it more:

When I had my growth bot research Felix Rieseberg's post How to be more ambitious and write a stronger response, I asked for a sourced essay. I got back about 4,000 words with every number and quote linked to a source, plus a promo post and a thread. Two things made me trust it more:

  • It flagged two sentences written in my voice, claims about my own experience, and asked me to confirm them instead of assuming.

  • It didn't invent any TypeAide metrics. When it didn't have a number, there was no number.

That's the behavior you want, and you can ask for it out loud: "Link every factual claim. Flag anything about me you can't verify. Never make up numbers." Then actually click a few of the links. The FAQ gives similar advice: for important decisions, ask the bot "to check the current source rather than relying on memory."

  1. Run small experiments, not big bets

The fastest way to learn what a bot is good at is to give it small, real jobs with a clear finish line, then look at what comes back.

My account audit was one. Another was a cover image: I asked for one cropped to the 5:2 size X Articles use, and it came back already cropped. A follow-up asking for captions took one more message. Neither one was risky, and both showed me where the bot was strong and where I needed to review its work.

Once a small job works reliably, it becomes a candidate for a skill. Once a skill works reliably, it becomes a candidate for a routine. That ladder is how my use of it grew.

A few more things it can do

Some capabilities I've used less but that are worth knowing about:

Work on your own Mac, with approval. The cloud computer is separate from your laptop. A bot only runs commands on your local machine when you've turned that on and approve it. The setting lives under Settings → Computer (docs). This is why I have one bot per Mac.

  • Work on your own Mac, with approval. The cloud computer is separate from your laptop. A bot only runs commands on your local machine when you've turned that on and approve it. The setting lives under Settings → Computer (docs). This is why I have one bot per Mac.

Hand repo work to cloud coding agents. For well-defined code changes, a bot can launch cloud coding agents to do the implementation. The Team Bots announcement describes a bot that "launches Cloud Agents to handle well-defined fixes." My GitHub bot is the one I'd point at this.

  • Hand repo work to cloud coding agents. For well-defined code changes, a bot can launch cloud coding agents to do the implementation. The Team Bots announcement describes a bot that "launches Cloud Agents to handle well-defined fixes." My GitHub bot is the one I'd point at this.

  • Reach it from your phone. The same bots and conversations sync to the mobile app, so you can check on something or approve a draft while you're away from your desk.

Pitfalls and limits

Sites can rate-limit or block it. This one happened to me. I asked my growth bot to publish an article to X through its own browser. Sign-in went through the secure in-chat form, but X rate-limited the login. The bot didn't keep hammering the site or look for a way around it. It told me plainly what had happened, then made a phone-friendly HTML version of the article with the title in its own copy box, so I could paste it in and post it myself. The FAQ says a site "may still block automation, require a new login, present a CAPTCHA, or require human confirmation," and the bot "should hand those steps to you rather than bypassing them." Plan for that. The last step on some sites will be yours.

Facts still need checking. Sourced output is easier to check, but it isn't automatically right. Click the links on anything you'll publish, especially numbers.

Memory isn't the source of truth. Bots remember your preferences, but for anything that changes, like prices, policies, or current numbers, ask them to look again.

Don't hand over your judgment. A bot can tell you replies under big accounts got 13x the reach. It can't decide whether you want to be the kind of account that does that all day. Positioning, what you say publicly, and what your product stands for are still your calls. Use the bots to see more clearly, then decide yourself.

Shared computer means shared access. Every bot can see the same files and logins. Don't put anything on that computer that a bot shouldn't be able to use.

Usage is finite. Routines and parallel work feel free, but they aren't. Check usage weekly in the first month until you know your patterns.

Your first week: a starter setup

If I were starting over, this is what I'd do.

Day 1: One bot, one job. Use the first bot you're given for one real job you keep putting off. In the first message, describe the job, the boundaries, and how you want it to work, then ask it to remember all of that.

Day 2: Write your standing rules. Language, voice, things you never say, and the rule that everything going out under your name is a draft first. Then add an Ask first rule in Settings → General → Auto-review for sending external messages.

Day 3: Connect two tools you really use. Pick ones you live in, like Gmail and Calendar, GitHub, or Notion. Give it one small task that needs them.

Day 4: Give it an audit. Ask it to review something you own, using public or connected data: your X profile, your App Store page, your open issues. Ask for findings with evidence and sources.

Day 5: Add a second bot. Give it a different job, like research or design, and have the two hand something off.

Day 6: Save one skill. Take the task that went best this week and ask the bot to save it as a skill.

Day 7: Add one routine, then check it. Pick something low-risk and draft-only, like a morning digest. Test it, look at the result, and check your usage.

By the end of the week you'll have two specialists, a handful of written-down preferences, a skill, and a routine. That's a real setup, not a demo.

Closing

The shift for me wasn't that the AI got smarter. It was that I stopped treating it as something to talk to and started treating it as staff I manage. Give each one a clear job. Write down the rules once. Hand over outcomes. Ask for sources. Keep my own hand on anything that goes out under my name.

I'm still a solo developer. But on a good day, I'm a solo developer with a researcher, a designer, a growth person, and someone watching each of my machines. They share a desk, they remember how I like things done, and they don't post anything until I say so.

That last part is why I trust them with the rest.

References

Submit a Bot JobAll articles

Published on grokbot.sh. Cite the public log, not a prompt pack.

Command Menu