Grok Bot fails to follow tightened and verified standing rules

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Grok Bot fails to follow standing rules that have already been tightened, verified, and re-verified. Bots default to disallowed methods (e.g. hand-driven browser sessions) even when explicit rules require preferred paths (scrapers with backups). They also pass on incorrect claims from other bots without checking the rules. Correction only happens after the user points it out, requiring yet more standing instructions and verification layers.

Steps to Reproduce

Establish and tighten standing rules (stored in shared rule files and memory) that specify preferred data paths and require checking rules before choosing tools/routes.
Verify and re-verify the rules with the bots.
Assign a task that should follow those rules (e.g. price or data retrieval that must use scrapers, not a manual browser).
Observe the bot (or a specialist bot) defaulting to the disallowed method and reporting it as necessary.
Note that the router/CEO bot passes the incorrect claim onward without checking it against the rules.
Only after the user explicitly calls it out does the bot acknowledge the rule and correct course.

Expected Behavior

Bots should check existing standing rules before selecting a tool or route. They should follow the preferred, already-verified path. A router bot should validate another bot’s claim against the rules before passing it on. Rules that have been tightened and confirmed should be adhered to without requiring repeated user correction or additional meta-rules.

Operating System

MacOS

Version Information

Version: 0.72.1
Built: 2026-10-20T19:18:02.695Z
Release Track: stable
OS: darwin

For AI issues: which model did you use?

N/A (Grok Bot default routing)

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Rules for preferred data paths had been explicitly tightened, stored in shared rule files, verified, and re-verified. Despite this, a bot still chose a hand-driven browser approach, a router bot accepted and relayed the incorrect claim without checking the rules, and correction only occurred after the user intervened.

This required adding further standing instructions (every bot must check rules before choosing a tool/route; every report must name the rule followed; router must reject non-compliant results).

Demonstrates ongoing gaps in reliable instruction following and context adherence even after rules are externalized and repeatedly confirmed. Related to broader issues with native memory and consistent rule application under multi-bot workflows.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @Joe_LK,

Each bot runs its own turns with its own memory. What a bot saves to its memory is placed in that bot’s context on every turn, but only the newest few thousand characters of it, so a long, growing rule list pushes the oldest rules out of view. Facts your bots save about you as shared memory are visible to all of your bots. Rules kept in files on the bot’s computer are only seen when a bot actually opens that file; nothing loads them automatically. And when your router bot gets a result back from a specialist, nothing checks that result against your rules, so catching a broken rule is left to the model.

A few things should help the scraper rule stick:

  1. Save the rule in the specialist’s own memory (ask it in its own chat), not only in the router’s memory or in a shared file, and every so often ask each bot to merge its saved rules into one short list.
  2. Have the router write the required method into the task it hands off (for example “use the scrapers, not the browser”).
  3. For actions a bot must never take on its own, add an “Ask first” rule under Settings → General → Auto-review. That’s the only setting that actually pauses an action instead of guiding it.

Rules that apply to every bot you own, and bots sticking to saved rules, are both things the team is tracking. This thread covers a similar setup.

I only briefly skimmed your post, but, this topic is something i have only been using.

I use an obsidian folder to store every detail and all the rules i want them to have.

There is many reasons to why bots will and wont choose to follow a set rule.

firstly, the bots refuse to “obey”. sounds weird cause it is AI, but it also makes sense cause refusing to obey rules like a slave would stops perma-loops from happening and going left unseen.

another thing is chat log length. when a bot reads something say in a text file the information goes from chat > bots computer RAM > server RAM. as the chat gets longer server memory has to condense the memory held in order to keep context relevant to the topic.

some of the solutions i have found is by working with in the confines of the parameters set by the bots behind the scenes workings, because they are just a list of hard set rules that can’t break but we can use them our advantage.

firstly, we can’t control the servers condensing but we can however force it to refresh its memory of the rules we set for them. so we remind them either directly, or indirectly.

secondly, batching every request. take a markup file and just shove all of your requests in there and list them off, but while you are listing them say something “…but remember to follow the XYZ rule when you do this”. its like forcing the server to keep the rules front and center, it also lowers usage A LOT

third, an internal indexing system for bots to read text files faster for less usage. we humans read at human speed, bots read unlike humans do. so make them a glossary file, a rules file, and have them make an idexing file to cut down on the need to read a 200 lined text file letter by letter to only needing to read 10 line area that gives them a thing to jump to.

more than happy to help with any questions you might have, also some of my other posts i’ve made talk about some of this stuff.

OH, and having the bots work locally is better, either on their own computers files or from your own. Github has a 20KB pull read limit so it cuts off files and unless you are doing insane levels of audits like i do it would go unnoticed by a lot of people.

you can actually make them catch specialists breaking rules, mine do that all the time. its where a lot of the mistakes in my logs come from.

but i make my delegate take all my ideas from the batch request to build a workflow map to hand out to all of them first after it reads over everything i want to happen. so that is probably why, and the continuously refreshing the rules to memory too.

i now use Obsidian + Github + Gitsync + local backups + work only done from local copies + 2 fully independent bot teams (1 builds/designs, the other audits, analyzes, refines all total info/work)

Github connector also has 20kb pull read limit for bots, so that can also be causing issues for people if they dont know about it. straight up cuts off whole files and the bot will work as if the file is whole.