Stopline Engineering: How to Build Your Own Agent Crew on Grok Bot + Kimi K3 (Full Guide)
Grok Bot and Kimi are not competitors. They are two halves of the same build.
Grok Bot shows you what a finished crew looks like. Agents with their own computer, real logins, work that keeps going after you shut the laptop.
Kimi gives you every part to rebuild it, in the open, and lets you keep the org chart.
I ran six agents for four weeks on the same workload. Money first.
That last line is the one nobody puts in these posts. Paying per token wins until your volume gets high enough that flat pricing takes over. Run the number against your own tier before you switch anything.
Here is what the six did in four weeks.
I am not going to show you a P&L. Anybody who does is selling something.
What I will show you is the layout that kept the crew from setting money on fire, which is the part that decides whether any of this earns anything.
What Stopline Engineering means
Every seat is defined by what it cannot do, and everything irreversible stops at you.
That is the whole method. Two rules, and they fight the same failure.
An agent that can both decide and execute has nowhere for a mistake to stop. A crew where each seat has a written stop line has a stop at every handoff, and one final stop in front of you.
TL;DR
One agent with full permissions is a fast intern holding your credit card.
Six narrow agents work because none of them can both make the call and press the button.
Station 3 is the system. Everything before it is setup, everything after it is scale.
Why one agent fails
The failure is structural, not intellectual.
When the same context window holds the idea and the button, the model has argued itself into the action long before it reaches the tool. Nothing in that prompt is rewarded for refusing.
You do not fix that with a bigger model. You fix it by taking the button away from whoever had the idea.
Six is not a product limit and it is not a magic number. Grok Bot lets you create as many Bots as you want, up to 50 Bots and group chats combined per account, and xAI's own docs tell you to think twice before adding another one.
Six is the smallest set where every dangerous capability sits in a different chair from the reasoning that wants to use it. Start with two. Add the fourth when the third gets boring. Stop the moment a new seat has nothing to refuse.
One thing to know before you copy the shape. On Grok Bot every Bot shares one persistent cloud computer tied to the account rather than to the Bot. That is what lets them hand files, browser sessions and logins to each other, and it is also why you keep sensitive credentials off that machine.
The roles
SEAT OWNS STOPLINE
---------------------------------------------------------------------
SCOUT scans literature, patents never ranks a candidate
builds the candidate list
CHEM structures, binding scores never calls anything promising
TOX safety flags, off-targets never runs an assay
the verdict
BENCH runs the assay, logs results never acts without a TOX pass
SCRIBE evidence, raw data, protocol never touches the result itself
versions
CHIEF routes, sets the objective never does the scienceRead down the right column. That is the design.
The left column is the part everyone writes first and the part that matters least.
Station 1 - Get one agent alive
Kimi Code CLI is the hands. It reads and edits files, runs shell commands, fetches pages, and picks its own next step from what it finds. The CLI is free and MIT licensed.
curl -fsSL https://kimi.com/install.sh | bash
kimi
/login
/model # pick Kimi K3K3 earns the pick here. 2.8 trillion parameters, roughly 104 billion active per token across 896 experts, a 1,048,576 token context window, text, image and video in one model. Weights are open, pricing is $3 in and $15 out per million tokens.
The context size is not a spec sheet flex. An agent that holds a full overnight session without compaction still remembers its own limits at 4am.
Do not write anything yet. Give it one real job by hand and watch.
> pull the last 200 candidates from ./feed, drop everything that fails
the liquidity filter, and write what survives to shortlist.mdNote where it stalls, what it guesses at, and what it touches that you did not expect.
That third list is your deny list.
Station 2 - Write charters, not prompts
A prompt says what to do this time. A charter says what the seat owns, what good output looks like, and where the seat stops.
In Kimi Code this is a skill file that loads on its own when the task matches.
---
name: risk
description: Verdict on every proposal before anything executes
whenToUse: When a proposal from QUANT needs a go or no go
---
# RISK Seat
## Owns
Sizing, exposure, correlation. The verdict.
## Stopline
Never places, cancels or modifies anything. Never argues the idea.
## What good looks like
PASS, CUT or KILL on every proposal, with the limit that triggered it
named explicitly.
## Hard limits
Single position never above 4% of book.
Correlated cluster never above 9% of book.
Nothing new inside 20 minutes of a scheduled release.
## Rules
Argue the size, never the thesis.
If two limits conflict, take the tighter one and say so.
If the proposal has no evidence block, return KILL and name the missing
field. Do not go find the number yourself.
That last rule separates a crew from a group chat.
RISK is forbidden from repairing sloppy work upstream. A missing source kills the proposal and SCOUT finds out. You fix inputs, not symptoms.
I wrote four charters before one survived a week without me patching it mid-session. The system is not hard. The job description is.
Station 3 - The reversible line
This station decides whether you can shut the laptop.
Sort every action the crew can take with one question. If this goes wrong, can I undo it in under a minute without talking to anyone?
REVERSIBLE IRREVERSIBLE
runs alone, all night stops, waits for you
read a feed place an order
score a candidate cancel a resting order
rank a shortlist move funds
draft a message send anything
compute exposure publish anything
label and cluster delete a record
write to a scratch log revoke a key
Two traps.
Cancelling is not reversible. A cancel that fires on a fill you did not see leaves you naked, and there is no un-cancel.
Reading is not always safe either. A read that burns your rate limit in a volatile window costs you the next fifty reads.
Now enforce it in code, never in a prompt. Kimi Code has lifecycle hooks that run local commands at key points and can gate a risky tool call before it fires.
{
"permissions": {
"allow": ["read_*", "grep", "mcp__feed__*", "mcp__db__select_*"],
"deny": ["mcp__venue__transfer", "mcp__db__delete_*", "key_revoke"],
"ask": ["mcp__venue__order_*", "mcp__mail__send", "publish_*"]
},
"hooks": {
"preToolUse": "./guards/check_reversible.sh"
}
}deny is not ask. The deny list is for things you never want to approve at 3am while half awake, because you will.
One more rule I would defend hard. Give the ask queue an expiry.
A card nobody answers in fifteen minutes dies and logs itself as expired. Missing an opportunity is cheap. Taking one against context that moved six hours ago is not.
Station 4 - Evidence or it did not happen
Nothing moves between seats without a source.
Every number carries where it came from and when it was read. Every action writes a recording of what it did.
{
"claim": "24h volume up 3.1x versus 30d median",
"value": 3.14,
"source": "mcp://feed/ohlcv?sym=X&tf=1h",
"read_at": "2026-08-24T01:14:07Z",
"recording": "runs/9f2c/vol_check.cast",
"produced_by": "quant"
}The reason is not paperwork. It is that I stopped double checking.
Before this rule I re-derived about one number in three by hand, because I could not tell a retrieved figure from a confident invention. That tax never shows up in anyone's demo video and it eats the whole time saving.
After the rule an unsourced number is a schema violation rather than a judgment call. It bounces before it reaches me.
Kimi Code takes video input, so you can drop a screen recording into the session and the agent reads it. Recordings become a working artifact instead of a folder nobody opens.
Station 5 - Wire the crew together
Kimi Code ships built in coder, explore and plan subagents that run in isolated contexts. The isolation is the point. Each keeps its own working memory, so the main thread does not fill with somebody else's intermediate mess.
Give the crew an objective, not a checklist.
/goal Cut the candidate list to five by Friday.
SCOUT shortlists, QUANT scores, RISK rules on size.
SCRIBE attaches evidence to every number.
Nothing executes without me.Then enforce the org chart in the router rather than in the prompts.
def route(task, board):
seat = match_seat(task.kind)
if seat == "execution" and not board.has_verdict(task.id, "PASS"):
return park(task, reason="no risk verdict on file")
if not board.evidence_complete(task.id):
return bounce(task, to="scribe", reason="evidence incomplete")
return dispatch(seat, task, board.slice_for(seat))board.slice_for(seat) is the quiet hero. RISK reads numbers and exposure, never the thesis prose. It cannot be talked into anything because it never receives the argument.
Connect tools once with /mcp-config. The marketplace shows a trust level for each install before you accept it. Read it. A crew is only as safe as the least trustworthy thing you plugged into it.
Add the sixth seat after five worked without it. Every seat added early is a seat you debug instead of use.
Station 6 - Let it run without you
Kimi Code is the interactive session. The Agent SDK turns the crew into something that runs on a schedule rather than on your attention.
The SDKs reuse the same CLI configuration, tools, skills and MCP servers, and surface approvals and tool calls as events you can render in your own UI.
from kimi_agent_sdk import Agent, Session
session = Session(
work_dir="./crew",
skills=["scout", "quant", "risk", "scribe"],
mcp_servers=["feed", "db", "venue"],
)
result = Agent(session=session).run(
task="Run tonight's shortlist. Stop at anything irreversible.",
require_approval=["mcp__venue__order_*", "mcp__mail__send"],
)
for event in result.events:
if event.type == "approval_requested":
push_card(event) # your gate, your UI, your expiry
Pair it with scheduled tasks on kimi.com and the crew works nights.
That is the Grok Bot property, rebuilt on parts you own.
Guards
Reproduce these or the crew collapses back into one agent wearing six hats.
What I haven't tested
Four weeks and six seats. I have no data on whether coordination survives at ten or twenty.
I have not tested a self hosted K3. Everything above went through the API, so my cost numbers say nothing about what open weights cost on your own hardware.
All six seats run the same base model, which is a shared blind spot I have not measured. The honest fix is a different model in the RISK chair. I have not done it.
I have not stress tested the hooks against an agent actively routing around them. My guards assume a cooperative agent making mistakes, not an adversarial one.
Every seat trusts the same data source the same way, so one poisoned feed compromises SCOUT, QUANT and RISK at once with no disagreement to catch it.
Numbers above are from my logs on my workload. Run your own.
The playbook
The point
The single agent was not stupid. It was unaccompanied.
A crew costs more per decision and takes longer to answer, and I would take that trade every time, because what I was buying was the ability to shut the laptop.
You do not get that from a bigger model. You get it from an org chart where every seat has a stopline, and the last one is you.
If you want more breakdowns like this, I post one every couple of days on Telegram and X. Both free.
Telegram - https://t.me/GipArcAI
