Use case

AI Agents for Release Management

Name: Fleet
Author: Fleet

Release management is a coordination job that requires constant attention without requiring constant judgment. Someone has to watch CI, verify approvals, check that all required reviews are in, confirm changelog is updated, and execute the merge. On a fast-moving team this happens multiple times a day. It consumes engineering time that could go toward building.

The risk in release management is not complexity — it is missing a gate. Merging without a passing CI run or without a required review slips through when the person doing releases is context-switching or in a hurry.

How it works with an agent fleet

A release-manager agent subscribes to pr_approved events on fabric. When all required gate conditions are met, it executes the merge sequence using the /fleet-ship-pr skill.

# Check merge gate status for a specific PR
fleet release check 42

# Output (always JSON):
# {
#   "pr": 42,
#   "mergeable": true,
#   "reason": "approved_via_fabric",
#   "approved_by": "tech-lead"
# }

The fleet release check command is the merge gate. It returns mergeable: true when EITHER GitHub's review decision is APPROVED, OR there is an approved label plus a pr_approved fabric event from a reviewer with no later pr_changes_requested. The release-manager agent calls this before executing any merge.

The fleet pattern

Release-manager is the last agent in the chain. It never starts until upstream agents have published their fabric events. The chain is: developer opens PR, qa-engineer reviews, tech-lead approves, release-manager merges. Each step is gated on the previous step's fabric event. Humans can inspect the full chain with fleet log.

Guardrails that matter here

Merge gate accepts a `pr_approved` fabric event from a reviewer (plus the approved label) when GitHub's own review decision is unavailable — fabric is the source of truth, not the label alone
Release-manager runs `fleet release check` before every merge and will not proceed unless it returns `mergeable: true`
All merge decisions are logged as fabric decision events with full provenance

Who this is for

Teams shipping multiple PRs per day who want the mechanical release steps automated with hard gates. Also useful for teams operating across time zones where the person who reviews and the person who merges are rarely online at the same time.

Frequently asked questions

What if CI is failing? Will the release-manager still merge?

No. The `/fleet-ship-pr` skill checks CI status before merging. If checks are failing, the release-manager publishes a note to fabric and waits. It will not attempt to bypass a failing CI run.

Can I configure which PRs the release-manager handles?

Yes. The `subscribes_to` config in `.fleet/config.yaml` controls which fabric events trigger the agent, and the repo-level `required_label` controls which issues enter the chain at all.

Related use cases

AI Agents for Pull Request Review →AI Agents for Code Review →AI Agents for DevOps and CI →

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.

See how it works Install Fleet