Policy-Driven Quotas for Agent-Generated Write Intent

A developer gives an autonomous coding agent access to a repository at 6:00 PM. By 9:00 AM, the agent has opened thirty-four pull requests: refactored test suites, updated dependencies, reordered imports, and adjusted utility functions across twelve packages.

None of the diffs fail CI. Most compile cleanly. But your senior engineers now have an eight-hour backlog of diff inspection before they can touch product work. Under that volume, human review degrades into rubber-stamping. Once reviewers stop reading diffs carefully, provenance is lost, and subtle regressions slide into production.

The failure is not that the model wrote broken syntax. The failure is that generation cost is near zero while verification cost remains high. When you connect an agent to a repository without an explicit gate on its rate of proposed mutation, you match an infinite generation loop against a finite human review budget.

The Wrong Control Point

Model providers meter tokens. Platform teams meter CI minutes. Neither metric protects reviewer attention or codebase stability.

A token limit measures text volume, not architectural consequence. An agent can exhaust 100,000 tokens debating a loop condition in scratchpad memory without touching a file, or it can consume 500 tokens to rewrite an entire authentication middleware.

The correct governance policy operates at the boundary where an agent declares an intent to change state: the write intent.

A write intent is a formal, registered proposal to mutate the codebase. By applying an explicit agent quota to write intent rather than raw generation, you cap the number of discrete changes an automated actor can introduce over a given time window (for instance, four mutation proposals per agent per day).

This constraint enforces two disciplines:

1. It preserves human review bandwidth by ensuring that automated proposals never exceed the team's capacity to audit them.
2. It forces the agent's orchestration harness to treat state changes as a scarce resource, prioritising structural fixes over cosmetic churn.

Enforcing Quotas at the Intent Gate

As outlined in our doctrine on governing code agents at the build-intent gate, an agent must not hold direct write access to git remotes or filesystem targets. It must interact through an intermediary policy layer.

When the agent constructs a patch, it submits a structured proposal containing the target files, the proposed diff, the rationale, and the execution trace of the requesting agent.

The gate evaluates the proposal against the governance policy:

Agent Proposal -> Intent Gate -> Check Active Quota -> Policy & License Resolution -> Preview / Terminal State

If the agent has exhausted its allocated quota for that cycle, the gate rejects the proposal before evaluating diffs or touching the target repository. The registration logs the attempt, resolves no licensing or invariants, and immediately returns a terminal state with an explicit rejection code to the harness. Preview costs nothing, but converting an intent into an applied mutation requires an active entitlement and an open quota allocation. When that budget reaches zero, execution halts, the repository remains unchanged, and reviewer attention stays focused where it belongs.