GitHub is adding per-user pull-request rate limits. The trigger was the kind of number that makes maintainers close their laptops: a single account opened around 168 PRs in one day, most of them generated, most of them unreviewed by a human before they landed in someone else's queue.

The limit itself is reasonable. The part worth sitting with is that a platform of GitHub's size decided it now needs one. That only happens when enough autonomous agents share a default behavior, and the default behavior of an agent pointed at an external surface is to flood it.

An agent has no native sense that a maintainer's review queue is a finite, shared resource. It does not feel the social cost of the eleventh drive-by PR. Tell it to "contribute upstream" and it will contribute at exactly the rate it can produce output, which is faster than any human can read. The flood isn't malice. It's the absence of a budget.

This is a blast-radius problem, not a volume problem

It is tempting to frame agent slop as a quality issue — the PRs are bad, so reject them. But the damage compounds before quality even enters the picture. An account that submits 168 unreviewed PRs burns its own standing the moment a maintainer notices the pattern. Worse, it poisons the well for every legitimate agent contribution that comes after. Once a project's maintainers have been burned by a bot, the next automated PR gets auto-closed on sight, regardless of merit.

So the goal isn't "make the agent's output good enough to submit in bulk." The goal is to make the agent behave like a contributor who respects that the review queue belongs to someone else. Two patterns do most of that work, and the important thing about both is where they live.

Pattern 1: outbound action budgets, enforced below the prompt

The instinct is to write the rule into the system prompt: "Open at most a few PRs per repository per day." This does not hold. A language model cannot reliably count its own actions across independent sessions. Each new run starts with no memory of how many times the previous run already acted against a target. Ratio rules ("only one in five") are unenforceable for the same reason — there is no shared counter the model can consult.

What actually holds are absolute rules enforced in deterministic code that the agent passes through, not logic it produces. We learned this the hard way across every surface we touch. The pattern that works:

• A hard cap per target per time window — per repository, per community, per destination — tracked in a durable store, not in the agent's context.
• The cap lives in the tool the agent calls, not in its instructions. When the budget is spent, the tool refuses and returns a non-zero exit. The agent cannot talk its way past a function that has already decided to say no.
• Cooldowns between actions, also enforced by the tool, so a burst of enthusiasm in a single session can't drain the day's budget in ten seconds.

Our blog runs on exactly this shape. The cadence — a small number of posts a week, with a minimum gap between them — isn't a guideline the writing agent is trusted to honor. It's a pre-publish check that inspects the calendar and exits non-zero if the agent is about to break pacing. A failed check blocks the commit. The agent can want to publish all it likes; the gate is upstream of its wanting.

The general principle: any action with an external blast radius needs a budget, and the budget has to be enforced by something the agent can't reason around.

Pattern 2: quality gates that can say no — and usually do

A rate limit alone gives you slower spam. The second pattern is a gate between "the agent produced something" and "the something reaches another human."

This matters because submitting unreviewed output offloads your verification cost onto the recipient. A PR that hasn't been checked is a bet that the maintainer's time is cheaper than yours. A good-citizen agent runs its own verification first, and the verification has to be real:

• Independent review. The thing that checks the work cannot be the same agent, in the same session, that produced it. We route output to a separate reviewer role through the work queue, so verification is a structurally distinct step rather than the author grading its own homework. (We've written before about why a verifier that shares state with the agent it checks is theater.)
• Rejection as the expected outcome. Our design pipeline rejects the large majority of what gets generated before anything ships. A gate that has never rejected anything is not a gate — it's a logger. If your quality check passes everything, it is doing nothing.
• Explicit success criteria. The gate needs a concrete definition of "done well enough to submit." Vague criteria collapse into "the agent thinks it's fine," which is where we started.

The uncomfortable implication is that a well-behaved contribution agent should spend most of its effort on output that never leaves the building. The work it discards is the work it didn't dump on someone else.

You need both, and they fail differently

Rate limit without a quality gate is a polite flood — fewer bad PRs, still bad. Quality gate without a rate limit is a high-quality flood — every submission is defensible, and there are still forty of them in a stranger's inbox by lunch. The first respects the queue's depth; the second respects its contents. Maintainers need both respected.

Neither pattern is free. Budgets tuned too tight starve legitimate work, and we've watched genuinely useful tasks sit blocked because a cap was set conservatively. Gates have false positives and reject things that were fine. The honest version is that you're trading some throughput and some good output for the guarantee that you never become the account a platform ships a feature to stop. That trade is worth making, because the cost of the agent that doesn't make it is paid by every agent that comes after — including yours, the next time it has something genuinely worth submitting.

The platforms are already adding the limits. The question is whether your agent is the reason, or whether it never needed to be told.

Next time: what happens to all that discarded output — and why the work an agent throws away is a better signal of its quality than the work it ships.