Change & Release Orchestration Agent — Engineering Guide

InfinitySDLC Engineering Guides · 06/12

Reference implementation guide, not a report of a completed client deployment. Code, configurations, metrics and policies are illustrative. Adapt and validate them before production use.

This agent coordinates deterministic delivery systems. It should never replace CI/CD; it chooses, sequences and explains existing pipelines, approvals, feature flags and rollback mechanisms.

6.1 Event-driven design

Trigger the agent from a signed event such as “release candidate created,” “PR approved,” or “change window opened.” The agent fetches current state rather than trusting the event payload alone, composes a release plan, and submits mutating actions through an approval-aware executor.

event -> task admission -> gather evidence -> compute release plan
      -> preflight gates -> approval -> progressive deploy
      -> observe -> advance | pause | rollback -> close evidence packet

6.2 Integrations/MCP

• SCM: PR state, commits, CODEOWNERS, tags, protected branch checks.
• CI/CD: pipeline dispatch, status, artifact provenance, deployment promotion.
• Feature flags: create proposal, staged rollout percentage, targeted cohort, emergency disable.
• Change management: ServiceNow/Jira change request read/create-draft, maintenance windows, approvers.
• Observability: release markers, SLOs, error rate, saturation and business KPIs.
• Chat/notification: post structured release status; never accept unauthenticated chat messages as approval.

6.3 Release state machine

DRAFT -> PREFLIGHT -> READY_FOR_APPROVAL -> DEPLOY_CANARY
  -> OBSERVE_CANARY -> {PROMOTE_25 -> OBSERVE -> PROMOTE_100 | ROLLBACK}
  -> VERIFIED -> CLOSED
Any state -> PAUSED
Any deployed state -> ROLLBACK when policy threshold is crossed

Make the state machine deterministic. The LLM can propose a transition and explain evidence, but a policy service validates whether the transition is legal. This makes rollback reliable even if the model endpoint is unavailable.

6.4 Risk-aware release policy

• Increase approval level for schema migrations, authentication/authorization code, payment paths and infrastructure blast-radius changes.
• Block promotion when required evidence is missing, even if the model is confident.
• Use canary metrics with predefined thresholds. Do not ask an LLM to eyeball graphs as the only gate.
• Store release-plan version and model/tool versions with the deployment record.

Implementation Blueprint: Two-Phase Writes

Proposal/commit pattern

proposal = release.propose_deploy(service="payments", version="2026.09.14-rc3", env="prod")
# returns immutable action_hash, exact diff, policy results, expiration
approval = approvals.request(proposal.action_hash)
release.commit_deploy(action_hash=proposal.action_hash, approval_id=approval.id)

The commit endpoint should accept the signed action hash, not arbitrary deployment parameters. That prevents the model from changing the target, version or rollout strategy after a human approved the proposal.

Canary policy example

stages: [1, 5, 25, 100]
observe_minutes: [10, 15, 30, 30]
abort_if:
  error_rate_delta > 1.0pp for 5m
  p95_latency_delta > 25% for 10m
  slo_burn_rate > 14.4
advance_requires: deterministic thresholds + required tests
human_approval_at: [25, 100]

The LLM can recommend an earlier pause or rollback, but emergency rollback remains a deterministic function that is executable even if all model endpoints are unavailable.

Source and Shared Prerequisites

Adapted from the September 2026 Enterprise AI Agent Mesh handbook, Article 6 and Blueprint 6. The Enterprise Agent Platform Foundation guide provides the shared identity, MCP, retrieval, sandbox, audit and evaluation design, plus the source handbook’s further-reading list. Validate model, protocol and tool versions before production use.

Explore the Series

Previous guide · Series foundation · Next guide