The AI opens the pull request. The checks decide.

One exception, ratified in writing

Everything I build runs on the same default. The AI investigates, diagnoses, and drafts, and a person owns anything that changes a system. For most of this project's life HurricaneWise lived that rule exactly. It detected its own incidents, wrote the report, linked the evidence, and waited. The person it waited for was me.

This summer I moved one kind of work across that line: repair. Not a list of blessed failures, a kind of work. If the system's own monitoring detects that something is broken, the system may try to fix it, and the fix may ship without me. Everything that changes what the product is still comes to me.

What actually happens

1. Its own monitoring notices. Eighteen probes watch the site, the database, the upstream feeds, the storage layer and every scheduled job. Two consecutive bad checks, not one, because a single blip is usually the internet. The system opens an issue against itself naming what is down and what still works.

2. It dispatches itself. Every confirmed incident is eligible. There is no severity threshold, no category filter and no approved list. The one exception is an incident affecting the resolver itself, which is withheld deliberately so a broken repairer cannot chase its own reflection.

3. Within five minutes a sweep picks it up and starts a session: an AI working with nobody at the keyboard, inside hard limits on money, on time, on how many turns it may take, and on what it holds. Only one session runs at a time, enforced by a lock.

4. It writes the fix and proves it, then opens a pull request. It cannot push to production. That path does not exist for it.

5. Every automated check must pass. Linting, types, the full test suite, the end-to-end checks that drive the real interface on desktop and mobile. Green all the way down is the only thing that permits a merge, and only its own fix branch is eligible.

6. The release is tagged and deployed, and then the system checks the live site's health itself before calling the fix done.

7. It writes the postmortem and emails me the audit trail, whether the outcome was good or not.

8. Any failure at any stage escalates. The incident is marked as needing a person, with the failure reported as NOT deployed. It is posted to the operations dashboard behind the zero-trust door and it emails me. That path was designed first, before the happy one.

The conditions I wrote down before paying

Removing a person from a deploy path is a decision you earn. Here is the price, written before I paid it.

The fix arrives as a proposal, never a push. The credential the resolver holds cannot write to the main branch. This is a control rather than a request.

The merge is decided by the checks, not by confidence. No score, no self-assessment, no "the model was quite sure." The same battery any change of mine would face, and nothing else gets a vote.

The deploy is verified afterward, by the system, against the live site. A successful deploy and a working site are two different facts and I have been burned by treating them as one.

It holds almost nothing. The session runs on a throwaway copy of the code with no database credential, no storage key, no secrets-vault token and no deploy key in its environment. It cannot reach production data at all, whatever it decides to do.

Every fix leaves a traceable chain. Incident, to issue, to pull request, to checks, to merge, to postmortem. "A fix without that chain is not a fix" is a law in the project's constitution, quoted as written, and a test enforces it.

Money has its own fences. A soft cap per session that flags for review, a hard fifty-dollar daily ceiling behind it, brakes at eighty turns and two hours of wall clock, a daily cap on how many sessions may run at all, and a separate API key so the repair budget and the product budget can never blur into each other.

It cannot try to fix itself. This one I added after thinking about the failure mode that worried me most. If the resolver breaks, its own failure generates an incident, and a naive system would happily dispatch a session to repair the resolver, fail, generate another incident, and loop. A guard withholds dispatch for any incident touching the resolver's own services. Those always come to a person.

Two switches on the wall. On the internal dashboard, behind the zero-trust door, one kills the resolver and one kills its permission to deploy. I have not needed either. They exist so that handing over the fix path is a reversible decision rather than a permanent one.

The envelope

Here is the line that makes this a design rather than a gamble. The system may repair what exists. It may not change what the product is.

Inside the envelope: what the product does, what data it gathers, where that data comes from, where it is stored and how it is processed, the incident pipeline, and the watchdog that keeps an eye on the machinery itself. Broken pipelines, upstream sources that changed shape, jobs that stopped, checks that started lying. That is its territory.

Outside it: new features, new data sources, new pipelines, layout and interface changes, and performance work. Those come to me as a suggestion, never as a change. People can submit feedback through the site and it lands in the same tracker as everything else, and the system will not act on it by itself. That is deliberate, and it is the honest edge of what I am willing to hand over today.

The reason is not that I doubt it could do the work. It is that I wanted the shape of the product held still while I found out whether the running of it could be handed over. You cannot tell whether a system is stable if you are also changing what it is.

Now the part I would rather say myself than have somebody find. That envelope is held by the instructions the session runs under and by the shape of the incidents it receives. It is not held by a technical restriction on which files it may edit. If a session decided to redesign a page, nothing in the code would stop it; what keeps it to small corrective changes is the framing of the work, the instruction to make the minimal fix, and a test suite that has to stay green. I think instruction-enforced scope is a legitimate position and I also think it is early. It will get stricter as I learn where it strains. This was never meant to be a perfect system. It is meant to fail in front of me often enough to teach me something, and every hard control it has now exists because something taught me to add it.

How long to let it run

The mechanism was the easy part. The tuning is the work, and the dials interact in ways that are only obvious afterwards.

How many turns does a session get before it stops. How long in wall-clock time. How much money before the run is worth questioning. Set them too tight and you get a machine that gives up two steps from finishing, which is the worst outcome available because it costs the money and produces nothing. Set them too loose and it wanders: it starts refactoring something adjacent, or chases a symptom in a file that has nothing to do with the failure, and you pay for the tour.

Where I have landed is eighty turns, two hours of wall clock, fifteen dollars a session as the number that makes me look, and fifty dollars a day as the number that stops everything. Those are not principled values. They are the result of watching runs and moving the numbers, and I expect to move them again.

The same problem shows up upstream, in what counts as a failure worth acting on. Two consecutive bad checks rather than one. Checks a visitor would feel every sixty seconds, and the internal loop that watches slow-moving things every fifteen minutes. Tune that wrong in the tight direction and you drown in false incidents, each one now dispatching a machine that will spend real money investigating nothing.

This is the actual craft in autonomous operations and it is unglamorous. Not the model, not the prompt. Knowing how long to let something try before you take it back.

Why here and not everywhere

I run another system that manages a household's records and long-term financial plan. Its repair agent is structurally barred from merging or deploying anything, ever, and a test in that build proves it cannot reach the credentials that would let it. Same builder, same summer, opposite policy.

That contrast is the method working, not a contradiction in it. Where the automation boundary sits is a per-system decision made from blast radius and data. HurricaneWise serves a public weather read that regenerates continuously, fails closed when unsure, and rolls back in minutes. The worst realistic outcome of a bad automated fix here is a stale page and an email telling me about it. A system holding a family's financial plan does not get that grace, so its line stays where the risk puts it.

The question is never whether you trust the AI. It is what this particular failure costs, and what machinery would have to exist before that cost is acceptable. Two systems, two honest answers.

The unglamorous prerequisite

None of this would have been safe a few months earlier, and not because the models were worse. Because the monitoring was still lying to me.

A system cannot be trusted to fix itself until you can trust what it says about itself. Before the resolver could exist, a probe had to stop reporting its own liveness as the system's health. A dissipated storm had to stop opening false outages. An incident had to stop shipping the same generic sentence because a token limit was truncating the JSON. Those five failures, and the two months of fixing them, are the actual foundation under this episode. The autonomy is the easy part. Earning a source of truth is not.

What it costs and what I got

The resolver is why this project's AI bill roughly doubled, from about $3.60 a month to about $7. I consider it the best money in the story. Those marginal dollars buy the exact work that used to interrupt my evenings, and they are capped, metered on a separate key, and reported in the same snapshot as everything else.

What I got back is written down where the machine can be held to it: a constitution with a version number, an operations dashboard with a kill switch, and an email in my inbox every time the system uses the permission I gave it. If somebody asks what engineering leadership looks like when the engineers are agents, my best answer right now is that inbox.