Every business gets its own agent, every number gets an owner, and everything that moves money stops in front of you

Why this pairing and not one or the other

Grok Bot is the finished picture. You message named bots like teammates, they share one persistent cloud machine with a browser, a filesystem and a terminal, they stay logged into your real tools, and they keep working when your laptop is shut.

Kimi K3 is the parts bin. Open weights, a coding agent with real hands, skills, MCP, subagents and an SDK. Nothing is hidden behind a subscription tier, and the org chart stays yours.

Most people treat this as a versus. It is not. Grok Bot is the fastest way to feel what a working crew is like. Kimi K3 is how you rebuild that crew so it belongs to you and scales past one account.

The businesses do not care which one you use. They care that somebody owns the number.

Installing Kimi K3

Let me kill one myth first. Kimi K3 is not a laptop install. It is a 2.8 trillion parameter open weight MoE model, roughly 104B active per token across 896 experts, native vision, and a 1,048,576 token context window. The official MXFP4 checkpoint sits around 1.5 to 1.6 TB. Official vLLM recipes start at 8× B300 / GB300 class GPUs, or the AMD MI355X equivalent.

Anybody telling you to "just download it" has not looked at the file size.

Official links

GitHub: https://github.com/MoonshotAI/Kimi-K3
Weights on Hugging Face: https://huggingface.co/moonshotai/Kimi-K3
API quickstart: https://platform.kimi.ai/docs/guide/kimi-k3-quickstart model name kimi-k3, OpenAI compatible
Kimi Code: https://www.kimi.com/code

Path A - the one you actually want on day one

Use the hosted model. Web and mobile apps at kimi.com, or the API. Zero infrastructure, full K3, you start today.

Path B - Kimi Code CLI, the hands

This is what turns answers into work. It reads and edits files, runs shell commands, fetches pages, and picks its own next step from what it finds.

Then log in and select the model:

Path C > self hosting the open weights

Only if you have the cluster. Official engines in the README: vLLM, SGLang, TokenSpeed

Full recipes: https://recipes.vllm.ai/moonshotai/Kimi-K3SGLang cookbook: https://docs.sglang.io/cookbook/autoregressive/Moonshotai/Kimi-K3

Community GGUF and Unsloth quants exist for local runs, still hundreds of GB of RAM or VRAM: https://unsloth.ai/docs/models/kimi-k3. CPU ports are proof of concept, not production speed.

My recommendation: start on the API. Move to self hosted only when your token bill beats your GPU bill, and you will know exactly when that happens because you will be watching it.

Installing Grok Bot

There is no long guide here, and that is the point. Go to the site, download, sign in.

https://x.ai/bot

Access is bundled with the higher xAI tiers rather than sold standalone, so check what your current plan already includes before paying twice.

Two things to know before you copy any org chart onto it:

One machine, many bots. Every bot you create shares one persistent cloud computer tied to your account, not to the individual bot. That is exactly why they can hand files, browser sessions and logins to each other. It is also why sensitive credentials do not belong on that machine.

There is a ceiling. Bots and group chats are capped per account, and xAI's own docs tell you to think before adding another one. Good advice. Every extra bot is another thing to debug.

Six businesses, six ledgers, one desk

This is the part everyone gets wrong, so I am going to be blunt about it.

You are not building six chatbots. You are building six ledgers with an owner each.

A ledger is the full state of one business: what came in, what is in progress, what shipped, what got paid, what broke. An agent that owns a ledger is not answering questions about the business. It is the thing responsible for the number at the bottom of it.

Read the last two columns, not the first two. The businesses are interchangeable. The refusals are the design.

WARDEN is not a manager in the corporate sense. It is a dispatcher with a cash view. It never writes copy, never packs an order, never joins a sales call. Its only job is deciding which ledger gets attention next and stopping anything that touches money.

The three rules that keep this from burning money

I have watched a lot of people wire six agents together and end up with a group chat that spends. These three rules are what separate a desk from a mess.

Rule 1 - Two keys on anything that moves money

No single agent can complete a money action. Ever.

One agent proposes, a different agent verifies against the ledger, and you press the button. Three separate contexts, and none of them can skip the other two.

If WARDEN cannot verify a number from the ledger, the request dies. It does not go looking for the number itself. A proposal missing a number is a broken proposal, not a puzzle to solve.

Rule 2 - Every action gets a colour, and colours are enforced in code

Not in a prompt. Prompts are suggestions. Code is a wall.

Two traps people fall into.

Cancelling is red. People file cancels under "undo" and they are not. A cancelled supplier order on stock you already sold is a hole, and there is no un-cancel button.

Reading can be red. A scraper that burns your API quota at 2am costs you the next four hours of the business that shares the key.

Here is what that looks like as configuration rather than as good intentions:

deny is not ask. The deny list exists because at 1am you will approve things you should not. Take the option away from your future tired self.

Approvals expire. An approval card nobody answers within twenty minutes dies and logs itself as expired. Missing an opportunity costs you a little. Executing on context that went stale six hours ago costs you a lot.

Rule 3 - Every claim carries its source or the handoff bounces

The moment agents pass numbers to each other, invented numbers start moving through your business at machine speed.

Make it structural instead of a judgment call:

An unsourced number is now a schema violation. It fails before it reaches WARDEN, and WARDEN never has to decide whether to trust it.

This one rule is what let me stop re-checking things by hand. That re-checking tax never shows up in anybody's demo and it eats the entire time saving.

How the agents actually talk to each other

Six independent agents are six businesses. Six agents that hand each other work is a company. The difference is the wiring.

The daily loop

Every ledger runs the same three beat rhythm. Same clock, different work.

The cross-wire

This is where the money hides, and it is the part almost nobody builds.

Your six businesses are not six islands. They feed each other, and the agents should route that traffic automatically.

That loop is the actual business. Every other part of this article is plumbing that makes the loop safe to run unattended.

CRATE sits slightly outside it and feeds cash rather than leads:

What a handoff looks like on the wire

Note expires_at. Leads rot. A handoff with no expiry becomes a queue of stale work that some agent will eventually action at the worst possible moment.

The router enforces the org chart, not the prompt

Politeness in a prompt is not a control. Put it in code:

desk.slice_for(owner) is the quiet hero of the whole system. PITCH never sees the ecommerce ledger. CRATE never sees the client list. An agent cannot be talked into misusing data it was never handed.

Writing the agents

A prompt describes this one task. A charter describes the seat. You want charters.

In Kimi Code these are skill files that load themselves when the work matches.

That last rule matters more than it looks. An agent that quietly picks a winner between two conflicting numbers is an agent that has started inventing your business results.

Write the refusals first. Every time. If you cannot write three things a seat must never do, the seat does not exist yet, you just have a vague helper.

Now the money conversation

I am going to be honest with you about this section, because most posts on this topic are not.

These are model numbers, not receipts. They show how the structure reaches six figures and what has to be true for it to work. Your market, offer and close rate decide whether it does. Treat this as arithmetic to argue with, not a promise.

A realistic shape of a 100k month across six ledgers:

ECHO earns the least and is the most important seat on the desk. It feeds every other ledger. Judge it on what it sends downstream, not on what it bills.

Cost side, running everything through the API:

The interesting number is not margin. It is cost per finished task, because that is what tells you when to switch billing models. Track it from week one. Flat subscriptions beat per token pricing above a volume threshold, and you cannot find your threshold without your own data.

Build order that actually works

Do not build six agents. You will spend a month debugging a company that has no customers.

The failure list

Everything below broke something for somebody. Read it before you build, not after.

One agent per business, not one agent per tool. Tool shaped agents multiply until you have twenty things to debug and nobody owning a number.

The dispatcher must not do the work. The moment WARDEN starts writing copy, it stops being able to say no to anything.

No agent repairs another agent's bad input. It rejects it and names the missing field. Repairing hides the broken upstream forever.

Shared credentials are a shared blast radius. Grok Bot's one machine per account is a feature for handoffs and a risk for keys. Scope credentials per ledger.

Every seat on the same base model is one blind spot. If they all reason alike, they all miss alike. The honest fix is a different model in the verification chair.

One poisoned data source hits several ledgers at once. If BEACON, PITCH and WARDEN all trust the same feed, a bad feed produces confident agreement instead of a disagreement that catches it.

Coordination gets harder faster than output gets better. Six is not magic, it is the smallest number where each dangerous capability sits in a different chair. Add the seventh only when the sixth got boring.

The point

The thing you are actually building is not six AI workers. It is a desk where every number has an owner, every claim has a source, and everything that moves money stops in front of a human.

The model matters less than people think. K3 gives you the reasoning and the context window to hold a full business day. Kimi Code gives it hands. Grok Bot shows you what the finished thing feels like before you have built it.

The org chart is the product. Six agents, six ledgers, one desk, and a queue you clear in ten minutes a day.

That is what running six businesses looks like when nobody is watching them but you.

If this was useful, I post breakdowns like this every few days.

Ledger Architecture: Running Six Businesses on Grok Bot + Kimi K3 (Full Build)

Job breakdowns