Warnings are not confetti: build a warning budget before agents merge

The merge button is live. Above it, the report reads GATE PASSED WITH WARNINGS — Ready for merge. Below it, the page is a column of yellow triangles.

On June 20, 2026, a personal-assistant project called Arshad.AI merged pull request #61, an automated quality-gate report for a change that wired the Vercel agent-browser CLI into the project as seven new skills. Eight reviewer agents weighed in. None said stop. All found something.

Here is the summary they produced, paraphrased from the public PR:

Code Review      WARN   0 critical   2 warnings
Security Audit   WARN   0 critical   2 warnings
Bug Analysis     WARN   0 critical   2 warnings
Test Coverage    PASS   0 critical   1 warning
Code Quality     PASS   0 critical   2 warnings
Documentation    WARN   0 critical   3 warnings
Silent Failures  WARN   0 critical   4 warnings
Test Quality     PASS   0 critical   1 warning

Zero critical issues. Zero hard failures. Seventeen warnings. The verdict line is honest about exactly that: passed, with warnings, ready to merge.

I am not here to second-guess that merge. It is a small open-source project doing something most teams will be doing within the year: letting agents propose a change, having other agents review it, and reading a single rolled-up verdict at the end. The PR is useful precisely because it is ordinary. It shows you the shape of the report you are about to start receiving, and it puts a hard question in front of you that a green checkmark hides.

What happens to seventeen warnings the moment you click merge?

The two wrong answers

There are two reflexes here, and both are wrong.

The first is to treat WARN as a stop sign. Block the merge until every triangle is gone. Do that and you have rebuilt a gate that never passes, because agent reviewers are tuned to find things. Run eight of them over any non-trivial change and you will always get a fistful of warnings. A gate that blocks on any warning is a gate your team learns to bypass by Tuesday.

The second reflex is the one almost everyone actually uses: treat WARN as background noise. The summary says ready, no critical issues, ship it. The seventeen findings scroll off the screen with the merge. Nobody decided they were acceptable. Nobody decided who owns them. They just... stopped being visible.

That is the failure this piece is about. Not a bad merge. A forgotten one. The warnings did not get resolved and they did not get rejected. They got buried under a checkmark, and the only record that they ever existed is a closed pull request nobody will reopen.

Warnings are not confetti. They are debt with a due date. The job is not to clear them before merge or to ignore them after. The job is to give each one an owner, a trigger, and an expiry, so a tolerated warning stays tolerated on purpose instead of quietly becoming permanent.

Read the warnings, not the verdict

Look at what those eight agents actually flagged in PR #61, because the specifics are the point.

The Security Audit agent noted that the new skill bundle includes dormant, unregistered hooks — shell commands that are not wired into the lifecycle yet — and that one of them runs curl HEAD against a URL. Inert today. But if a future change activates that hook, it could fire a request to an attacker-controlled address and leak the machine's real IP. It also flagged a test-only hook that uses eval to pull a function out for testing.

The Documentation agent flagged that the change references dogfood template files that are not in the repo, that one skill is missing its allowed-tools frontmatter, and that the new skills never got added to the index.

The Silent Failures agent — four warnings, the most of any reviewer — flagged that curl failures are treated as cache misses, that a perl fallback gets skipped without a word, and that errors removing a lock file are suppressed.

None of those is a crash. None blocks the merge. Each one is a small, specific bet: this is fine for now. And here is the thing about "for now" — nobody wrote down when "now" ends.

A dormant hook is only dormant until someone registers it. A missing allowed-tools declaration only matters when a skill starts reaching for a tool it never declared. A suppressed lock error is invisible until two processes collide. Every one of these warnings is a tripwire whose trigger condition is real and namable. The agent review found the tripwires. It did not tell you when they fire, or who is watching.

Why this change in particular raises the cost of a vague warning

It matters what got merged. agent-browser describes itself plainly: a browser automation CLI for AI agents. Its quick start walks through open, snapshot, click, fill, get text, screenshot, and close. Read further and the surface widens fast: file uploads, PDF rendering, accessibility snapshots, JavaScript evaluation, Chrome DevTools Protocol connections, and runtime WebSocket streaming.

That is not a linter. That is a tool that can drive a real browser session: type into fields, submit forms, move files, and execute script in a live page. When the capability you just merged can act on the world, the gap between "warning we tolerated" and "incident" gets short.

Put the agent-browser capabilities next to the warnings and the math changes. A dormant hook that does a network call is a shrug in a static library. In a bundle that already includes a browser the agent can drive and a JavaScript eval surface, it is a second outbound path you forgot you were holding. The warning did not get more severe. The blast radius behind it did.

This is the same instinct behind giving browser agents a separate profile: capability that can touch the outside world deserves its own boundary, not a shared checkmark. A warning on a tool that reads is cheap to defer. A warning on a tool that clicks, types, and evaluates script is debt you want a name and a date attached to.

The warning budget ledger

So write the thing the gate doesn't. Not a longer review — a place for the warnings the review leaves standing.

A warning budget ledger is one row per surviving warning, filled in before you merge, not reconstructed after something breaks. It does not ask "is this critical?" The gate already answered that. It asks the question the gate never does: if we are accepting this for now, on what terms?

Nine columns. Copy them into a sheet and fill one row per warning the gate left standing.

1. Warning — the finding in one line, with the agent that raised it. "Dormant hook runs curl HEAD, could leak real IP if activated (Security Audit)."
2. Current severity — your call today, not the agent's label: tolerate, watch, or fix-now. The gate said WARN; you decide what that means here.
3. Why allowed today — the actual reason this is acceptable right now. "Hook is unregistered and unreachable in current config." If you cannot write this sentence, the warning is not tolerated, it is ignored.
4. Activation trigger — the concrete condition that turns this from inert to live. "Any PR that registers the hook into a lifecycle event."
5. Promotion rule — what flips this row from warning to blocker. "If the trigger fires, this becomes a FAIL and blocks merge until reviewed."
6. Owner — a named person, not a team. The one who answers for this row.
7. Expiry date — the date this tolerance ends and someone must re-decide. A warning with no expiry is a permanent one you never chose to keep.
8. Evidence link — where the finding and its context live: the PR comment, the line, the gate output.
9. Next test — the check that catches this automatically next time, so it stops depending on a human reading a yellow triangle.

That last column is where the ledger stops being paperwork. A tolerated warning with a Next test becomes a replayable eval case: the next merge re-checks it without anyone remembering to. A tolerated warning without one depends on memory, and memory is exactly what the checkmark erased.

The ledger has exactly three exits, and every warning takes one: accept for now (with a reason, an owner, and an expiry), promote to block (the trigger fired, it's a blocker now), or retire (fixed, row closed). What it forbids is the fourth, invisible exit the merge button offers for free — dropped.

Three warnings from PR #61, in the ledger

Take three of the real findings and run them through the columns. Illustrative values, your project's specifics would differ.

Scroll sideways to see all 4 columns.

Column	Dormant hook network call	Missing allowed-tools frontmatter	Suppressed lock-removal error
Warning	Unregistered hook runs curl HEAD; could leak real IP if activated (Security Audit)	One skill ships without allowed-tools declared (Documentation)	Errors removing a lock file are silently suppressed (Silent Failures)
Current severity	Watch	Tolerate	Watch
Why allowed today	Hook is dormant and unreachable in current config	Skill currently invokes no privileged tool	Lock contention not observed in single-process use
Activation trigger	Any change that registers the hook into a lifecycle event	Skill starts calling a tool it never declared	A second concurrent process touches the same lock
Promotion rule	Trigger fires → FAIL, block until security re-review	Undeclared tool call → block until frontmatter added	Concurrency introduced → block until error is handled, not swallowed
Owner	Security lead	Skill author	Infra owner
Expiry date	2026-07-20	2026-07-20	2026-08-20
Evidence link	PR #61, Security Audit comment	PR #61, Documentation comment	PR #61, Silent Failures comment
Next test	CI check: fail if any hook is both registered and does outbound curl	Lint: every skill must declare allowed-tools	Test: lock-removal failure must log, not suppress

Three rows. Look at what they buy you. The dormant hook is no longer "a thing one agent mentioned in a closed PR." It is a watched item with a named owner, a trigger anyone can check for in a future diff, and a date in July when its tolerance runs out. If someone registers that hook in three weeks, the promotion rule already says what happens. Nobody has to remember the original warning, because the ledger remembered it for them.

This is observe-first discipline applied to your own gate. The same way you run an agent firewall in observe mode before you enforce — watching what trips before you let it block — the ledger lets you tolerate a warning on purpose while you learn whether its trigger ever fires. Tolerance with a tripwire, not tolerance by forgetting.

A note on honesty: the point is not that Arshad.AI did anything wrong. It is that the report it received is the report you are about to receive, and a closed PR is a terrible place to store seventeen open decisions.

Your first pass, on one repo

Do not build a warning-governance program. Build one ledger, for one change.

• Pick the next agent-reviewed or agent-generated pull request that merged with warnings. Not a clean one — one with yellow.
• Copy every surviving warning into a row. If the gate produced twelve and you tolerated all twelve, you have twelve rows. Empty cells are the finding.
• Write the "why allowed today" sentence for each. This is the filter. The rows where you cannot write that sentence are not tolerated warnings — they are the ones to fix or block now.
• Put a name and a date on every row. No team names, no "TBD." An owner who answers for it and a date the tolerance expires.
• Turn the highest-stakes row into a Next test — usually a capability that can act, like the browser-eval or outbound-network ones here — so the next merge re-checks it for you.

Capture all of it where the rest of the agent's work already lives. If you keep an agent receipt for tool calls, approvals, skips, and rollback notes, the warning budget is one more section of the same record: not just what the agent did, but which of its reviewers' objections you chose to carry, and on what terms. (If hooks are part of your stack, Anthropic's Claude Code hooks documentation is worth a read on why a dormant hook and a registered one are genuinely different risk classes — exactly the activation-trigger distinction the ledger is built to track.)

Bring one PR; leave with a ledger

If you are letting agents edit repos, sync skills, run browser automation, or review each other's pull requests, you will see GATE PASSED WITH WARNINGS again this week. The question is not whether the merge was right. It is whether the warnings it carried have owners, triggers, and expiry dates — or whether they just scrolled off the screen.

Bring us one agent-generated pull request, or one browser-agent workflow you are about to ship, and we will build its warning budget ledger with you: the rows, the "why allowed today" sentences, the activation triggers, the promotion rules, the owners, the expiry dates, and the first Next test — wired into how your process automation already runs. Build a warning budget ledger for one change.

Warnings are not confetti. They are debt with a due date. Give every one a name and the date it comes due.