Release Manager AgentRelease readiness, verified before the go/no-go call.
The Release Manager Agent checks your configured exit criteria, tracks change approvals, drafts release notes and changelogs from the linked work, keeps the rollback plan current, and assembles a review-ready release package. It runs inside your Azure DevOps project. It prepares the assessment, and the accountable release owner makes the call.
No card required. Your data stays in your Azure DevOps tenant.
- trigger release 2.4 · candidate build
- check exit criteria · 2 findings
- checkpoint awaiting release owner
A release gate that checks itself before the meeting.
The best first workflow for this agent. The release meeting stops being a checklist scramble: the readiness report is already on the release record, with every finding linked to its evidence and its owner.
- 01Runs when a candidate build lands or a release gate is reached, and on demand before the go/no-go meeting.
- 02Checks delivery hygiene, test evidence, operational readiness, pipeline and artifact integrity, approvals and, if you turn it on, security findings.
- 03Publishes a readiness report with each finding, its evidence link and its owner, and opens follow-up work for every unmet criterion.
- 04Threshold-shaped checks, such as required states and pass rates, can run as an Execution Agent: deterministic code, no model call, a flat 4 credits a run.
RELEASE READINESS · RELEASE 2.4
- ✓ Scope linked, states correct
- ! Test runs meet pass threshold
- ✓ Runbook and rollback plan
- ✓ Pipeline stages and artifacts
- ! Change approvals current
Ships with
- Verify Release Readiness
- Validate Deployment Readiness
- Generate Release Notes
- Generate Changelog
- Manage Rollback Plan
- Track Change Approval
- Verify Approval Trail
- Verify PR-to-WorkItem Linkage
- Identify Release Risks
- Assemble Release Package
Six jobs your release manager can hand over.
Each one runs the same controlled sequence and leaves its output on the release record, wiki page or work item the team already uses, ready for the release owner to review.
- JOB 01
Check readiness against your exit criteria.
Evaluate the release scope against the criteria you configured: correct states, no critical blockers, required test runs at their pass threshold, failures accounted for, open defects, security findings and approvals. Every finding names its evidence and its owner.
dev.azure.com/contoso · Pipelines · release 2.4run started · release gate reached
scope query · 38 work items, 21 PRs
test runs: 2 failures not accounted for
follow-up tasks created · owners assigned
checkpoint · report awaiting release owner
- JOB 02
Draft release notes from the linked work.
Assemble features, fixes, breaking changes, known issues, migrations, dependencies and customer impact from the release scope and its linked work items, PRs, commits and defects, not from commit messages alone. The draft waits for sign-off before it is published.
dev.azure.com/contoso · Wiki · Releasesrun started · release cut, 2.4
reading 38 items, 21 PRs, 4 known issues
grouping: 9 features · 14 fixes · 1 breaking
notes drafted on wiki page Releases/2.4
checkpoint · notes awaiting sign-off
- JOB 03
Generate the changelog.
Produce the technical change record for the release: PRs, commits, work items, versions and deployment scope, in the order and format your template sets. Engineers get the detail; the release notes stay readable.
dev.azure.com/contoso · Repos · release/2.4run started · manual: changelog for 2.4
diffing release/2.4 against release/2.3
21 PRs · 64 commits · 3 version bumps
PR !431 has no linked work item
record · changelog attached to release
- JOB 04
Keep the rollback plan current.
Document the prior stable version, the reversal steps, data and configuration impact, the owner, the validation to run, and the criteria for calling a rollback. When scope changes, the plan is checked again rather than discovered stale on release night.
dev.azure.com/contoso · Wiki · Runbooksrun started · scope change on release 2.4
prior stable: 2.3.2 · artifact verified
new migration in scope · reversal step missing
rollback plan update proposed
checkpoint · awaiting release owner
- JOB 05
Verify the approval trail.
Track the required reviews, change-control records and release decisions, and confirm every code change in scope has a linked work item and a recorded approval. Expired or missing approvals are flagged and re-requested from the right person.
dev.azure.com/contoso · Pipelines · Approvalsrun started · schedule: weekdays 08:00
checking 21 PRs for work item and reviewer
change approval CHG-77 expired
re-request sent to named approver
record · approval trail updated
- JOB 06
Assemble the release package.
Gather the approved artifacts, manifests, reports, baselines, evidence, notes and any unresolved conditions into one review-ready package, so the decision record and the evidence behind it live in the same place.
dev.azure.com/contoso · Pipelines · release 2.4run started · manual: package release 2.4
collecting artifacts, manifests, test runs
readiness report, notes, rollback plan linked
1 unresolved condition listed in package
checkpoint · package awaiting go/no-go
run started · release gate reached
scope query · 38 work items, 21 PRs
test runs: 2 failures not accounted for
follow-up tasks created · owners assigned
checkpoint · report awaiting release owner
ILLUSTRATIVE RUNS · EVERY RUN LANDS IN YOUR JOB LOG
It runs when your release says so.
Manual, event-based, or scheduled. Every run starts from a trigger a person on your team set. The agent cannot add its own, and a disabled agent does not run at all.
- EVENT
A candidate build lands, a gate is reached, or scope changes.
Run on pipeline stages and work item changes. On work item events, add conditions such as Tags Contains release-2.4, so it runs only on the release that matters and spends no credits on the rest.
- SCHEDULE
The release window comes closer.
Schedule a readiness sweep daily, on weekdays, or weekly, so the status is current before anyone asks. It still runs on demand at any time.
- MANUAL
Someone asks: is release 2.4 ready?
Run it from the agent before the go/no-go meeting, or call it from Copilot4DevOps Chat, where system agents sit alongside your own.
Detected
- scanning…
Release 2.4, from candidate to recorded.
The seven stages every run follows, shown on one release readiness run. Click a stage or let it play.
01 Trigger
Candidate build 2.4.0-rc3 completes on the release-payments pipeline and the staging to production gate is reached. That is the event the team configured. Nothing else starts it.
What it reads. What it writes.
The agent retrieves only the Azure DevOps context, and approved external context, that the release workflow needs. Scope it to a project, a release query, or a pipeline.
| Context | It reads | It writes, creates, or updates |
|---|---|---|
| Release scopewhat is shipping | Work items, PRs, commits, defects, known issues, and the release query that defines scope | Readiness findings, release notes, changelogs, and a release report |
| Build and testevidence | Pipeline runs, stages, versioned artifacts, test runs and results, and security findings | Follow-up work for unmet criteria, failed checks, or unresolved risk |
| Approvalschange control | Approvals, change records, stage-gate findings, and segregation requirements | Approval requests and release record status, according to your policy |
| Operationsdeploy and recover | Environments, deployment topology, dependencies, service connections, secret references, runbooks, and rollback procedures | Rollback plans, and approved deployment steps where supported and explicitly configured |
| Your industrywhen a pack is on | Release-for-production, validation, certification, or evidence criteria, and configuration baselines | A review-ready release package with artifacts, manifests, baselines, evidence, and open conditions |
| The runevery time | The trigger and the scope it was given | A run record: trigger, actions, approvals, output, errors, and verification result |
Run it as shipped, or fork it.
Every agent is a versioned definition. Edit its instructions in plain English, attach your release checklist, runbooks and templates as knowledge, and re-version with rollback. You never write or see code.
Grounded in your own release process
With Bring Your Own Data, the agent retrieves from your uploaded documents, Azure DevOps queries, and wiki pages during the run, so its report follows your checklist, your runbook format, and your terminology.
Your model, per agent
Choose the model this agent runs on and see its credit rate at selection. Put the threshold checks on an Execution Agent and keep reasoning for the report. Enterprise brings your own LLM and key.
Versioned, with library updates
Restore any earlier version in one step. When the library version improves, compare yours with the new one, then keep yours or review and update.
knowledge
- exit_criteria"gatekeeper v2 · 5 checks"
- pass_threshold"set per required suite"
- security_gate"on · waiver by policy"
- templates"release notes v3"
- use_byod"on · wiki + runbooks"
- approver"release owner, named"
KNOWLEDGE UPDATED · SOP v3 attached
Rules check. The agent assembles. Your release owner decides.
Deterministic rules govern thresholds, states, links, and stage results. Planner-based analysis handles risk summaries, notes, and packaging. The agent works through your existing Azure DevOps controls and never around them.
Deterministic rules
- Required states and critical-blocker checks
- Pass thresholds on required test runs
- PR-to-work-item links and pipeline stage results
Drafts, then waits for review
- Readiness assessment for go/no-go
- Release notes, changelog, and rollback plan
- Release record updates and approval requests
Never does
- Makes the go/no-go decision
- Bypasses branch policies, environment approvals, or service-connection permissions
- Trains models on your project data
Permissions
Allow and deny, per group.
Who can manage, delete, and inspect agents follows Allow and Deny per team or security group, set at project level with organization inheritance. Protected deployment actions also need explicit identity, approval, and verification.
| Permission | Allow | Deny |
|---|---|---|
| Manage Agents | ||
| Delete Agents | ||
| Job Explorer | ||
| Manage Skills |
PROJECT LEVEL · ORGANIZATION INHERITANCE
Job log · per run
Every run, reconstructable.
- trigger
- work item 4821 updated
- checked
- criteria · links · fields
- changed
- +1 follow-up task
- approval
- awaitedgranted
- output
- draft accepted · verified
The same agent, with your industry's release rules.
Industry variants add release-for-production, validation, certification, safety and cybersecurity, segregation-of-duties, conformance, or regulatory package requirements to the gate.
- Variant 01
Software / SaaS
- Variant 02
Automotive
- Variant 03
Banking & Finance
- Variant 04
Telecommunications
- Variant 05
Medical Devices
- Variant 06
Pharma / Life Sciences
Release Manager variants ship for software, automotive, finance, and telecommunications. In medical devices, pharma, and aerospace and defence, baseline and release control pairs with the Configuration Manager variants for those industries.
All industries
Agents prepare, check, and assemble release evidence. The accountable release authority keeps responsibility for go/no-go, release-for-production, and regulatory release decisions.
Hands off, explicitly.
Ask whether a release is ready and the work fans out: one agent sweeps the criteria, one maps test coverage, one assembles the approval trail. Explicit handoffs, one checkpoint before anything is written back.
Release Manager Agent
TestQA Engineer Agent
Maps test coverage across the release scope and generates the test summary report for release sign-off.
ShipDevOps Engineer Agent
Verifies environments, service connections, and deployment prerequisites, and triages a failed release pipeline with evidence.
OwnProduct Owner Agent
Turns completed work items into release notes and wiki pages the release owner can sign off.
GovernCompliance Officer Agent
Assembles the evidence pack for the release and verifies every code change has a traceable approval.
[ Trusted by Microsoft and industry leaders ]
Questions about the Release Manager Agent.
No. It evaluates your configured criteria and prepares the evidence. The accountable release owner makes the decision, and the run history records who approved, edited, or rejected the result.
Only if the action is supported and explicitly configured with the required identity, environment permissions, approvals, and verification. It never bypasses branch policies, environment approvals, or service-connection permissions.
What you configure. Typical gates are delivery hygiene (scope linked, correct states, no critical blockers), test evidence (required runs, pass thresholds, failures accounted for), operational readiness (runbook, rollback plan, monitoring and alerts), pipeline and artifact integrity, approvals, and optionally security findings gated or waived by policy.
From the selected release scope and its linked work items, PRs, commits, defects, and known issues, not from commit messages alone. The draft follows your template and waits for sign-off before it is published.
The release readiness gate on one upcoming release. The trigger, the criteria, the owner, and the result are clear, and you can compare the report with your own checklist in the first week of the trial.
No. The agent runs inside your Azure DevOps environment on the same security and trust model as Copilot4DevOps, with no separate login. Your project data is not used to train models.
Credits are $0.01 each, pooled across your organization with no per-user fees. Threshold checks on an Execution Agent cost a flat 4 credits a run, about $0.04. A readiness report that reads across work items, pipelines, and test results is a deeper Assisted Autonomous run, and its credits scale with the context it reads. Agents pause cleanly at zero.
Release Manager variants exist for software, automotive, finance, and telecommunications. Regulated release and baseline work in medical devices, pharma, and aerospace and defence is covered by the Configuration Manager variants for those industries.
Put it on your next release.
Free trial with 2,000 credits, no card. Or bring one workflow to a 30 minute demo and watch the run live.
