Use Grok Bot Better Than 99% of People: A Practical Guide to AI Agents

Greg Isenberg
Greg Isenberg
Nov 11, 2026 • 15 min read

The most useful way to think about Grok Bot is not as another place to ask AI questions. It is a place to coordinate work.

I use it for engineering, design, content ideas, business decisions, and shopping. Sometimes it does the task itself. More often, it directs another tool, carries context between tasks, and brings something back for me to review.

That distinction is everything: Grok Bot is my orchestrator, not necessarily my executor. Claude Code handles much of the engineering. Paper handles the design canvas. Connected services provide information or let an agent take action. Grok Bot gives me one surface for managing all of it.

The result is that my phone actually feels useful. I can move projects forward without sitting inside a coding environment all day. More importantly, the agent knows enough about what I am doing that I do not have to start every conversation from zero.

Table of Contents

Key Takeaways

  • Use Grok Bot to orchestrate specialized tools rather than expecting it to execute every task itself.
  • Give serious projects dedicated bots, keep small experiments together, and delete bots that stop being useful.
  • Approve plans and design systems before implementation, then review functionality and security before shipping.
  • Shared context connects engineering, content, finances, and personal tasks without repeatedly explaining your goals.

Start With Context, Not a Giant Collection of Bots

Grok Bot organizes work into bots, each with its own context, skills, and computer. For me, that is easier to manage mentally than a long list of loosely related chat threads.

When I open the Pluto bot, I know I am working on Pluto. When I open my Bible app bot, I am in that project. The name is not just a label. It gives the work a clear boundary.

But that does not mean every idea deserves its own bot. That is how you end up with bot fatigue.

Use a general bot for small ideas

I keep a general engineering bot that knows about my projects and catches random experiments. For example, I built a screenshot extension called Still in two prompts. That did not need a dedicated agent with its own ongoing context.

A general bot is where I can say, in ordinary language, “Here is an idea. Make something that works, push it to GitHub, and I will check it later.”

Give serious projects their own bots

A project gets its own bot when I intend to keep working on it, launch it, or give it sustained attention. Pluto qualifies. My Bible app qualifies. Bezalel, which had reached $200 in monthly recurring revenue at the time of this setup, qualifies.

Some permanent bots serve functions rather than products:

  • IT: Manages my connected machines.
  • ML: Handles local models, downloads, and fine-tuning work.
  • Content: Supports an ongoing publishing workflow.
  • Finance and advisor bots: Keep business decisions connected to my goals.

The deciding factor is how much distinct context the work needs, not whether I can invent another job title for an agent.

And when a bot stops being useful, I delete it. An experiment does not earn a permanent place in the sidebar just because it was exciting for an afternoon.

Engineering: Separate Exploration From Shipping

There are two very different ways I use an engineering agent: exploring an idea and building something people will actually use. Both are valuable, but they should not be confused.

Let the agent explore ideas while you are away

A friend who works in government contracting mentioned AI governance. I know AI; I did not know much about that market. So I asked my bot to find government bids related to AI governance, then asked the engineering bot to make a simple app in that category.

I sent the request at night. By the next morning, there was a repository for an AI governance compliance platform.

Had I run it? No. Did I understand every part of it? Absolutely not. That is the point of the distinction: a generated repository is an exploration artifact, not proof of a finished product.

What changed was the cost of investigating an idea. Instead of leaving it in my head, I had something concrete to inspect.

For real products, review the plan before approving the build

Pluto is a more serious example. We were exploring a direction that would let people use data from their Pluto instance to fine-tune a base model.

A friend and I worked through the idea, and he used Claude Code to turn the proposal into a PDF. I gave that PDF to my agent with a simple request: review it.

I did not ask it to start building.

The agent came back with objections. It thought the direction made sense, but it would not approve the build plan unchanged. It identified issues and suggested a different scope.

From there, the process was straightforward:

  1. I clarified which part of the offering was mandatory.
  2. I added a relevant post that illustrated demand for the product.
  3. The agent revised the plan.
  4. I sent that plan to my friend.
  5. I pasted my friend’s feedback back into the conversation.
  6. The agent revised it again, and I reviewed the result myself.
  7. Only then did I approve the build.

That last step matters. I did not outsource the decision about what we should make. I used the agent to make the decision better informed.

Once I approved the plan, I asked Grok Bot to use Claude Code, run multiple sessions if needed, and work toward the goal. The run continued for hours and returned five working pull requests. People were then testing the feature.

That is a much more useful workflow than “build my idea” followed by blindly accepting whatever appears.

Why Put Grok Bot on Top of Claude Code?

You can go directly to Claude Code or Codex. I use those tools too. The reason I put Grok Bot above them is not that every engineering task requires another layer.

It is that the interface and the broader context make me more productive.

A better interface for managing multiple projects

I have worked through pull requests from my phone while visiting my mom for dinner. I can open a named project bot, give it direction, and let it coordinate the coding session.

That feels very different from trying to remember which generic conversation contains which project. Voice interaction also makes it possible to talk through work instead of typing every instruction.

This is a personal preference, not a claim that one architecture is universally better. But the difference in how often I use it is real.

Engineering does not happen in isolation

One of my projects, VP Cloud, is a Canadian sovereign cloud concept: deploying applications and AI workloads on infrastructure located in Canada.

The agent did more than coordinate implementation. When Canadian GPU costs looked high compared with American alternatives, the project bot had another bot email a provider to ask about a discount. It even mentioned my YouTube audience as a potential reason for a partnership.

I had not suggested that negotiating angle.

This is where a personal agent becomes interesting. A coding tool can help build the product. An orchestrator can connect the product to supplier conversations, costs, emails, and other business work.

That broader capability is useful, but it also makes permissions important. An agent that can contact people or make purchases is operating beyond a code editor.

The same pattern works across very different projects

I also built Terminal, a Rust trading application inspired by the look of a Bloomberg terminal. It has a fast interface and can connect to a brokerage account for live use. I directed the work through Grok Bot rather than writing the code myself.

Another side project explored an engine for synthetic stocks, meaning tokens that mirror stock prices rather than ownership of the underlying shares. I asked the agent to create a separate bot so I could investigate it without mixing that discussion into Terminal.

It surfaced legal considerations and produced a plan in a readable artifact. I could inspect the proposal before asking it to coordinate implementation on a connected server.

Neither example means generated trading software or an exchange concept is ready for unrestricted real-world use. They illustrate how far an agent can carry an investigation and prototype when it has the right tools.

How to Connect Grok Bot and Claude Code

There are two approaches to the engineering setup: the simple route and the networked setup I use.

The simple route: use the bot’s computer

Each bot has a computer. The basic approach is to ask it to help set up Claude Code there, then complete the required installation and authentication steps.

You do not need to begin with a fleet of machines. Start with one bot and one working coding connection.

The advanced route: connect your own machines

I have multiple machines connected through Tailscale, and I use T3 Code as part of the workflow. When I ask Grok Bot to use Claude Code, it can start a session through that existing setup.

I am not a networking expert. I used the agent to help me work through the configuration. That is an important shift: you can ask the agent how to establish the workflow, not just what to do after the workflow exists.

Still, “ask your agent” is a starting point, not a substitute for checking access, authentication, and whether the connection actually works.

Use subscriptions deliberately

My preference in this setup was Claude Code with Opus 5.5. Model preferences can change as better options arrive; the orchestration pattern does not depend on one model staying ahead forever.

I am also aggressive about using subscriptions. My estimate was that the $200 monthly plan could support usage that would cost roughly $8,000 to $12,000 at API rates. That is my comparison, not a promise of API credits or guaranteed usage. Limits and pricing matter.

The practical lesson is simpler: if a subscription fits your budget and removes a meaningful constraint on useful work, learn how to use it well. Buying access is not the achievement. Turning it into tested output is.

Security Is Part of Shipping

It is easy to get excited about five pull requests and forget to ask whether the application is safe.

For serious apps, especially those handling payments or sensitive user information, security review is part of the job. You owe that to the people using the product.

In my own workflow, I also run a separate model with safeguards removed against my applications for defensive testing. That describes my setup; it is not a requirement for getting started, and removing safeguards does not establish that an application is secure.

The accessible starting point is to ask a capable model to review your own application for security issues, with clear authorization and scope. Grok Bot can coordinate that review just as it coordinates other work.

Some tools may restrict security-related requests. Be explicit about ownership, the defensive purpose, and the permitted scope rather than treating those restrictions as something to bypass.

Risk also varies by application. My free Bible app has no login and a much smaller sensitive-data surface than Pluto. That changes the review priorities; it does not make any application automatically immune to problems.

Code generation, testing, and security review are separate responsibilities. Finishing the first does not finish the other two.

Design: Lock the Visual Direction Before Generating Code

One of the biggest mistakes with AI-generated products is going straight from a vague prompt to a coded interface.

Then you spend the next hour explaining why the fonts feel wrong, the spacing is strange, and the whole thing looks like the same purple-gradient template as everything else.

I prefer to solve those problems before implementation.

Turn references into a design system

I use Paper with its MCP connection so the agent can work on the design canvas. I collect inspiration from designers on X and from Mobbin, then give the agent screenshots or references.

The request is not to copy an entire site. It is to create a design system informed by what I like, then adapt it.

A design system is the guidebook the agent should follow. It defines things such as:

  • Fonts and typography sizes.
  • Colors and visual hierarchy.
  • Spacing and layout rules.
  • Button and card dimensions.
  • Shapes and corner rounding.

Without that guidebook, the agent keeps making fresh visual decisions. With it, I have something concrete to approve and reuse across projects.

Example: a Shopify store for a clothing brand

For my brother’s clothing brand, I supplied the clothing designs and asked for a clean storefront. The agent asked questions about the mood, and we worked toward a Christian gothic direction.

It initially used Framer because I had Framer connected. I wanted Shopify, so I clarified the destination.

That is a useful reminder: an agent having access to a tool does not mean it has correctly understood which tool you want used.

We developed the design in Paper. After I was happy with the direction, I connected Shopify and asked the agent to implement the front end.

Use comments as the feedback loop

Paper lets me leave comments directly on the design. I can point to something and say the logo looks wrong, the font does not fit, or the spacing needs work. Then I ask the agent to address the comments.

I do not need expert design vocabulary to give useful feedback.

This is much cleaner than deploying a site, describing a dozen visual problems in a chat, and having the agent repeatedly rewrite code.

My approval stays in the loop for both design and functionality. The extra review step is not wasted time. It prevents wasted implementation.

Context makes small improvements easier too

For Bezalel, I wanted a playful animated demonstration on the homepage. I had shared an animation reference earlier, then later referred to it vaguely as the “animation thingy.” The agent connected that request to the earlier reference and offered to prototype the hero section.

After reviewing it, I noticed it used generic icons where company logos belonged. I asked for logos, reviewed the resulting pull request, and merged it.

The broader visual direction drew inspiration from family.co, then went through its own design-system adjustments. The useful combination was not one magical prompt. It was references, tools, memory, and feedback.

Content: Automate Discovery Without Outsourcing Your Voice

My favorite content bot is not a scriptwriter. It is an idea finder.

At 9 a.m. and 5 p.m., my YouTube bot scans X and sends three topics that fit the kind of content I make.

Each suggestion includes:

  • A topic relevant to my interests and audience.
  • Source posts to investigate.
  • A possible title.
  • Resources I could use to develop the piece.

For my niche, X is particularly useful because so much of the AI conversation happens there. Access felt generous in my usage, although I would not describe that as a guarantee of unlimited API access.

The bot has suggested angles around AI finance features, remote coding agents, developer-tool privacy discussions, and data-center debates. Those are leads to investigate, not reporting I should publish without verification.

I do not use every idea. The value is that I have a steady flow of relevant possibilities and a better sense of what is happening.

Keep the personal part personal

I generally do not use AI to script my videos. People prefer people. An agent can help organize thoughts, but I want the point of view and delivery to remain mine.

Discovery is a different problem. If your community is active on a platform the bot can search, there is no reason to manually reconstruct the entire conversation every day.

Use an editor bot to translate taste into instructions

I also use an editor bot to explore styles and prepare feedback for my human editor. At the time of this setup, none of those experiments had gone live in my own workflow.

I might not know the right terminology for a color grade or transition, but I can say, “This feels too yellow,” or explain the kind of motion I want. The bot helps turn that into a more useful brief.

There is also a practical short-form workflow: record a raw idea on a phone, provide Claude Code with a framework for what makes a good edit, and have it work on the clip. Experiments with that approach had produced short videos reaching hundreds of thousands of views.

The important part is not just access to an editing tool. The valuable input is the framework for what good editing looks like. Pacing, motion, text, and narrative judgment still need direction.

Grok Bot can manage the process, whether the next step belongs to a coding tool, an animation workflow, a narration service, or a human editor.

Business and Finance: Give Your Advisor Enough Context to Disagree

I have a serious case of shiny object syndrome.

One day I want to build software. The next day I am interested in a trucking company, storage units, real estate, or starting an AI lab.

My advisor bot exists partly to tell me to relax and focus.

Connect goals to actual financial information

My setup includes business finance, personal finance, business investor, and personal investor bots. Through the finance connection, which uses Plaid, the bots can access connected account information and transactions.

That lets the advisor compare a new idea against my actual situation instead of giving generic encouragement.

It can remind me that I said I was saving for something, that a purchase would pull cash from another goal, or that a new project does not fit the current business.

This is sensitive access. The benefit comes from context, but connecting financial accounts is a separate permission decision, not something to do casually.

Example: talking me out of a property

I sent the advisor a real estate listing. It pushed back for several specific reasons:

  • The property was an investment building, not the home I was saving toward.
  • Buying it would divert cash from other priorities.
  • The seller wanted unrepresented buyers only, which deserved scrutiny.
  • The boiler and furnace dated to 2009, creating a potential future replacement expense.

The useful part was not that a bot had issued a verdict on real estate. It had connected the listing to my goals and highlighted details worth checking. I still own the decision.

Use the same context to evaluate opportunities

I have also used bots to scan Canadian government contracts. Because they know something about my business, they can help distinguish an opportunity that fits from one that would require hiring or capabilities I do not have.

This is why the orchestration layer matters. Engineering, design, finances, customers, and content are related.

A fresh coding session may not know what my business earns or whom it serves. A contextual agent can bring that information into a product decision. It can also remember that I already have a Paper design system suitable for a new project and suggest reusing it.

The win is not more disconnected automation. It is less repeated explanation.

Shopping: Delegate the Research, Keep Approval Where It Matters

Shopping is where the idea of an agent as an interface to the internet becomes very concrete.

I have used Grok Bot to scan eBay for sealed GPUs and send listings daily. Instead of repeating the same search, I get candidates that match what I am looking for.

A PS5 Pro purchase with a human checkpoint

For a PS5 Pro, the bot found an eBay listing, emailed the seller, and learned that the seller was a store in Ontario about two hours away.

It gave me a phone number and a suggested script. I called the store myself and confirmed the details. After I granted access, the bot completed the purchase.

The workflow combined search, seller communication, human confirmation, and an authorized transaction. It did not require me to personally do every click.

Bring another person into the decision

I also asked it to research shoes because I was experiencing sciatica discomfort. Then I had it email the options to my wife, who has much better judgment about what I should wear.

She picked a few, and the bot returned the approved list.

That is shopping assistance, not a medical assessment. What made it useful was coordinating the research and the style approval without making me manage the whole exchange.

Increasingly, I describe the outcome I want rather than opening pages and doing every intermediate step myself.

A Simple Setup You Can Copy Today

You do not need my entire collection of bots, machines, and side projects. Start with one workflow that solves a real problem.

  1. Create one general engineering bot. Use it to collect small ideas and explore prototypes.
  2. Choose one serious project. Give it a dedicated bot and supply the relevant plans, references, and decisions.
  3. Connect the execution tool. For engineering, get Claude Code working before attempting a more elaborate network.
  4. Ask for a review before a build. Let the agent question the plan, then make your own decision.
  5. Approve the design before implementation. Use a design system and a clear feedback loop.
  6. Review the output. Inspect the work, test functionality, and make security review part of serious releases.
  7. Add other workflows only when useful. Scheduled content research or shopping research can come later.
  8. Delete what stops serving you. More bots are not the goal.

The prompts do not need to sound like legal documents. I often use casual language because the project context is already there. Plain language works much better when the agent knows what we are talking about.

Think Bigger, Then Actually Try Something

The most exciting part of this is not another software dashboard. It is being able to attempt things that previously stayed in your head.

I have been experimenting with hardware using a Raspberry Pi, speakers, and other components. I am not a hardware expert. I ask what to connect, what part I need, and how to make the next piece work.

That does not erase expertise. It gives me a way to learn while building.

There is plenty of negativity about software, AI, and whether ordinary people still have an opportunity. You can spend all day absorbing it, or you can pick a problem and make a serious attempt.

Use Grok Bot to coordinate the work. Use specialized tools to execute it. Keep your judgment in the loop.

Then build something worth using.

Share

Greg Isenberg

I share startup ideas, practical AI workflows, and step-by-step playbooks to help you build products and get customers.

© 2026 Greg Isenberg
Powered by Convella