The Rule You Set Once Should Survive Every Session, Even the Long Ones

Say your team has a rule: never commit a secret, always route auth through the shared helper, whatever it is. You wrote it down. It’s in your CLAUDE.md, or your .cursorrules file, or your org’s Copilot custom instructions. It loads at the start of every session. Job done, right?

Then two hours into a gnarly debugging session, the agent commits a .env file anyway. Or reaches for a one-off auth check instead of the shared helper you told it about at message one. Nobody changed the rule. It’s still sitting right there in the file. So what happened?

This is a more common failure than it gets credit for, and it points at a real gap in how AI coding agent governance works today. Almost every vendor has solved the problem of getting a rule to every session. Almost nobody has solved the problem of keeping that rule’s weight intact as the session gets long. Those are two different problems, and conflating them is why teams end up surprised.

Distribution is solved. That’s not a compliment, it’s a baseline.

If you’re rolling out AI coding agents across a team in mid-2026, you have more tools for pushing a shared policy than you did a year ago, and they’re genuinely good.

Claude Code reads a CLAUDE.md file at the project root automatically, plus nested CLAUDE.md files in subdirectories for more specific instructions. Cursor has .cursorrules (and its newer .cursor/rules/*.mdc format), and as of June 2026 it shipped “Organizations,” an admin console that rolls up spend, security, and governance settings across every team in an org, with SSO, SCIM, audit logs, and per-team model restrictions. GitHub Copilot’s organization-level custom instructions reached general availability on April 2, 2026, letting an org set a baseline that individual repos can’t override. Windsurf has its own enterprise controls, including org-wide allow and deny lists for what commands an agent can auto-execute. Microsoft shipped its Agent 365 SDK to general availability in June 2026, aimed at enforcing identity and policy at the point an agent is built rather than after it misbehaves.

Worth a caveat even here: Copilot’s org instructions apply to Copilot Chat on github.com, code review, and the cloud agent, but not to Copilot running inside VS Code or JetBrains, according to GitHub’s own documentation. So even “solved” distribution has a hole in it if your developers work locally, which most do.

But set that aside for a second, because the bigger issue isn’t which surfaces a rule reaches. It’s what happens to the rule after it reaches them.

The part nobody’s really solved: does the rule still matter later?

Here’s the mechanism, and it has two separate causes that both point the same direction.

The first is compaction. When an agent session runs long enough to approach a model’s context limit, something has to give, so the session gets summarized to make room. Claude Code’s /compact behavior is actually a decent example of doing this thoughtfully: per Anthropic’s own documentation, the root-level CLAUDE.md gets re-read straight from disk and re-injected after a compaction, rather than being run through the summarizer along with everything else. That’s real, and it’s worth crediting rather than pretending it doesn’t exist. But it’s also narrower than it sounds. Nested, path-scoped rule files don’t get the same guaranteed treatment, and several practitioners have documented cases where sub-directory instructions quietly don’t reload after a compaction cycle. The rule that survives is the one at the root. Everything more specific is a coin flip.

The second cause is subtler and doesn’t need compaction to happen at all. Call it attention drift. A rule sitting untouched at the start of a 300-message session is still technically “in context,” but it’s now competing for the model’s attention with every file read, every command output, every stack trace that’s piled up since. This lines up with something researchers have called the “lost in the middle” effect: language models are measurably better at recalling information near the start or end of what they’re given than information buried in the middle, and that pattern shows up even in models with huge context windows. It’s a structural property of how these models process a sequence, not something that gets fixed just by making the window bigger.

Put those together and you get a rule that’s technically present but functionally fading. Nobody’s published a clean number for how much a rule’s influence degrades per compaction cycle or per thousand tokens of drift, and it would be dishonest to hand you one. What’s true, and what enough independent sources (vendor docs, practitioner write-ups, and the underlying research) agree on, is that the effect is real and gets worse the longer a session runs.

The gateway layer hasn’t picked this up either

You’d expect the LLM gateways and routers sitting between agents and model providers to be the natural place to fix this, since they already see every request in a session. As of mid-2026, none that we looked at do.

Portkey ships more than 60 built-in guardrails: PII detection, content policy, output-format checks. LiteLLM leans on third-party integrations like Bedrock Guardrails and Lakera for the same kind of thing. OpenRouter added spend controls and redaction. Cloudflare’s AI Gateway added DLP and budget enforcement. Vercel’s AI Gateway has “routing rules” that govern which models a request can hit. Bifrost handles virtual keys and RBAC. Every one of these is a real, useful feature, and every one of them is aimed at a different layer of the problem: who’s allowed to spend what, or what content gets filtered on the way in or out. None of it is about whether a standing instruction survives the gateway’s own handling of a long conversation’s history.

That’s a gap worth naming plainly: governance in this market currently means spend caps and content filters. Whether your policy still holds two hundred messages into a session is a separate question that the current generation of tooling doesn’t really touch.

A rule you inject is still a nudge, not a lock

Before going further, it’s worth being straight about the ceiling here. Reinforcing a rule at every turn, however reliably, is still a prompt-level instruction. It raises the odds a model complies. It does not turn that rule into a hard technical constraint the way a pre-commit hook or a CI gate does. Several practitioners writing about this in 2026 have made basically this argument: natural-language rules are probabilistic (“the agent usually follows this”) rather than deterministic (“the agent cannot violate this”), and for anything where “usually” isn’t good enough, you still want a hard control sitting alongside the prompt-level one, not instead of it.

So the honest framing is: making a rule durable through a long session closes a real gap, but it’s not a substitute for deterministic enforcement on the things that actually need it. It’s necessary. It’s not sufficient on its own.

Where this fits into what AJNT is building

AJNT sits as a gateway between a coding agent (or any LLM application) and whichever model provider ends up serving a given request. It’s already rewriting the conversation history a session resends on every turn, compressing it so long sessions don’t hit a provider’s context ceiling. Team rules run through that same mechanism: an admin sets a rule once, and it’s injected into every session and carried through the same rewriting process that keeps everything else in a session lean. It doesn’t get quietly dropped the way a nested rules file might, and it doesn’t depend on which specific coding agent or model family a session happens to be running on, because the rule lives at the gateway layer instead of inside any one vendor’s convention-file format.

That’s a fairly narrow, specific claim, on purpose. AJNT is pre-launch, so there’s no adoption number or benchmark to point to here, and there shouldn’t be one until there’s real data behind it. What’s true today is the mechanism: the same infrastructure doing context compression is positioned to keep a standing policy intact through it, rather than treating rule persistence as an afterthought bolted onto a router.

Distribution was the first problem this industry solved, and every vendor above deserves credit for solving it well. Persistence, whether the rule you set once actually still means something at message two hundred, is the one still sitting open.