I run about 25 bots as an AI C-suite from Bangkok. The hard part is knowing which bot gets the job, which tools it can use, and when it should stop. Get that wrong and work disappears into a conversation nobody wants to untangle.
kaize (@0x_kaize) wrote a practical guide to saving tokens in Grok Bot without upgrading your plan. We adopted several of those rules at Wize.
What stuck with me was the work you do not see. A message can trigger tool calls, retries, and another reading of a conversation that keeps getting longer. The reply is only the visible part.
Use the connector before the browser
When a bot needs records from a service, I want it to check for a connector or API path first. In a browser, it has to navigate, inspect the screen, choose where to click, and check whether the click worked. A changed layout or a login can stop it along the way. A connector can request the records directly.
Kaize cites a comparison: a browser agent took 53 steps, about 551,000 tokens, and 17 minutes. The API path took 8 calls, about 12,000 tokens, and 20 seconds. I would not treat those figures as a promise for our workflow. They do make the tool choice hard to ignore.
So our instructions say to use the direct integration when it can do the job. Use the browser when the task needs a human-facing interface. If permission is missing, report that instead of poking at the page again and again.
Give the bot a whole task
A vague request usually buys you a longer conversation about what you meant. Corrections can send the bot back through earlier instructions and tool results. Kaize cites a Cursor employee’s account of busy bots re-reading 80,000 to 90,000 tokens per step. That is a warning about oversized history, not a measurement of our bots.
I give a specialist the objective, source of truth, boundaries, and deliverable together. For an inbox task, I specify which inbox or label to check, what qualifies for action, whether to draft or send, and where the result should go.
I do not pack unrelated requests into the same prompt. One whole task per message gives the bot a finish line I can review. If the brief changes substantially, I restate it rather than keep patching an old thread.
Keep the reply short and the failure obvious
I do not need a diary of every click. I need the result, any decision waiting on me, and the location of the detailed artifact. Long chat transcripts give the bot more to read next time. They also make scanning the team feel like sitting through a meeting for every completed task.
A short reply still has to tell me when something broke. If a page fails or a connector refuses access, the bot should stop after 3 failed attempts. Tell me the failed action, the error or obstacle, and what remains unfinished. If I need to fix a permission or approve a login, hand it back to me. Do not improvise around it.
This matters even more for scheduled work. A routine can quietly loop over a broken source, consume attention and tokens, and leave me with nothing useful.
Schedule around decisions
A scheduled bot does work even when there is no news. Kaize’s math is blunt: a routine every 15 minutes runs 672 times a week, compared with 168 on an hourly schedule. He cites a Chinese user who measured this pattern. Even a check that ends with “nothing changed” has a cost.
Before scheduling something, I ask who needs the update and what they would do with it. If nobody needs to act between reviews, I prefer fixed, low-frequency runs that gather changes since the last run and return actionable items. When I stop reading a routine’s output, I should pause it or give it a narrower job.
The schedule belongs to a specific task, not a general bot told to inspect everything. Urgent exceptions can come through an event or a direct request. That does not make every check urgent.
Keep the role stable and put changing context in files
A bot description should say what the bot does, where its boundaries are, which tools it uses, and how it reports back. This week’s priorities, the current campaign brief, and working documents can live in files it reads when needed. If I edit the permanent description whenever a priority changes, the starting context becomes harder to audit.
There may be a caching benefit too, though I would not claim a specific saving for our setup. Grok 4.6 API cached input is $0.50 per million tokens versus $2.00 per million uncached, according to xAI pricing cited by kaize. API prices do not tell us exactly how a Grok Bot plan accounts for our work. They do show why repeatedly changing a shared prompt prefix may matter.
The practical benefit is clearer: a research bot knows what it may gather, and a writing bot knows which source material to use. I can change a brief without changing either bot’s standing rules. Each bot should read the files its task requires, not absorb the whole workspace.
Let the coordinator coordinate
I part company with one of kaize’s warnings here. He cautions against a chief of staff bot becoming the place you ask about everything. Fair. That bot can end up with a sprawling chat and too much work on its own desk.
But a coordinator helps our AI C-suite when it routes work to specialists, collects compact results, and flags decisions for me. It should not browse for every answer, draft every document, or carry all the project detail in its own chat. Kaize’s own bot-manager discussion supports that narrower setup: coordination works when the substantial work happens elsewhere.
Routing costs resources too. I am not sending a trivial task through a committee to make the org chart look tidy.
Before I add another bot
Does it have a distinct job and a clear handoff?
Can it use a connector before opening a browser?
Can I give it the objective, inputs, limits, and deliverable in one message?
Will it return a short result and stop after 3 failed attempts with a useful blocker report?
If it runs on a schedule, is that schedule fixed and low-frequency? Will I pause it if nobody reads the output?
Are its standing instructions stable, with changing context in task files?
If a coordinator routes the task, is a specialist doing the actual work?
That is the arrangement at Wize. The bots can do plenty. They also need to know when the job is someone else’s, and when to hand it back to me.