My AI Rulebook Has a Hard Page Limit

The Page Limit Rule: What the Operator to Builder Transition Taught Me About Context Engineering

Somewhere in the middle of my operator to builder transition, I built myself a boss. It is a rulebook. One file that governs how my AI operating system behaves, what it can decide alone, and where it must stop and ask. That file has a hard page limit, and the limit has done more for the system than any rule inside it.

This is a piece about context engineering. But it did not start as one. It started as a mess of my own making, and I want to walk through the mess first, because the mess is where most builders are standing right now.

The Rulebook That Kept Growing

When I moved from running operations inside large businesses to building my own systems, I carried one habit with me. When something breaks, write a rule. That habit served me for fourteen years inside Rs.200 Cr to Rs.1000 Cr operations. A vendor payment goes wrong, you add an approval step. A dispatch slips, you add a checkpoint. The binder grows, and the binder is proof you are managing.

So when I started running my consulting work on a personal operating system, nine subsystems doing real work every day, I did the same thing. An agent saved a report in the wrong folder, so I wrote an instruction about folders. A draft went out sounding nothing like me, so I wrote three instructions about voice. A scheduled task failed silently, so I wrote a rule about failing loudly.
Each rule was sensible on its own. Every single one solved a real problem from a real bad day.
Six weeks in, the rulebook had roughly doubled. And the system was getting worse.

Why More Rules Made the System Dumber

The mechanism is plain once you see it. Every rule I added was not just an instruction for one situation. It was a tax on every future decision the system made.

An AI agent reads its standing rules the way a new employee would read the company handbook if you forced them to read all of it, every morning, before doing anything. Twenty pages of instructions means twenty pages of things competing for attention on a task that needed three of them. The task drowns in the preamble.

Then the contradictions started. A rule written in March about formatting quietly argued with a rule written in May about brevity. I could not see the conflict, because I never read the whole book in one sitting. The system read it in one sitting every time, and it had to resolve the argument somehow, silently, on every task.

The failure did not look like disobedience. It looked like mush. Outputs got average. Decisions got hesitant. The system was not ignoring my instructions. It was drowning in them.

The Old Frame I Had to Drop

My old frame was the operator's frame: more rules equals more control. It is the frame behind every thick SOP binder in every founder-led company I have worked with, and it fails for the same reason in both places.
The frame treats rules as free. They are not. In a human organisation, every policy costs reading time, training time, and exception-handling time. People pay the tax by quietly ignoring the binder, which is why the thickest rulebooks tend to sit in the companies with the loosest actual discipline.

In an AI system the cost is worse, because nothing gets ignored. Every rule occupies working memory that the task itself needed. The tax is collected in full, on every single run.

Context is a budget. That is the whole of context engineering in one line. Prompt engineering asks how to phrase an instruction. Context engineering asks a harder question: of everything I could tell the system, what earns a place at all?

The Page Limit Rule

So I set a ceiling. The rulebook gets a hard page limit. Right now that ceiling is ten pages. Not because ten is magic, but because a fixed number forces a discipline that no amount of good intention will.

The rule that matters is the meta-rule: every rule I add has to earn its place. Past the ceiling, something old gets cut.
This changed my behaviour more than the system's. Adding became expensive. Before writing a new instruction, I now ask whether the last failure was really a missing rule, or a bad rule already on the books. About half the time, the honest answer is that the fix is a deletion, not an addition.

The rulebook now turns over like a portfolio. Positions get reviewed. Weak holdings get sold. Nothing stays in because it has always been in.

What Counts Against the Limit

One distinction keeps the ceiling workable. Not everything lives under it.

Reference material sits outside the limit: playbooks, templates, past decisions, data. Those get loaded only when a task needs them. The page limit applies to standing rules, the instructions every subsystem reads before every task, on every run.

A library can be large. A constitution cannot. The moment I let reference material creep into the standing rules, the tax comes back, so the boundary between the two is itself one of the ten pages.

The Same Pattern in Founder-Led Firms

I keep meeting the human version of this in founder-led companies. Nobody ever deletes a policy. The approvals matrix only grows. Exceptions multiply, because the fastest way through a thick rulebook is around it.

Then one day the founder notices that the best people ask for exceptions more often than they ask for direction. The binder nobody reads has quietly become the operating model nobody follows.

The instinct is to write a clearer binder. The fix is usually a shorter one. If every policy had to re-justify itself against a fixed capacity once a quarter, most companies would discover that half their rules were written for one bad day in 2022 that never repeated.

How I Run the Review

The review is a fixed monthly slot, thirty minutes, calendar-enforced. I read the whole book top to bottom in one sitting, the way the system does, and that single habit surfaces contradictions faster than any tooling I have tried.
Each rule answers three questions out loud. What incident created you? Have you fired since? What would break if you left? A rule that fails all three is cut on the spot. A rule that half-fails gets merged into a neighbour, which is where most of the compression comes from.

The first review cut four rules and merged six into two. Nothing broke. The second review cut three more. Still nothing broke. Somewhere around the third review I stopped being afraid of deletions, which, looking back, was the actual milestone in the operator to builder transition: trusting the structure enough to carry less law.

The Principle

A constraint on rules is itself the strongest rule. Capacity forces ranking. Unlimited space means nothing has to matter.
The page limit did not make my system more obedient. It made me more honest about what I actually need it to know. That honesty, not the rules, is what the system runs on.

If you are building your own operating system, for a business or for an AI, start with the ceiling, not the rules. I write about how I run mine at anjanipandey.com