Skip to content
Bot jobsJob breakdowns

Your Grok Bot will invent a strategy. Something else has to be allowed to say no.

Open X this week and you will find the same video on a loop. Someone installs Grok Bot, wires up a chief agent, gives it a few specialists, connects a broker, and goes to bed. The caption is always

paulrodturnerImported from X4 min read
paulrodturnerx article
See this runHouse 314 · 00421

Article

Job breakdowns

Open X this week and you will find the same video on a loop. Someone installs Grok Bot, wires up a chief agent, gives it a few specialists, connects a broker, and goes to bed. The caption is always some version of "it trades while I sleep."

The stack is real. Grok Bot gives each bot a persistent cloud machine, a browser, logins, files, and scheduled routines that keep running after you close the laptop. Coinbase for Agents shipped write access earlier this month, so a bot really can preview and place orders from chat. The open source desks are real too. HyperGrok runs seven agents against Hyperliquid. PumpGrok runs eight against Solana memecoins. Both are better engineered than the threads that borrow their screenshots.

What the threads leave out is the part that decides whether you still have an account in March.

The failure is not a bad strategy

Language models are fluent idea machines. That is their nature and it is genuinely useful. Ask one for trade ideas and you will get twenty, all articulate, several plausible, and a few that look like genius until someone tests them honestly. The problem is that the same fluency applies to justifying the idea, sizing the idea, and approving the idea. A model that can write a thesis can also write the approval for its own thesis.

So the question is not whether your bot can find an edge. The question is what stands between the idea and the send.

In most of the setups being demoed, the answer is nothing. One context holds the research, the risk view, the keys, and the order tool. The approval lives in the same chat that wrote the request. HyperGrok's own README says it plainly: if the bot can read an approval, it can write one. That single sentence is worth more than most of the threads built on top of it.

This is not a prompt engineering problem. You do not fix it by adding "be careful" to a system prompt. It is a governance problem, and governance means structure that exists whether or not the model is having a good day.

Four things that have to be true before anything goes live

One bot cannot see the whole picture. The agent that finds ideas holds no credentials and no connector. The agent that reviews ideas cannot send orders. The agent that sends orders cannot originate ideas. Three roles, three boundaries, and a hard rule that the reviewer and the executor are never the same identity. Not the same bot wearing two hats. Different bots, different sessions, different keys.

Approval lives outside the chat. A ticket ID that a human types, in a channel the bot cannot write to. Anything the bot generates that looks like an approval is not evidence. This sounds pedantic until you imagine the alternative at three in the morning, when the thing that approved the trade was the thing that wanted to make it.

Loss caps exist before live mode does. A daily loss ceiling, a maximum notional per order, a maximum open position, and a leverage limit. If those numbers are not set, live should not be an option you can choose. Not a warning. Not a default you can override. Simply absent from the list until you fill it in. And the moment a daily loss cap is breached, the desk reverts to research mode and stays there until a person resets it.

Sleeping is not a mode. This is the one the threads are actually selling, so it deserves the sharpest rule. A scheduled routine may draft. It may review. It may prepare tickets for you to read over breakfast. It may not change the desk's mode. Only a human moves a desk from research to paper to live. If a schedule can promote itself to live, you have not automated a trading desk. You have written a very expensive alarm clock.

What I built

I put all of that into a free pack. Three roles with the firewall between them, an approval gate that only accepts human typed tickets, exposure caps that gate the existence of live mode, a trade only connector policy where withdraw and scope changes are forbidden outright, and record schemas so the three bots pass a shared object shape instead of inventing incompatible JSON on day one.

It ships as a ZIP. Paste ready system prompts for each role, a connector policy for your venue, an operator runbook with a pre live acceptance test, and a signed trust manifest with a verify script so you can prove the files you are running are the files you generated. Every file hashed. Nothing hidden.

It does not place trades. It does not touch your keys. It does not promise returns, and it never will, because the moment a governance layer starts publishing performance it has stopped being a governance layer. What it gives you is the thing you can show a partner, a fund operations person, or yourself when the feed is loud and the caps feel inconvenient.

The honest version of the pitch

Grok can invent a strategy all day. The account survives because something separate can reject it, and because send does not live in the same chat that wrote the idea.

That is not a limitation of the technology. It is how every trading desk that outlasts a cycle has ever been organised, with the front office separated from the risk seat separated from execution. The models are new. The failure modes are two hundred years old.

The pack is free at clawmaven.com/desk. Generate one, read the runbook, run the acceptance test in paper, and only then think about live. If you are running a desk for other people, that is a different conversation and I am happy to have it.

We never touch the book.

Published on grokbot.sh. Cite the public log, not a prompt pack.

Command Menu

Your Grok Bot will invent a strategy. Something else has to be allowed to say no. | grokbot.sh