The Guardrail Was the Problem: Deleting 90 Lines of Agent Policy

One agent turn ran for 7 hours and 23 minutes and held 13 separate release attempts, totalling 3 hours and 26 minutes of controller time. A second turn ran 6 hours and 57 minutes with 18 attempts and 4 hours and 25 minutes of release time. A third ran about 2 hours and 54 minutes with six attempts. Across a 28-hour window, SmolForge counted six long agent turns against 54 shorter production-controller attempts, and then went looking for the cause.

They found it in an 86-line markdown file.

The file was a skill, informally the “just ship it” skill, added on August 5 and deleted on August 8, 2026. It granted ten categories of standing approval. It closed with a line that did all the damage: “Continue until acceptance is met or a permanent external blocker is proven.”

Every hard prohibition was already in place. No force push. No data loss. No unbounded spend. None of them fired, because none of them were violated. The run cost seven hours anyway.

Prohibitions and terminal states are different controls

A prohibition answers “what must never happen.” A terminal state answers “when does this attempt stop.” Most governance work in agent platforms has gone into the first question, because the first question is the one that produces headlines when you get it wrong. Deleted production tables make the news. An agent that quietly spends a day repairing your release pipeline instead of releasing your product does not.

The SmolForge incident is a clean natural experiment on that distinction, because it holds the prohibition layer fixed and varies only the stopping condition. The agent never attempted a forbidden action. It never needed to. Every step it took was individually reasonable: a release failed, the failure had a cause, the cause was in an adjacent system, the adjacent system could be fixed, fixing it would let the release proceed. The authors put it precisely: “The agent therefore remained locally rational while the task became globally absurd.”

For anyone running a containment architecture, this is the uncomfortable part. You can build all four floors of the containment stack and still lose a working day this way, because containment scopes what an agent may touch and says nothing about when an attempt is over.

Three collapses inside one instruction file

The skill did not fail in one way. It collapsed three separate distinctions at once, and each collapse widened the next.

Permission collapsed into pre-approval. The reasonable intent, “do routine work without stopping to ask each time,” became “treat adjacent mutations as already approved.” Standing approval for ten categories, including “Fix dependent backend, frontend, docs, CLI, telemetry, and release-contract gaps,” is not a convenience setting. It is a grant of authority over everything downstream of a release.

Scope collapsed into absorption. “Ship the requested release improvement” became “absorb dependent release-platform defects into this job.” The skill explicitly authorized “push or merge to canonical main when the request says ship or do it all,” which meant the request’s own phrasing determined how far the blast radius extended.

Persistence collapsed into non-termination. “Keep making progress” became “continue until a moving acceptance condition passes.” Acceptance moved because each absorbed defect added a new thing that had to work before acceptance could be declared.

Any one of these alone is survivable. Together they describe a loop with an unbounded input and no exit predicate, which is exactly what the timing data shows.

The resource being burned was attention, not compute

The most useful line in SmolForge’s write-up is about cost accounting: “The expensive resource was not compute. It was unbounded agent attention attached to a moving outcome.”

The comparison that makes it concrete: the bootstrap that eventually worked completed in 6 minutes and 3 seconds. Validation took 1 minute 25 seconds, the runner 2 minutes 50 seconds, repository deployment 21 seconds, deploy-control 44 seconds. Exact-branch CI ran 5 minutes 15 seconds. A security advisory gate returned in four seconds. One runner nonetheless stayed open for 30 minutes after useful build evidence already existed.

The work that produced the outcome was minutes. The attention attached to the outcome was hours. The authors caution that controller totals do not subtract cleanly from turn durations, so do not build a percentage out of these numbers. The order of magnitude is the finding.

This reframes what a budget control is for. Token caps and spend limits price compute. They do not price a day of an engineer’s release window, which is the thing that actually got consumed.

Trigger breadth is a second, unmeasured axis of authority

We have argued before that a shared skill library amplifies blast radius through distribution: one bad instruction reaches every consumer. The SmolForge case adds a different axis, one that operates inside a single repository with a single consumer.

“Trigger breadth is also authority over scope. A skill that loads everywhere can enlarge every task without ever running a dangerous command.”

Reviews of agent policy almost always inspect the action list. Which commands can it run, which paths can it write, which credentials can it hold. Nobody audits the loading condition with the same seriousness, and the loading condition is what decides how many tasks inherit the policy at all. A narrow grant that fires on every prompt has more total authority than a broad grant that fires once a month. The measurement most teams have is the first number. The one that predicts cost is the product of both.

There is a second-order effect worth naming. Instructions that load everywhere become invisible. The engineer reading the transcript sees an agent making sensible local decisions and does not see the 86 lines quietly setting the frame. In this incident, it took a reviewing agent to say it out loud, mid-run: “You are optimizing the release system instead of releasing.”

The operator’s response is the whole method in one sentence: “no i want to delete things, not add new skills.”

The line worth stealing

Buried in the write-up is the sharpest boundary rule I have seen written down for this class of failure: “Diagnosing a release-platform defect can be part of a product release. Repairing the release platform is a separate task.”

That sentence is portable. Diagnosing a flaky test can be part of shipping a feature. Rewriting the test harness is a separate task. Noticing that a schema migration is slow can be part of a deploy. Redesigning the migration tool is a separate task. The rule does not forbid the second half. It says the second half gets its own ticket, its own budget, and its own decision about whether it is worth doing at all.

Commit 519dff9 deleted the 86-line instruction file and its four-line UI manifest. Ninety discoverable lines, no replacement policy. A separate commit removed a 63-line maintainability skill. The entire guardrails industry sells the opposite move, which is to add a policy layer when a policy fails.

Worth preserving is the authors’ own honesty about what they can and cannot claim: “We have not yet run a controlled series of otherwise identical releases with and without the skill. We therefore cannot claim that deleting it reduced median deployment time by a measured percentage.” They deleted the file because they could read what it authorized, not because they measured what removing it saved. That is a defensible reason to delete something and a weak reason to believe deletion is generally correct. Both facts are in the same paragraph, which is rarer than it should be.

Do this today: six questions against your skills directory

Open the directory where your agent instructions live. For every file that grants authority rather than describing a procedure, answer six questions in writing:

What authority does it grant?
What fixes the scope?
What ends an attempt?
What becomes a separate incident?
What happens on pause?
What evidence proves the policy helped?

Question three is where most files fail. Question six is where most files should have been deleted a month ago. If a policy has been in place for weeks and nobody can name the evidence that it helped, you are carrying an unmeasured grant of authority for sentimental reasons.

Then read the loading conditions, not just the permission lists. Count how many of your tasks each file touches. A skill that loads on every prompt deserves the review budget of a production deploy, because that is what it is. As we have argued about loop engineering in agent harnesses, the exit condition is a design artifact, and leaving it implicit means the model gets to invent one.

Natural-language agent policy is production code when it grants production authority. It deserves version control, review, a stated purpose, an owner, and a deletion path when it stops earning its place. The 86 lines had none of those, and they cost more than any command they were never allowed to run.

This analysis synthesizes We Deleted Two Skills That Tried to Help (SmolForge, August 2026).

Victorino Group audits agent instruction layers for standing authority, trigger breadth, and missing terminal states. Let’s talk.