Letting AI Agents Work on Production

Code in Unison: The Repository Is the Control Plane

The foundation is a rule so strict it sounds almost naive: nothing changes on a server by hand. Every environment this site runs - production, staging, ephemeral previews - is bound to a git branch, and the environment follows its branch the way a shadow follows a hand. Push to the staging branch and the staging environment rebuilds itself within minutes, automatically. Production changes through exactly one door: a pull request merged into the production branch. Nobody deploys; people and agents merge, and the GitOps automation does the deploying.

This binding is what "GitHub and your cloud moving in unison" means in practice, and it quietly solves the hardest problem of operating a live system: drift. When the running environment can only be what the repository says it is, there is no snowflake server whose configuration lives in someone's memory, no "who changed this and when" archaeology, and no deploy ritual that works only when performed by its inventor. The repository holds the entire truth, and the repository is versioned, reviewed, and revertible by design.

For agent work this is the load-bearing wall. An agent that can only reach production through a merge inherits every protection the merge carries: branch protection rules, required reviews, continuous integration, and a one-click revert. The agent does not need to be trusted with production. It needs to be trusted with a branch - which is a much smaller thing to trust anyone with.

Two Planes of Change, One Discipline

Code is only half of what changes on a live platform. The other half - content, layouts, media, configuration, customer records - lives in a production database, where a change is live the instant it is saved, with no branch and no merge in sight. We wrote a full companion piece on that problem: when a data change is a production deployment, and the three gates that give data changes code-grade safety: a named snapshot before anything moves, changes through an API that can only touch what it names and keeps revisions, and verification of what actually rendered in a real browser.

An agent operating on a live site works both planes constantly, often in the same hour: a theme fix on the code plane, then a layout adjustment on the data plane, then a batch of media uploads with structured metadata. The controls differ by plane - merges and CI on one side, snapshots and revisioned API writes on the other - but the shape of the discipline is identical: no change without a way back, no change broader than its intent, and no change trusted until the result is observed. Keeping the two planes' rails parallel is what lets one operator move fluidly across both without ever leaving the guardrails.

What an Agent Session Actually Looks Like

Concretely, a working session on this site follows a loop that any release manager would recognize, compressed from days to minutes. It starts with read-only reconnaissance: the agent inspects the live system - real content, real logs, real rendered pages - before deciding anything. Code changes are tested against the staging environment first, on its container, before any commit. The commit lands on the staging branch, which redeploys staging automatically; the agent verifies the result as rendered, then opens a pull request toward production for a human to approve. Data changes ride the three gates from the companion piece. The terminal below is the whole ceremony, unabridged.

The SDLC Controls, Mapped to Agent Work

None of the controls above were invented for AI. They are the same software development lifecycle controls auditors have been asking about for twenty years - they just need to be real rather than aspirational, because an agent exercises them hundreds of times a week. Identity and authorization: the agent works under named, scoped credentials - its own SSH identity, its own application passwords minted per session - so every action in every log is attributable. Environment separation: hands-on testing happens only against staging; production is reachable exclusively through the merge door. Change approval: the production branch is protected, and a human review stands between the agent's work and the customer.

Testing gates: a browser-based regression suite with screenshot baselines runs after every increment, on the theory that no operator - human or machine - gets to declare their own work correct. Rollback: code reverts with git, data restores from named snapshots, layout changes from API revisions. And audit: here agents quietly outperform people. Beyond the git history and API revision logs, every agent session leaves a complete transcript - every command run, every observation made, every decision and its reasoning - which is a level of change documentation no human operator has ever produced voluntarily. When the control question is "show us exactly what happened," the agent's answer is better than yours.

Guardrails Beat Good Intentions

The honest part: the gates exist because things went wrong, and they will again. In June, a batch edit on this site - automated, confident, plausible - adjusted headings across nine pages and silently rebuilt each page's layout geometry along the way, flattening the custom column widths on two of them. Every check that ran that day read the served HTML and pronounced the work clean; the damage only existed once a browser assembled the page, and a person spotted it before the tooling did. The screenshot-comparison suite that now gates every increment is a direct descendant of that afternoon.

That incident is the correct mental model for agent risk. Agents do not get tired, but they do get confidently wrong, and they are wrong at the same speed they are right. A delivery system built on trusting the operator's self-assessment will eventually be burned by any operator. A system that verifies rendered reality, keeps a way back, and bounds each change's blast radius does not need to care how the mistake was made - it catches the human's bad Friday deploy and the agent's overconfident batch edit with the same indifference. Guardrails are not a tax on velocity; they are what velocity is made of.

What This Buys: The Velocity, Measured

The payoff is not theoretical. In one recent seventy-two-hour stretch, this site shipped five substantial content pages, imported thirty-four client testimonials in a single gated batch, uploaded a series of custom diagrams with structured metadata, and re-pointed its navigation - dozens of production changes on a live business site, agent-executed, with the regression suite green after every increment. Over the six weeks this operating model has been running, the site's Ahrefs health score climbed from 18 to 96 while the pace of change went up, not down.

And the model transfers. The morning this page shipped, the same playbook was pointed at another property we operate - a busy Charlotte sports facility's site that had drifted, through months of ordinary neglect, to an Ahrefs health score of 13 with over nine hundred crawl errors. One agent session diagnosed the error families instead of the individual URLs, fixed the content lifecycle behind nearly all of them, and put the same gates in place. By the afternoon recrawl the score read 85. Same discipline, different codebase, one working day.

The operating rule that makes it sustainable is almost embarrassingly simple: one task at a time, verified before the next begins. The agent does not get to batch ten changes and verify once; every increment passes the gates on its own. That cadence would feel bureaucratic to a human team. To an agent it costs minutes, and it means the blast radius of any single mistake is one increment - which is precisely the property that lets a human supervisor stay comfortable while the agent runs ahead.