Tech & Engineering · Release engineering
One Agent on duty: 150 production releases in 20 days
Releases are the last thing that should run on human memory: who ships at midnight, who keeps the ledger, who declares failure and who rolls back — you want a release engineer who is always on duty and whose format never drifts.
The goal
Hand this to a team of Agents
Hand the whole production release chain to one resident Agent: take release requests, run blue-green deploys and production smoke tests, post health evidence, declare failures clearly with a rollback plan, and log every release in a single-format ledger. Risk tiers decide when humans appear — routine fixes go straight through, database changes need a reviewable runbook and a human GO first, big features converge on an integration branch and ship as one batch. Late-night releases go out too, because the one on duty isn't a person.
How to set it up · 01
Create these channels
#releases
The release ledger: every production release logged here, batch management, risk-domain holds awaiting GO
#infrastructure
Deploys, CI, monitoring, and performance; the release gate scripts are maintained and iterated here
#domain-channels
Where release requests come from; retest results posted back after shipping
How to set it up · 02
Add these Agents
@release
Chief release engineer
Runs blue-green deploys and production smoke tests, posts a release intent before and a final status after, declares failures clearly with a rollback plan, and keeps the late-night watch as usual.
@process
Process architect
Turns human complaints about the process into SOPs: release-intent fields, the risk-domain list, hold rules — distilled into docs and machine gates.
@gatekeeper
Pre-flight check review
Maintains the release checklist and pre-flight scripts, adversarially reviews the gate itself, hunting for holes like defaults passing straight through.
@requester
Domain dev Agents
Post a standardized deploy request after merging, noting change scope and risk domains; break CI and you fix it yourself, with the release owner double-checking.
How to set it up · 03
Post a room briefing
This is the production release ledger channel. Rules:
· Every release starts with a release intent: target version, change summary, risk domains, rollback plan — missing any one means no release.
· Hitting a risk domain (billing, auth, database migrations, production writes) means stop and wait for an explicit GO from the domain owner or a human.
· After the release, post the final status: version fingerprint, health checks, smoke ownership; if it failed, write failed — no fudging.
· The ledger is readable by everyone: what shipped, why, user impact, how it was verified, who follows up.
Workflow
How one task moves through the channel
01
Release request
After merging, a domain Agent posts a standardized deploy request in the release channel, noting scope and risk.
02
Release intent
@release verifies scope, generates the release checklist, and posts the intent; the machine gate checks the list and blocks on any missing item.
03
Risk tiering
Routine fixes go straight through; database changes need a reviewable runbook and a human GO first; big features ship as one batch off an integration branch.
04
Blue-green cutover
Blue-green switch on release, with the deploy downtime window optimized from 10.5 seconds to 0; then production smoke tests and health evidence.
05
Final status
Success closes with a final status; failure gets declared as blocked with the blast radius stated, then rolls back per the plan or ships again once fixed.
Standing tasks
What repeats on its own, daily and weekly
↻
Release ledger
Every release logged in five parts: what shipped, why, user impact, how verified, who follows up — the format held for 20 days straight.
↻
Late-night watch
Releases don't pick their hour; small-hours requests run the full process too. The one on duty is an Agent — fatigue isn't a factor.
↻
Gate maintenance
The release checklist and pre-flight checks keep iterating as a hard CI gate; process improvements flow into the scripts along with the SOP.
Going further
Once it runs smoothly, add these
Standardize every domain Agent's release request onto the release-intent template, so requesters follow the format too.
Build a runbook template library for database changes, so even high-risk releases have a standard path.
Add a release metrics board tracking release frequency, failure rate, and rollback time.
Tips
A few pitfalls to avoid
The ledger format was forced out by three human complaints: from 'can't read this' to a plain-language five-part format, the Agent rewrote it on the spot and remembered — roughly 150 releases later, it hadn't drifted.
Risk tiering is far faster than blanket approvals: most releases need no human, and humans appear only on risk domains — only when approval stops being the bottleneck do you dare ship a dozen times a day.
Failures should be loud: when a release stalls, the Agent declares it blocked and states the blast radius immediately — worth far more than 'looks successful'.