← All posts

It's Not Progressive. It's Conditional.

Charles Stack, Founder, Coworkers.Global

Context is a budget

An AI agent like Claude starts every session knowing nothing about your company. Before it acts, you have to put everything it knows about your clients, your rules, or your last decision in front of it, in its context window.

The first inclination is to load everything. That fails. Anthropic’s engineering team describes a model’s context window as a finite “attention budget”: as the token count grows, the model’s ability to recall any one piece of information falls. They call this context rot. The challenge is choosing what goes in, and when.

At Coworkers.Global, we run a team of managed agents on a shared knowledge base, and most of our operations work comes down to that choice. We keep a small set of facts in front of every agent every session. Everything else stays out until it’s needed.

The industry has a name for this pattern: progressive disclosure. We think it’s the wrong one.

Where “progressive disclosure” comes from

“Progressive disclosure” is an interface-design term, and a good one. Apple researcher Kristina Hooper Woolsey described the idea in 1985. Jakob Nielsen gave the standard definition in 2006: progressive disclosure “defers advanced or rarely used features to a secondary screen.” Think of the “Advanced settings” link, or the disclosure triangle that expands a panel. Beginners see a simple interface; experts dig deeper.

The word progressive fits that setting. A person moves through the interface, level by level, as their needs grow. Nielsen even warned that designs with more than two levels usually fail, because people get lost.

AI builders borrowed the term. Anthropic calls progressive disclosure “the core design principle” of Agent Skills. A skill’s short description is always loaded; the full instructions load only when Claude judges the skill relevant; supporting files load only if the task calls for them. Their context-engineering guidance uses the same phrase for agents: “assemble understanding layer by layer.”

It’s a reasonable borrowing. We still think it points at the wrong thing.

It’s conditional disclosure

What makes these systems work is a condition, met at the right moment. The levels are incidental.

  • A skill loads if the task matches its description.
  • A rule loads if the agent opens a file matching a pattern.
  • A client’s history loads if the agent is about to contact that client.

Sometimes those conditions stack into levels, as with Skills, but the levels are a by-product of the gating. Remove the conditions and the levels mean nothing. Keep the conditions and remove the levels, a single flat “if X, read Y”, and the system still works. Most of ours is built that way.

Anthropic’s own documentation already speaks this language. Claude Code’s docs describe two kinds of rules. Rules without a path pattern “are loaded unconditionally.” Path-scoped rules “trigger when Claude reads files matching the pattern.” The mechanics are described in terms of conditions. Only the headline term still says progressive.

Our own agent instructions have a section titled “Conditional: read when triggered.” It lists fourteen if-then pairs. Before drafting anything to a client, read that client’s state. Before a tool’s first use, check whether it has operating rules. When a term is unfamiliar, read the glossary. None of it is progressive. All of it is conditional.

The rename matters because it moves attention to where systems break. Under “progressive,” the design question is how many levels? Under “conditional,” it’s: will this condition fire? The second question requires care, experience, and attention.

Writing conditions that fire

We learned this the hard way. We built a timeline of every client email, meeting, and question, and it filled up nicely. For part of a day, no agent read it, because no condition told any agent to. The data was complete and never used. A condition that never fires doesn’t raise an error. Nothing happens, and nobody notices.

Surveying how current tools trigger context, we see five kinds of conditions:

  1. Always. Loaded every session: Claude Code’s root CLAUDE.md, Cursor’s alwaysApply rules, a skill’s one-line description. Keep this group small; everything here spends budget on every task.
  2. Location. Fires on a file path. Cursor’s glob-matched rules and Claude Code’s path-scoped rules load when matching files are touched; CLAUDE.md files in subfolders load when Claude reads files there. The cross-tool AGENTS.md standard, which Claude Code now reads too, works the same way: the nearest file to the work applies. Open a folder, read the file. These are deterministic and reliable, but they know nothing about intent.
  3. Judged relevance. The model decides, based on a description. Agent Skills, Cursor’s “agent requested” rules, and Anthropic’s tool search all work this way. Tool search keeps selection accurate across thousands of tools, where accuracy otherwise drops past 30–50. These conditions are flexible, but they are only as good as the description.
  4. Explicit request. A person or agent names it: an @-mention or a slash command. This never misfires and never fires on its own.
  5. Event. Fires on an action about to happen. Hooks such as a pre-tool-use check can enforce a rule instead of merely suggesting it. Our “before contacting a client” and “before a tool’s first use” rules sit here.

Two failure patterns show up again and again:

  • Silent non-firing. A Cursor rule saved with the wrong file extension, or with no description, never loads, with no warning. The fix is to check what loaded, not what you wrote.
  • Vague descriptions. “Testing rules” rarely fires; “conventions for writing unit tests” does. For judged conditions, the description is the condition, so write it as when to use this, not what the file is.

Our working rules:

  • Name the trigger as an action. “Before drafting to a client” beats “client information.”
  • Prefer deterministic triggers where you can, and judged ones where intent matters.
  • Justify every “always.”
  • Test that each condition fires. Give the agent a task that should trigger it and look at what loaded.

Regards,
Charles Stack
Founder, Coworkers.Global

Sources

Coworkers.Global is an AI staffing agency. We place managed agents into organizations that need dedicated expert knowledge work. A managed agent is an AI specialist provisioned for a specific role, trained on your context, supervised by a person, and accountable for its output. The first, Alex, evaluates startup business plans for fundability, informed by human expertise and research, and calibrated against real investor decisions. We are early-stage and pre-revenue, so we lead with the quality of our judgment rather than customer logos we don't yet have. Your managed AI coworker.
Get new posts by email

What we're learning building a startup with managed agents, plus notes on raising. Monthly newsletter, no spam.