Last month, one of my agents finished a content update at 2am. It wrote the diff, ran pre-deploy checks, filed its request, and went idle. The deploy didn't happen until morning when my Librarian process kicked off on schedule. That pause wasn't a bug—I built it that way on purpose.

The Capability I Withheld

Every agent in my operation at aienterprise.dk has file write access to its workspace. It can read the database, call external APIs, generate and modify content. What it cannot do is push to production. The pm2 reload command, the deploy script, the snapshot promoter—none of them are in scope for any agent except one designated process I call the deploy authority. This isn't about distrust. The agents' code is usually solid. The issue is risk asymmetry: a wrong file write gets caught in the next review cycle; a wrong production deploy is live the moment it runs. Those aren't the same failure mode, and they shouldn't have the same access model.

What Actually Happened

I closed that gap after an agent shipped a schema migration to the wrong site instance because it matched on name prefix instead of full identifier. Nobody was harmed—rollback took four minutes—but the path was clearly wrong. An agent that builds a thing should never be the one that decides when the thing ships.

How the Gate Works

The mechanism is intentionally simple. When an agent finishes deployable work, it calls a single script: request-deploy.mjs. The script takes a surface, an intent string, and the artifact ID. That's it—the agent's job is done. A separate process called the Librarian holds the actual deploy token and runs on a 15-minute heartbeat plus an autorun trigger when a request lands. The Librarian checks whether the new snapshot conflicts with anything else in flight, runs pre-deploy verification, ships all six sites in lockstep, bumps the version with the intent string as the changelog bullet, and records everything to the runtime log. The agent never interacts with the Librarian directly. That separation isn't there to create friction—it's there to enforce a hard architectural boundary: the thing that builds is never the thing that ships. If a deploy gets genuinely blocked, the Librarian escalates. I get an alert. I resolve it. But the system doesn't let any agent work around the gate by claiming urgency—that's where most shops create their own disaster scenarios.

Why This Matters Now

The EU AI Act's December 2027 deadline is fixed. Danish operators running agentic systems in employment, critical infrastructure, or migration contexts have a planning horizon they can actually work backward from. The draft Article 6 guidelines define high-risk more broadly than most builders expect. But the real reason to build approval gates isn't compliance—it's that production systems break in ways demos never show. An agent that can both write and ship is a system where the blast radius of a wrong decision is unbounded on one axis. That's the axis you want to control before something goes wrong, not after you've already shipped bad migrations at 2am.

Key Takeaways

  • Wrong file writes get caught in review; wrong deploys are immediately live—these require different access models
  • Separation between build and ship isn't friction—it's a hard architectural boundary with no exceptions
  • Escalation paths should exist for blocked deploys, but agents must never be able to override the gate by claiming urgency
  • Audit trails become readable only when building and shipping are separate logged processes

The Bottom Line

Most teams building agentic systems are giving their AI too much rope before they've even established where the cliff is. The EU AI Act deadline isn't a wake-up call—it's confirmation that regulators noticed what builders should have fixed already. Build your gates now, not when you're explaining a 2am incident to your compliance team.