Building a Grok Bot Army: The Ultimate Guide for Small Businesses

I feel like we’re in the “Not another one” phase of the personal AI bot era. First we had OpenClaw (Clawdbot as it was initially called) and that took off, until everyone realized it was crap and then it died. Then Hermes came along and that became the new darling. It’s a lot better but still requires a bit of work to set up.

Grok Bot is the latest, launched last week by the folks at xAI/SpaceX/Cursor/whatever they’re called. And it’s hard not to look at all the clown car AI influencers saying “this changes everything” like they do every time a new product comes along and brush this off as another flash in the pan.

But I think this might be the real thing. Or at least the start of it.

I’ve tried them all to the point that I’ve built my own version of it because none of them worked well enough. And in doing so, I’ve realized something. It’s not the bot itself, it’s the context you give it.

None of them will work for your business the way you want it to if it doesn’t understand how your business works, no matter how easy it is to set up. And Grok Bot is by far the easiest to set up.

Download the app, open it up, and in 5 minutes you can create a sales Bot, a recruiting Bot, a website Bot, and a chief of staff to coordinate the lot. You do not need to write code or buy a separate Mac Mini. You message a Bot like you would message a colleague, sign it into the tools it needs, and give it work.

That is the easy part. The hard part is teaching it your business.

What do you sell? Who do you sell it to? Which customers matter right now? Where does the current deal stage live? What does a good proposal look like? What always needs your approval? When should a stalled lead get chased? Which document wins when two sources disagree? What may the Bot do alone, and where must it stop?

I have spent the last year building this layer for my own company. I call it Refound OS. It holds our company context, client histories, pipeline, tasks, follow-ups, operating rules, and approval boundaries.

That is the idea behind this guide:

Grok Bot makes AI teammates easy to create. Your company operating system is what makes them useful. Build the OS first, then add Bots.

By the end, you will have a lightweight company OS, a useful first Chief of Staff Bot, a safe way to add specialist Bots, and a five-day sprint for putting the system to work.

What Grok Bot actually is

Grok Bot launched in early beta on August 11, 2026. xAI describes it as a team of always-on agents with their own cloud computer. They sign into the tools and websites you already use, complete jobs across them, and return when they need your approval.

The product has a few important building blocks:

• Bots are persistent, named AI teammates. They retain conversation context and learn how you like work done.
• The cloud computer lets them use browsers, files, apps, and websites while your laptop is closed.
• Plugins connect services such as Gmail, Notion, and Slack directly. Cursor’s plugin guide covers the current connection flow.
• Computer use covers tools without a clean API or MCP integration. The Bot works through the interface like a person would.
• Routines turn demonstrated, corrected work into something the Bot can repeat or run on a schedule.
• Multi-Bot coordination lets Bots message one another, share context in threads, and coordinate in group chats.
• Approvals bring you back when a task needs judgment or a consequential action.
• Desktop and mobile access let you hand off work at your desk and check it from your phone. Mobile support is currently iOS only.

The difference is the last mile. A normal chatbot can draft a follow-up. Grok Bot can read the call notes, update the CRM, create the follow-up draft in the right inbox, and tell you it is ready to approve.

The official launch examples include a sales Bot that updates CRM records from transcripts, an operations Bot that onboards new hires and processes invoices from Gmail, and an engineering Bot that reproduces a bug, files a ticket, and hands it to a debugging Bot.

Grok Bot versus chat and traditional automation

Traditional automation still wins when every step must be deterministic. If an invoice always arrives in the same format and must always enter the same accounting fields, an API workflow gives you better speed, logging, and control.

Grok Bot gets interesting when the work crosses four different tools, contains judgment, and does not fit neatly into a flowchart. Think meeting preparation, account research, inbox triage, campaign planning, or chasing missing information across portals.

How much Grok Bot costs

As of August 19, 2026, the public pricing page lists three access paths:

Cursor Pro and Pro+ do not currently include Grok Bot. Paid access uses a weekly allowance. The free trial combines a seven-day window with a usage credit, and Cursor warns that one large run can consume most or all of it.

The mistake: building a Bot roster before a company brain

The first thing most people will do is create a fleet.

Sales Bot. Marketing Bot. Inbox Bot. Finance Bot. Website Bot. Perhaps a cheerful Chief of Staff Bot wearing the digital equivalent of a waistcoat.

Then the problems begin.

The sales Bot has one version of the ideal customer. The marketing Bot has another. The website Bot uses positioning from six months ago. The inbox Bot remembers that a particular client is important, but nobody knows why. Two Bots update the same spreadsheet. A third uses an old proposal as the pricing source. The chief of staff confidently summarizes the confusion.

This is not a model or bot problem. It is an operating-design problem.

A fleet does not become a company because the Bots can message one another. It becomes a company when they share truth, methods, and rules.

I learned this while building Refound OS. Each agent needed the same context: what Refound does, who our clients are, how our pipeline works, what counts as a stale deal, where our documents live, how we communicate, and what needs my approval.

Repeating that context in every agent created drift. So I moved it out of the prompts and into the company itself.

Refound OS now has a simple constitutional rule:

Structured information that changes over time lives in a system of record. Long-lived written context lives in maintained documents.

Deals, tasks, activities, and follow-ups are structured state. They live in our database. Company strategy, client context, and operating rules are narrative. They live in documents. Agents read both and write changes back to the correct place.

You do not need a database to get started. We’re going to set you up with a lightweight version.

Build the lightweight company OS first

Create one shared location called My Company OS. It can live in Google Drive, Notion, SharePoint, Dropbox, or a repository. Use this structure:

My Company OS/
├── COMPANY.md
├── SYSTEMS-OF-RECORD.md
├── APPROVALS.md
├── CURRENT-PRIORITIES.md
└── templates/
    ├── email-examples/
    ├── proposals/
    └── briefs/

Markdown is convenient because it is portable and easy for models to read, but any other format works - Google Docs, Notion, obsidian, whatever.

1. Create COMPANY.md

This is the front door to the business. Keep it short. One or two pages is enough.

It should tell the Bot what the company does, who it serves, what matters now, and where to find deeper truth. It is a router, not an attempt to pour the entire company into one enormous prompt.

Copy this:

---
owner: [Name]
status: approved
last-reviewed: [YYYY-MM-DD]
---

# [Company Name]

## What we do

[One clear paragraph describing the company, its customers, and the outcome it sells.]

## Our current offers

- [Offer]: [Who it is for, what it delivers, important constraints]
- [Offer]: [Who it is for, what it delivers, important constraints]

## Who we serve

- Primary customer: [description]
- Strong fit signals: [list]
- Poor fit signals: [list]

## Current priorities

1. [Priority]
2. [Priority]
3. [Priority]

Current priorities are maintained in: [link to CURRENT-PRIORITIES.md]

## Team

- [Person]: [role, responsibilities, time zone]
- [Person]: [role, responsibilities, time zone]

## How we communicate

- Voice: [direct, warm, technical, concise, etc.]
- Prefer: [specific examples]
- Avoid: [specific examples]
- Approved examples: [link]

## Canonical company documents

| Topic | Source | Owner | Consult when |
|---|---|---|---|
| Strategy | [link] | [name] | Planning or representing the company |
| Offers and pricing | [link] | [name] | Proposals, sales, or website copy |
| Customer profile | [link] | [name] | Lead research or qualification |
| Brand and voice | [link] | [name] | External communication |

## Operating rules

1. Retrieve only the context needed for the current task.
2. Prefer current canonical sources over memory and previous AI output.
3. If sources conflict, show the conflict and their dates.
4. Never invent a customer fact, price, deadline, or approval.
5. Write durable changes back to the system that owns them.
6. Follow the approval rules in [link to APPROVALS.md].

The temptation will be to add everything. Resist it. Your refund policy belongs in the policy document. Your current pipeline belongs in the CRM. Your Bot only needs to know where those things are and when to retrieve them.

2. Map your systems of record

Now create SYSTEMS-OF-RECORD.md.

This may be the most useful file in the whole setup. It stops a Bot from treating its own memory, an old email, and your accounting platform as equally trustworthy.

# Systems of Record

| Information | Authoritative source | Read rule | Write rule |
|---|---|---|---|
| Customers and deal stage | [CRM or sales sheet] | Read current record | Preview changes before writing |
| Company documents | [Drive/SharePoint/Notion] | Prefer approved current version | Save approved documents here |
| Email and meetings | [Gmail/Outlook/Calendar] | Read relevant full threads/events | Draft first; external actions require approval |
| Tasks and commitments | [Asana/Linear/Trello/sheet] | Read current owner and due date | Update after approval; verify result |
| Website | [GitHub/CMS] | Read current source | Create preview; approval before publish |
| Accounting | [Xero/QuickBooks] | Treat as financial truth | No payment, deletion, or reconciliation without approval |
| Agent continuity | Grok Bot memory | Use for preferences and ongoing work | Never use as authoritative company state |

## Conflict rules

1. The named system of record wins over agent memory.
2. A current approved policy wins over an old email or draft.
3. If two authoritative sources conflict, stop and show both.
4. Do not silently repair a conflict by guessing.

Notice the final row. Memory is useful. It helps a Bot remember your preferences, ongoing work, and recent corrections, but it is not a ledger. If another human or Bot must rely on a fact, store that fact somewhere shared and maintained.

3. Write the stop signs

Create APPROVALS.md. Keep it blunt.

# Approval Rules

The following actions always require human approval:

1. Send an external email, message, or form submission.
2. Publish or schedule public content.
3. Spend money or change a budget.
4. Delete a record, file, account, campaign, or workflow.
5. Change permissions, credentials, or security settings.
6. Accept a contract, legal term, refund, discount, or pricing exception.
7. Change a production system or deploy publicly.
8. Create a commitment, deadline, or promise on someone's behalf.
9. Add a person to an outreach campaign.

For an approval request, show:

- The exact proposed action.
- The target person, record, or system.
- The content or values that will be submitted.
- The source used to prepare it.
- The expected consequence.

After an approved write, reread the destination and confirm the final state.

This is a fairly strict approval policy to start with, and I personally like to keep it that way. But you may relax this over time.

4. Add current priorities

Your company context describes what stays true. Priorities change.

Create a short CURRENT-PRIORITIES.md and review it weekly:

# Current Priorities

Last reviewed: [date]
Owner: [name]

## This quarter

1. [Outcome, owner, target date]
2. [Outcome, owner, target date]
3. [Outcome, owner, target date]

## This week

1. [Specific action]
2. [Specific action]
3. [Specific action]

## Explicitly not a priority

- [Tempting distraction]
- [Paused initiative]

## Known risks or blockers

- [Risk, owner, next decision]

Set up Grok Bot for your business

The official setup is simple: download the app, sign in, and create a Bot.

Step 1: Create the Chief of Staff

Use something like:

• Name: Whatever you want to call it.
• Title: Chief of Staff
• Description: The Bot’s permanent operating instructions.

The description is where you put the kind of context that would normally live in CLAUDE.md or AGENTS.md:

You are the Chief of Staff for [Company].

Before doing company work, read [link/path to COMPANY.md]. Use it to locate
only the authoritative context needed for the current task.

Read [link/path to SYSTEMS-OF-RECORD.md] before deciding which source is
authoritative or where a durable change belongs.

Follow [link/path to APPROVALS.md] before taking any external or consequential
action.

Treat memory as continuity, not authoritative company data. If sources are
missing or conflict, show the problem instead of guessing.

That gives the Bot its role and tells it how to navigate the company OS every time it works.

Step 2: Ask it to plan your day

Your first message can be this simple:

Plan my day. Review my calendar, inbox, current priorities, and open tasks or
commitments. Tell me what needs my attention, prepare me for my meetings, and
recommend the one thing I should do first.

Do not send messages or change anything without my approval. Show the source
behind every deadline, commitment, and customer fact.

You do not need to connect every tool in advance. Grok Bot will ask for access to Gmail, Calendar, your task system, or the files containing your company OS as it needs them. Grant the minimum access required for this job and continue.

Then inspect the result. If it uses the wrong fact, fix the authoritative document. If it chooses the wrong priority, fix CURRENT-PRIORITIES.md or tighten the Bot description. If it misunderstands how the job should work, correct it in the conversation and run it again.

Step 3: Turn it into a daily routine

Once the brief is useful, ask Grok Bot to repeat it:

Turn this into a routine that runs every weekday at 6:30 AM
America/Vancouver. Use current sources and deliver the brief in this thread.
If a source is unavailable, say which one failed instead of reusing old data.
Do not send messages or make external changes.

That is the whole setup: define the teammate, give it a real job, grant the tools it requests, correct the work, and turn the working version into a routine.

A specialist Bot for every part of a small business

Once the Chief of Staff reliably uses the company OS, you can add specialist Bots. The Chief of Staff coordinates across the business. Each specialist owns one function with its own context, tools, outputs, and approval boundaries.

This is a menu, not a launch checklist. Do not create all eight on Friday afternoon and spend Monday managing the confusion. Start with the function creating the most drag, get one real workflow working, and add the next Bot when the boundary is clear.

I already run versions of several of these systems at Refound. The others follow the same operating model.

1. Social Media and Marketing

Grok Bot can connect directly to your X account, which makes social media a natural specialist job. It can monitor relevant conversations, turn current priorities into campaign and post ideas, draft useful replies, and publish the exact posts you approve.

Point it to your positioning, target customer, current offers, marketing calendar, approved examples, recent posts, and claims it must never make. Otherwise it will produce the same generic marketing sludge as every other AI account.

Its lane: campaign planning, social listening, drafting, scheduling approved content, and reporting performance.

Its stop signs: unapproved publishing, private messages, unsupported claims, deleting posts, and changing ad spend.

2. Sales

My lead-sourcing system searches for companies matching our ideal customer profile, scores them, filters exclusions, deduplicates them against existing contacts, finds the right people, and prepares outreach. A Sales Bot can also prepare meeting briefs, update CRM records, draft follow-ups, flag stalled deals, and assemble proposals from approved material.

It needs your customer profile, fit and anti-fit signals, pipeline definitions, offer and pricing sources, existing accounts, approved proof, and sales process. It should treat the CRM as pipeline truth and email as communication history, not mix the two together in its memory.

Its lane: research, qualification, CRM hygiene, meeting preparation, follow-up drafts, pipeline reviews, and proposal preparation.

Its stop signs: sending outreach, inventing contact data, changing commercial terms, moving or closing deals without evidence, and making promises on your behalf.

3. Website

Our website lives in a separate codebase. A Website Bot can take an approved brief, edit the site, run checks, inspect the result, create a preview, and prepare the release.

Its description should point it to the approved offer, brand voice, website source, analytics definitions, and publishing checklist. The preview is the deliverable. Production remains a separate approval.

Its lane: implement approved briefs, verify desktop and mobile behavior, fix routine content issues, and prepare previews.

Its stop signs: production publishing, unapproved claims or pricing, page deletion, and changes to analytics, domains, credentials, or permissions.

4. Operations and Delivery

This is the function most Bot rosters forget, even though it is where the business does the work customers paid for. An Operations and Delivery Bot can turn a signed scope into a project plan, prepare kickoff material, track dependencies, chase missing inputs, update task systems, assemble status reports, and flag work at risk.

For a service business, point it to scopes, delivery templates, project records, and client communication rules. For a product business, the same role can monitor orders, inventory exceptions, fulfillment issues, and supplier dependencies.

Its lane: planning, coordination, status reporting, task updates, bottleneck detection, and preparation of client deliverables.

Its stop signs: changing scope, committing to dates, contacting customers, approving substitutions, issuing credits, and marking work complete without evidence.

5. Hiring

A Hiring Bot can turn an approved role into a job description, source candidates, screen against a scorecard, coordinate interviews, prepare interviewer briefs, summarize feedback, and keep the applicant tracking system current.

Give it the approved role, compensation range, must-have criteria, disqualifiers, interview process, scorecard, and candidate communication templates. Keep hiring judgment with humans. The Bot prepares the evidence; it does not decide who deserves a job.

Its lane: role preparation, sourcing, screening support, scheduling, interview packets, feedback summaries, and applicant tracking.

Its stop signs: rejecting candidates, making offers, changing compensation, conducting unsupervised assessments, and inferring protected or sensitive characteristics.

6. HR and People Operations

Hiring ends when someone accepts. HR begins before their first day. An HR Bot can prepare onboarding checklists, collect missing forms, answer routine policy questions from approved documents, coordinate equipment and account setup, track training, and prepare offboarding checklists.

This Bot needs stricter access than most. Point it to approved policies and the HR system, then limit which employee records it may read. Payroll, health information, performance issues, complaints, and disciplinary matters should stay behind a human boundary.

Its lane: onboarding coordination, policy retrieval, training reminders, routine employee requests, and offboarding preparation.

Its stop signs: employment decisions, policy interpretation beyond the written source, compensation changes, disciplinary communication, and broad access to sensitive employee data.

7. Customer Support

A Customer Support Bot can triage incoming tickets, retrieve account and order context, draft answers from the current knowledge base, suggest troubleshooting steps, route issues, identify recurring problems, and update support documentation after review.

Start it in draft mode. Let it earn the right to send narrow answers only after you have seen it handle edge cases, angry customers, ambiguous requests, and conflicting records.

Its lane: classification, context gathering, response drafts, approved routine replies, escalation, and support trend reporting.

Its stop signs: refunds, credits, account deletion, security changes, legal threats, unsupported promises, and closing a case the customer says is unresolved.

8. Accounting and Finance

An Accounting and Finance Bot can collect receipts, prepare invoice data, match supporting documents, categorize transactions for review, monitor unpaid invoices, assemble cash-flow reports, explain variances, and prepare a weekly financial brief.

Your accounting platform remains financial truth. The Bot may prepare and reconcile evidence, but a qualified human should approve filings, payments, payroll, tax treatment, and final books.

Its lane: document collection, data preparation, receivables follow-up drafts, reporting, variance analysis, and exception queues.

Its stop signs: moving money, changing bank details, filing taxes, running payroll, finalizing reconciliations, deleting records, and treating its own calculations as the ledger.

Across all eight specialists, the same flow appears:

Company context -> Specialist method -> Connected tools -> Reviewable output
-> Human approval -> Writeback to the correct system

More Bot ideas

Once the core functions are covered, you can create narrower specialists for work that is frequent enough to deserve its own context and tools:

• PR and Media Opportunities: Monitor publications and podcasts, score relevant opportunities, find the right recipient, and draft pitches for approval. This is where my media opportunity engine fits.
• Inbox and Email: Triage a shared inbox, identify commitments, route requests, and prepare replies without becoming a second Chief of Staff.
• SEO and Content: Find search opportunities, refresh decaying pages, prepare briefs, maintain internal links, and report rankings.
• Customer Success: Prepare account reviews, watch adoption and renewal signals, surface risks, and draft proactive check-ins.
• Competitive Intelligence: Track competitor launches, positioning, pricing, hiring, and customer feedback, then explain what actually matters.
• Customer Research: Organize interview notes, tag recurring problems, connect evidence to product or service decisions, and maintain a research repository.
• Procurement and Vendors: Compare quotes, track renewals, collect compliance documents, and flag contracts or subscriptions needing review.
• Legal and Compliance: Retrieve approved clauses, assemble evidence, and prepare review packets. It should never provide final legal judgment or accept terms.
• Analytics and Reporting: Pull agreed metrics from authoritative systems, explain changes, and prepare weekly management reports.
• Product and Engineering: Triage bugs, prepare specifications, run tests, create previews, and hand reviewed changes to a human release owner.

How to design a multi-Bot company without creating chaos

You can have bots communicate with each other, which means you can put your Chief of Staff above specialist Bots. That is a sensible default for a small business:

Owner
└── Chief of Staff
    ├── Social Media and Marketing
    ├── Sales
    ├── Website
    ├── Operations and Delivery
    ├── Hiring
    ├── HR and People Operations
    ├── Customer Support
    └── Accounting and Finance

The Chief of Staff coordinates. Specialist Bots own jobs. The human owns judgment.

Do not create a separate Bot for every task. Create one when a body of work has distinct context, tools, permissions, and outputs. Sales, support, and finance deserve separate roles. “Monday report Bot” and “Tuesday report Bot” do not.

Use each Bot’s name, title, and description to make the boundaries explicit. A specialist description can follow this structure:

You are the [title] for [company].

Your mission is to [one outcome this Bot owns].

Before working, read:
- [Authoritative source]
- [Authoritative source]

Your output is [artifact, system, and expected format].

You may do these things without approval:
- [Reversible, low-risk action]

Stop and ask for approval before:
- [Consequential action]

When handing work off, send [required information] to [person or Bot].

If a source is missing or the job fails, [what to report and where to stop].

Success means [business outcome and quality measure].

Then define how Bots hand work to one another:

When handing work to another Bot, include:

1. The requested outcome.
2. Links to the authoritative sources.
3. Work already completed.
4. Assumptions and unresolved questions.
5. The remaining decision.
6. The deadline and accountable owner.
7. The approval required before completion.

Never pass an unsupported conclusion as a fact.

Trust your Bots in stages

An agent that can finish work can also finish the wrong work.

Use this trust ladder:

1. Read: Collect, retrieve, and summarize.
2. Prepare: Draft, score, classify, and recommend.
3. Propose a write: Show the exact change before making it.
4. Write with approval: Execute the approved change, then verify it.
5. Automate narrow writes: Allow only after repeated successful runs and a clear recovery path.

Most businesses can get a surprising amount of value from levels one and two. A prepared inbox, researched lead list, meeting brief, website preview, and pitch draft move real work without granting blind authority.

Keep these actions gated for a long time, perhaps permanently:

• Send.
• Publish.
• Pay.
• Delete.
• Change permissions.
• Change production.
• Accept legal terms.
• Create an external commitment.

When you approve a write, require verification. If the Bot updates a CRM stage, it should reread the record and report the saved value. If it creates a draft, it should link the draft. If it changes a website, it should show the preview.

You probably do not need a database yet

I mentioned earlier that Refound OS has a Postgres database. It tracks companies, contacts, deals, activities, deliverables, tasks, follow-ups, invoices, content, and team members. Our agents use it because several workflows and people touch the same business state, and we need reliable histories, constraints, and reporting.

You can start much lighter.

Use the tools you already have:

• CRM for customers and deals.
• Asana, Trello, Linear, or a sheet for work.
• Drive, SharePoint, or Notion for maintained company knowledge.
• Gmail or Outlook for communication.
• Your accounting platform for financial truth.

The company OS maps those systems and teaches the Bots how to use them. It does not need to replace them.

Add a database when:

• Several Bots and humans update the same entities.
• Deduplication becomes recurring work.
• You need an audit trail.
• Cross-tool reporting becomes unreliable.
• The business needs its own durable state instead of renting truth from scattered SaaS tools.

Build an improvement loop

The system will get things wrong and that’s to be expected. Don’t give up yet. Every correction tells you where the operating model is weak.

Use this loop:

Run real work -> Review the result -> Diagnose the failure -> Fix context or method
-> Test again -> Promote to a routine

Apply the correction in the right place:

Do not bury every correction in a chat and hope the Bot remembers forever. Fix the authoritative source when the fact is wrong, the Bot description when a standing rule is wrong, and the routine when that particular job is wrong.

A practical five-day sprint

You do not need five days to create one Bot. The point of the sprint is to finish the week with the beginnings of an actual agent team, all working from the same company context.

Day 1: build the OS and your Chief of Staff

Create COMPANY.md, SYSTEMS-OF-RECORD.md, APPROVALS.md, and CURRENT-PRIORITIES.md in one shared location. Keep them short. Link to the systems where live information already belongs instead of copying everything into the documents.

Then create the Chief of Staff, paste the company OS instructions into its description, and ask it to plan your day. Connect the email, calendar, files, and task tools it requests. By the end of Day 1, you should have a first daily brief, even if it is not very good yet.

Day 2: test and correct it

Run the Chief of Staff on real work. Ask it to prepare you for a meeting, triage the inbox, or find the commitments you are in danger of missing.

When it gets something wrong, fix the layer that caused the mistake: the source document, system-of-record map, approval rules, or Bot description. Once the daily brief is useful, turn it into a weekday routine.

Day 3: add your first specialist

Choose the function creating the most drag. Pick one of the eight specialist starters, point it to the same company OS, give it only the tools it needs, and run one real job.

Do not start with a routine. First inspect the output, correct the Bot, and make sure it stops before consequential actions.

Day 4: add a second specialist

Repeat the process for a different part of the business. If Day 3 was marketing, choose sales or operations. Give the second Bot one clear outcome and test it on real work.

If the specialist needs to pass work to the Chief of Staff, test that handoff now. Make sure the handoff includes the source, completed work, unresolved decision, and required approval.

Day 5: hold the first weekly review

Spend 30 minutes reviewing the fleet:

• Which work was genuinely useful?
• Which output needed heavy editing?
• Which fact or instruction was missing?
• Did any Bot act beyond its lane?
• Which successful job should become a routine?
• Which Bot, routine, or instruction should be removed?

Fix those gaps before adding anything else. By Friday, you should have a lightweight company OS, a Chief of Staff, two specialist Bots, and at least one routine doing useful work. That is enough of a foundation to build on next week.