Verify delivery before closing an AI-led epic

Use My Architect’s review and delivery flow to establish what was delivered, which revision was checked and how it met the project’s criteria. Completed tasks, merged pull requests and passing tests supply evidence. None alone makes a managed epic delivered.

The expected outcome is a verified delivery decision for an exact artifact and scope, or a concrete account of the criteria and actions still outstanding.

Managed epics move through queued, in-progress, review and delivered. Confirmation uses the recorded policy and a review tied to the current scope. The server checks that modeled baseline and attributed evidence; agents or people must inspect the actual builds, tests and deployed behavior.

When to use this workflow

Suppose a coordinator owns a checkout epic and two workers finish address validation and payment-failure recovery. Their tasks may be complete while the combined checkout remains undeployed or fails an integration check. The coordinator gathers their evidence, verifies the integrated revision and submits the epic for review.

Use multi-agent coordination for worker ownership. This guide starts when implementation evidence is available and explains how to reach a supported delivery decision.

Before you start

Complete the agent quickstart. Confirm the exact project, epic and current coordinator claim. Read the applicable project context, including inherited requirements, open questions and dependencies. Check that workers have released completed assignments; active child claims prevent epic delivery.

Read get_epic_flow and the full delivery policy. Compact previews may be truncated. Call get_epic_flow_detail for the policy, continuing all returned windows at the same revision:

{
  "pid": "checkout-project",
  "field": "policy",
  "offset": 0,
  "limit": 4000
}

The identifiers below are fictional. Substitute observed values and actual evidence.

1. Verify the artifact against the requirements

Identify an immutable artifact revision, such as a commit SHA or build ID. Check the relevant acceptance criteria against that revision. Inspect test results and, when required by the policy, deployment and user-visible behavior. A successful request to a URL does not establish which revision is running.

Record evidence that another reviewer can retrieve, plus limitations and unresolved checks. Explicitly update proven requirement statuses before submitting review: later changes to relevant requirements, including status, can invalidate the baseline.

Resolve related product-change proposals through their own evolution delivery or cancellation workflow. Promoting a feature specification and delivering its containing epic are separate operations.

2. Submit the current scope for review

The coordinator calls apply_epic_flow_command with submit_review. Here the fresh flow revision is 24 and the coordinator’s current claim ID is checkout-coordinator-claim-001:

{
  "pid": "checkout-project",
  "command": {
    "operationId": "checkout-review-001",
    "expectedRevision": 24,
    "actor": "checkout-coordinator",
    "action": {
      "type": "submit_review",
      "nodeId": "epic-checkout",
      "claimId": "checkout-coordinator-claim-001",
      "criteria": "Address validation and payment recovery meet the accepted checkout requirements.",
      "requirementIds": ["FR-ADDRESS", "FR-RECOVERY"],
      "artifactRevision": "checkout-build-42",
      "evidence": ["Verified checkout-build-42 acceptance report: replace with the actual report reference."]
    }
  }
}

Include the complete checked criteria, applicable IDs and real evidence. The server derives the baseline; do not invent baseline fields or omit requirements to narrow the check. Confirm the receipt and the current review entry, then read the full review through get_epic_flow_detail when needed.

3. Confirm through the permitted route

Probe get_epic_flow_capabilities again before a new confirmation. This discovers the current connection’s support and verifier identity; it does not approve a policy.

For a recorded policy permitting automation, use confirm_delivery with the current claim, fresh revision, reason and one check for every exact policy criterion ID. Each check supplies outcome and evidence for the reviewed artifact. The actor must be the exact authenticated verifier identity returned by capabilities, not the coordinator label or a person’s name.

If the policy requires account-session confirmation, prepare the evidence for the supported account UI. Policy acceptance and account decisions cannot be supplied by an MCP actor string. With no accepted delivery policy, prepare a concrete proposal and report that delivery remains unconfirmed; authorized implementation and review can continue.

4. Read back the result

Inspect the command receipt and current flow entry. Report delivered only after verified success under the recorded policy. Check linked requirement and issue state separately; an epic transition is not a substitute for their synchronization.

The result should identify the delivered scope, artifact revision, checked criteria and evidence. State any unresolved work outside that scope separately.

Recover without changing the evidence

For EPIC_REVIEW_STALE, reread affected sources, return from review with a reason, recheck and resubmit. Never change a revision number just to pass a gate. For a known flow conflict, reconcile current state before forming a new command. For an unknown timeout outcome, retry the exact saved request with its original operation ID, revision, actor and action. See resume and handoff.

Task prompt

Verify delivery of the accepted checkout epic. Read its current context, claim, full policy and review. Check every criterion against the exact artifact revision and retain evidence. Use only the supported confirmation route. Report the verified delivered scope or the concrete remaining step; do not infer delivery from completed children or a merged PR.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.