When your agent reads 100k tokens of rules before it starts
Dennis Zaiser, technical founder
Rules accumulate. Each one is reasonable on its own: how to name things, how to log, how to write a migration, how to lay out a package. Then someone wires them all into the start of every session, and an agent asked to write a short research note first reads the migration guide, the logging rules and every naming convention the project has. Before it has looked at its task, a large share of its working context is gone.
How the load gets that big
Nobody decides to load 100,000 tokens of rules. The load grows one reasonable choice at a time. A rule is attached to every process because leaving it off feels risky, a template is added to a step because it helped once, and the always-loaded files keep their old sections because nobody is sure they're unused.
The arithmetic is quick. Count the bytes of everything a session loads before its first step and divide by about four for a rough token figure. Two dozen rule files of 10 to 15 KB each come to around 300 KB, or roughly 75,000 tokens. Add process instructions, step templates and the always-attached files, and 100,000 before the task is even read is easy to reach. Measure it once and the figure is usually a surprise. One command that sums the sizes of the files a session loads is enough; run it for each kind of task, not only the one you run most.
Most of that is usually guidance for writing code: conventions for operations, package structure, logging, migrations, typing. A research note or a plan review needs it only in places.
What it costs
Every request re-reads the whole context, so the load is paid on every turn, not once. A session that spends a quarter of its working limit on rules has a quarter less for the brief, the code and the results it was started for. Caching softens the price of re-reading a prefix that doesn't change, but not the space it takes: a cached rule still fills the window and still competes for the agent's attention.
Sessions then run out before their job is done. A research document needs a second session to validate it and a third to finish it, and each fresh session pays the full load again. The cost grows with every split, and the handoffs between sessions are where details get lost.
Quality suffers too. Attention spreads across text that doesn't apply, and in a large enough set two rules eventually disagree. The agent picks one, and it may not be the one you meant.
Load per task, not per process
The fix starts with what a task actually needs. Give each kind of task a light core, the few rules that apply everywhere, and attach the rest to the steps that use them. The migration rules belong to the step that writes a migration; the logging rules to the steps that write code. A research task's core might be a few short rules on how records are written, how sources are cited and how decisions are routed. A plan's core adds how plans are shaped. The code rules arrive with the build steps, and with the reviewers who check them.
When work is split across sub-agents, each one loads only the rules it checks. A reviewer for typing reads the typing rules; the coordinating session holds none of them and keeps its context for decisions. A short read-when map, one line per rule saying when it applies, lets an agent fetch a rule at the point it needs it rather than carrying all of them from the start.
Load each rule once per session. A rule already read doesn't need reloading at every step, unless it changed.
Fewer rules, each shorter
Rules that combine safely share a shape: one topic each, nothing restated from another rule, nothing that changes when read twice, and true wherever their topic arises. Rules shaped like that can be loaded in any combination without contradicting each other, which is what loading per task requires.
Then cut. Delete rules nobody has needed in months. Move every rule a tool can verify into a check whose message carries the fix, since a check costs nothing until it fails. What remains in prose is the reasoning a tool can't see, and that is usually much shorter than the rule it replaced.
A budget keeps it that way. Decide how much context the always-loaded core may take, and treat crossing it as a finding to fix, not a fact to accept.
Bound what tools add, too
Rules are not the only thing that fills a context. One unfiltered diff, a lockfile printed whole or a raw type-check run can cost more than an hour of real work, and it stays in the context for the rest of the session.
The same discipline applies: count before you print, filter at the source, cap every stream whose size you don't know, and send long output to a file the agent reads in windows. Sub-agents return conclusions and paths, not their full output.
Where ctxflows fits
ctxflows is the context layer and the workflows for agent-built software, and this is the context half done per task. On the Library page: one set of rules for every agent instead of one per vendor, written once, with a context step before each node that hands each task the rules and records that apply rather than the whole set. Workflows declare each node's inputs, such as a record, a docs page or an earlier node's output, so a node reads what its task needs and nothing else.
Analytics shows where the context goes: tokens and estimated cost per run, item and workflow, and an approximate view of context per task, so a load that creeps up is visible before it cuts sessions short. Memory & search lets an agent find a rule or a decision when it needs one, by meaning or by exact text, instead of carrying everything from the first turn.