Coordinate multiple AI agents on one project

Use My Architect when several AI agents need to work toward one project outcome without losing track of scope, ownership or the next step. A shared epic queue records coordination; independent child claims record who owns each work item. Your agent host launches and communicates with the agents. My Architect supplies the project context and coordination records they use.

The expected outcome is a current owner, retrievable evidence, and a verified next step for each active assignment, with a coordinator responsible for integrating the results.

When to use this workflow

Use it for work with separable outcomes: for example, a checkout epic with one worker implementing address validation and another adding payment-failure recovery. A coordinator keeps the overall acceptance criteria and integration plan current. Each worker reads the requirements for its own task and claims it independently.

A coordinator claim does not own every child. Even the coordinator needs a child claim before implementing a leaf task. Claims coordinate recorded work; they do not lock source files, create Git worktrees or guarantee conflict-free execution at any scale.

Before you start

Complete the agent quickstart. Resolve the exact project ID, accepted work scope and existing epic; reuse that work instead of creating a duplicate. Read the live flow and get_epic_flow_capabilities for the current connection. A locally installed tool does not prove server support.

Prepare eligible ordinary leaf tasks and distinguish any shared files or integration dependencies. Read project context before implementation. Give each worker a consistent actor label and its own claim; that label records attribution within the project’s authorization, not a separately authenticated identity.

1. Establish the coordinator

Call get_epic_flow to inspect the queue and current ownership. If the accepted epic is absent, register it with the enqueue action of apply_epic_flow_command, then claim it with claim. Use each fresh observed revision and retain every complete request and receipt.

Accepted implementation work permits this registration; it does not activate unrelated backlog. Respect another coordinator’s claim. get_next_epic recommends eligible work but does not acquire it. A blocked or empty recommendation is not evidence that the project is finished.

2. Let each worker select and claim work

These examples use fictional identifiers. Replace them with verified IDs, your worker label and the revision returned by the preceding read.

Call get_next_child_work:

{
  "pid": "checkout-project",
  "scopeEpicId": "epic-checkout",
  "assignee": "worker-address"
}

Read the selected task’s addressed requirements, then call apply_epic_flow_command. In this example, the selection returned task-address and flowRevision: 12:

{
  "pid": "checkout-project",
  "command": {
    "operationId": "worker-address-claim-001",
    "expectedRevision": 12,
    "actor": "worker-address",
    "action": {
      "type": "claim_child",
      "nodeId": "task-address",
      "scopeEpicId": "epic-checkout",
      "nextStep": "Implement address validation and verify its acceptance criteria."
    }
  }
}

Confirm the receipt and current child claim before starting. Recommendations exclude active child claims; a recommendation itself is not ownership. A successful claim uses its operation ID as the claim ID. The payment worker follows the same process with its own task, actor and operation ID.

3. Report progress and finish each assignment

At meaningful checkpoints, the current holder uses update_progress with its exact node and claim IDs, if live capabilities advertise it. Record verified results, remaining work and blockers. This changes descriptive progress, not completion or ownership.

Save the result and evidence with the task. For an ordinary child, release its claim through release_child, preserving the result in the reason or linked document, then use complete_task without replacing the original description with a summary. These are two guarded operations. If another claim appears between them, completion fails; reread ownership rather than overwrite it. Confirm applicable requirements and linked issues separately.

To transfer unfinished work, use handoff_child and retain its context and next step. See resume and handoff.

4. Integrate and verify the outcome

The coordinator reads worker results, checks integration and reconciles actual behavior with the epic’s requirements. Completed children do not deliver the epic. Follow verify delivery for review and confirmation under the recorded delivery policy.

The useful result is visible ownership, retrievable evidence and a verified next step for every active assignment.

Recover from interruptions

On a revision conflict, reread the flow, preserve others’ changes and reassess the intended command. A newly formed command gets a new operation ID. After a timeout with an unknown outcome, retry the exact saved request—including its original revision, actor and operation ID—to recover its receipt. Do not create a second claim. If the request was lost, inspect history and current state before proceeding.

Task prompt

Coordinate the accepted checkout epic in My Architect. Read current context and ownership, then use the available agent host to delegate independent leaf work. Require each worker to claim its own task, preserve evidence and report its next step. Integrate the results and verify delivery against the recorded policy. Report conflicts or missing capabilities explicitly.

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.