Guide

How to Build a Release Pipeline with AI Agents

Name: Fleet
Author: Fleet

A release pipeline is the sequence of checks and approvals a change must pass before it ships to users. Without automation, this sequence — code review, QA, staging deploy, sign-off, production merge — requires multiple people to actively hand off work to each other. AI agents can handle the mechanical parts of each stage, leaving humans to make the judgment calls.

Fleet implements this through its reactive event chain. Each stage completion triggers the next stage automatically. The release manager stage is the final gate: it checks that all required approvals exist before merging. This guide shows how to configure a multi-stage release pipeline.

Before you start

Fleet initialized with developer, reviewer, QA, and release-manager role agents (e.g. `backend-developer`, `tech-lead`, `qa-engineer`, `release-manager`)
GitHub repository with the required labels: ready, needs-review, approved, shipped
Fleet watcher running in supervised mode
Fleet skills installed on all agents

1

Map out your pipeline stages

Before writing config, list every stage and what event starts it and ends it. This mapping becomes your subscription and event config. A typical 4-stage pipeline: development (ticket_ready -> pr_created), review (pr_needs_review -> pr_approved), QA (pr_approved -> qa_passed), release (qa_passed -> ticket_shipped).

# Stage map:
# 1. Development: ticket_ready -> backend-developer -> pr_created
# 2. Review: pr_needs_review -> tech-lead -> pr_approved
# 3. QA: pr_approved -> qa-engineer -> qa_passed
# 4. Release: qa_passed -> release-manager -> ticket_shipped

2

Configure agents with stage subscriptions

Add subscription entries for each agent that correspond to the event that starts their stage. The watcher's subscription processor matches incoming events to these subscriptions and fires the right agent.

agents:
  - name: developer
    role: backend-developer
    subscribes_to: ticket_ready
  - name: tech-lead
    role: tech-lead
    subscribes_to: pr_needs_review
  - name: qa-agent
    role: qa-engineer
    subscribes_to: pr_approved
  - name: release-manager
    role: release-manager
    subscribes_to: qa_passed

3

Implement the release gate check

The release-manager agent runs fleet release check as part of its /fleet-ship-pr skill. This verifies that a pr_approved fabric event exists and the approved label is set before merging. The command exits non-zero if the gate fails, preventing the merge.

# The release-manager skill calls this internally:
fleet release check <pr-number>

# Exit 0: gate passes, release-manager proceeds to merge
# Exit 1: gate fails, reason printed, release-manager stops

4

Trigger the pipeline with a label

Add the ready label to a GitHub issue to start the pipeline. The watcher detects the label within 2 minutes, publishes ticket_ready, and the developer agent fires. Each subsequent stage fires automatically as the previous one completes.

# Start the pipeline:
gh issue edit 42 --add-label ready

# Watch it progress:
fleet log --type decision
fleet status

5

Monitor the pipeline run

Use fleet log with the --type decision filter to see the event sequence as each stage completes. You can also attach to an individual agent's session to watch detailed activity live.

# Follow the decision trail:
fleet log --type decision --since 1h

# Attach to a specific agent's session to watch live:
fleet agent attach developer

Common pitfalls

If any agent exits without publishing its output event, the pipeline stalls silently. There is no automatic timeout or error escalation by default. Monitor `fleet log` during the first few runs to catch stalled stages.
The release-manager merge gate checks for a `pr_approved` fabric event, not just a GitHub review approval. If your reviewer agent exits before publishing this event, the release gate will block indefinitely.
Running QA after code review adds latency. If your test suite takes 20 minutes, the total pipeline time is the sum of all stage durations. Set agent run-time budgets accordingly.
GitHub label and event dedup means republishing a `ticket_ready` event for an issue already in-flight may be swallowed. If you need to restart a pipeline, remove and re-add the `ready` label after the 15-minute dedup window expires.

When Fleet is the right tool

A fully automated release pipeline with Fleet makes sense once your team is producing PRs regularly and the bottleneck is the mechanical review-merge cycle rather than the quality of the work. If PRs take days to review because of substantive feedback and architectural discussion, automating the pipeline does not move the constraint. Automate the mechanical steps first and measure whether cycle time improves.

Frequently asked questions

Can I add a staging deploy stage between QA and release?

Yes. Define an agent with a custom prompt that subscribes to `qa_passed`, runs the deploy script, and publishes a `staging_deployed` event when done. The release-manager then subscribes to `staging_deployed` instead of `qa_passed`. Note that custom event names like these are ones you define for your own chain — the built-in chain events are `ticket_ready`, `pr_needs_review`, `pr_approved`, `pr_changes_requested`, and `ticket_shipped`.

What happens if a PR fails QA?

The QA agent publishes a `qa_failed` event (or adds a `changes-requested` label) instead of `qa_passed`. The developer agent subscribes to `qa_failed` and picks up the re-work. The pipeline loops back to the development stage.

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