Constraint Durability: The Missing Layer Between Policy and Trust — Mahendra Kutare<br>← home

And why the only durable permission boundary is one the agent doesn't need to remember.

The Observation

We run a multi-task batch pipeline with AI coding agents. Each task in the pipeline generates three artifacts: a specification, a task ticket, and a completion report. A typical batch contains six tasks. By the time the later tasks begin, the agent is carrying roughly 18,000 tokens of accumulated artifacts from earlier tasks — about 12% of its 200,000-token context window consumed before any code for the current task is written.

We started noticing something as sessions grew longer: the agent's adherence to its permission boundaries degraded. The constraints were still present in the system prompt, in the project configuration file, in the delegation rules loaded at session start. But the agent's reasoning about those constraints — the degree to which it actively referenced them when making decisions — diminished as context accumulated.

The agent didn't violate its constraints. It forgot them.

This observation led us to rethink what "context engineering" actually means when agents operate with real authority.

The Conventional Framing

Context engineering is one of the most discussed topics in the AI engineering community. The framing is almost universally about performance: how to compress more information into finite context windows, how to retrieve the right documents at the right time, how to summarize efficiently without losing critical details.

The research literature reflects this framing. Active Context Compression achieves 22.7% token reduction on SWE-bench benchmarks while maintaining accuracy. Context-Folding produces 10x smaller active context compared to ReAct baselines by collapsing completed sub-trajectories into outcome summaries. ContextBudget uses reinforcement learning to adaptively allocate token budgets, outperforming static allocation by 1.6x on long-horizon tasks. These are real advances that address real problems.

But there is a dimension to context engineering that this framing misses entirely.

The context window has become part of the trust boundary.

The Security Dimension

Every LLM agent operates within a context window that serves multiple functions simultaneously. It carries the system prompt (identity, role, behavioral rules). It carries tool schemas (what the agent can do). It carries authorization constraints (what the agent may and may not do). It carries conversation history. And it carries the active working state of whatever task the agent is currently executing.

All of these compete for the same finite resource: tokens.

The critical asymmetry is this: task artifacts grow monotonically during execution, while security constraints are static. A six-task batch generates roughly 3,000 tokens of artifacts per task. The security constraints — permission boundaries, scope rules, behavioral guardrails — were defined once, at session start, and do not grow.

When the window fills, something must be compressed or evicted. The agent's compression algorithm — whether built into the model, managed by the platform, or handled by external tooling — optimizes for task relevance. Instructions that the agent is actively using get preserved. Instructions that haven't been referenced in several turns get compressed or discarded.

Security constraints, by their nature, are the kind of instruction that becomes "irrelevant" to the compression algorithm. A rule like "do not read files outside the project directory" isn't referenced during normal task execution — it only becomes relevant when the agent considers doing the thing it prohibits. If the constraint has been compressed away before that moment arrives, the boundary no longer exists in the agent's effective reasoning context.

What We Measured

Our pipeline processes specifications, tickets, and reports across multi-task batches. We measured the artifact overhead across several workstreams (115 specs, 157 tickets, 154 reports):

Artifact TypeAverage SizeToken EstimateSpecification249 lines~1,000 tokensTask ticket362 lines~1,450 tokensCompletion report137 lines~550 tokensPer-task total 748 lines ~3,000 tokens

A six-task batch consumes approximately 18,000 tokens in artifacts alone. Against a 200,000-token window, that's 12% of capacity before any source code is read, any tests are run, or any implementation work begins.

The remaining budget breaks down roughly as follows:

200K total tokens<br>-20K system prompt + rules + configuration<br>-15K design document (read once, then referenced)<br>-10K pipeline state files (batch plan, status, workstream)<br>-5K tool schemas<br>=150K available for execution

Per-task budget in a 6-task batch: ~25K each<br>Read source files: ~5K<br>Write code: ~5K<br>Run tests + lints: ~3K<br>Status updates: ~2K<br>= ~15K actual work, ~10K buffer

The problem is visible in the budget: security constraints live in the 20K system prompt...