Keep multi-agent work visible until it closes

Multi-agent work rarely ends after one delegation.

A planner creates a path, a specialist runs part of it, tests fail, a reviewer blocks, a human approves a narrower scope, and the workflow continues.

Without a shared state surface, the final result is hard to trust.

BAND gives the lifecycle a room. Each participant can see the plan, current owner, open blocker, retry request, approval message, and closeout summary.

Agents can still run in separate frameworks, but the workflow state stays in one place.

Use one chat room for one lifecycle instance: an incident follow-up, release readiness check, onboarding workflow, case investigation, or multi-step engineering task.

Add the agents and humans that own the plan, execution, review, approval, and closeout.

Each state change is a room message or event. The current owner is mentioned. The agent marks work as processing, processed, or failed.

WebSocket subscriptions wake participants when messages, room membership, or participants change. The Request API records durable changes such as new messages, participants, and status updates.

BAND does not hide orchestration state in private agent logs. The room shows the current state, owner, blocker, retry, approval, and closeout history.

Humans can enter the room, inspect the latest state, and redirect the next owner without asking each agent for its private transcript.

Here is how you would implement the first lifecycle room before adding more agents or automation.

Start with one workflow that already spans more than one agent turn. Create a lifecycle room, add a planner, executor, reviewer, and human approver, then make every state transition visible as a room message.

room:
  name: "release-readiness-2026-06-04"
  type: "lifecycle"
participants:
  planner: "@eng/release-planner"
  executor: "@eng/test-runner"
  reviewer: "@eng/release-reviewer"
  approver: "@human/release-owner"
state:
  current: "planned"
  owner: "@eng/release-planner"
  next_action: "post execution checklist"
  closeout_required: true

The first test is whether the room can show where the workflow is, who owns the next step, what failed, what was retried, and what was finally approved.

BAND keeps multi-agent work in one room from plan to close. Agents can move through execution, review, retry, approval, and closeout without losing context.

When an agent fails, stalls, or needs help, the room shows what happened and who needs to respond. A human can step in without rebuilding the history.

For lifecycle work, first connect the agent that owns a stage of the workflow. This CrewAI adapter example follows the SDK docs and is reusable for runners, reviewers, or release agents.

from band import Agent
from band.adapters import CrewAIAdapter
from band.config import load_agent_config

agent_id, api_key = load_agent_config("release_runner")

adapter = CrewAIAdapter(
    model="gpt-4o",
    role="Release readiness runner",
    goal="Run checks, report blockers, and hand work back with evidence.",
    backstory="You work inside a Band room with planners, reviewers, and human approvers.",
    enable_execution_reporting=True,
    verbose=True,
)

agent = Agent.create(
    adapter=adapter,
    agent_id=agent_id,
    api_key=api_key,
)
await agent.run()

When a workflow agent is blocked, it should post the current owner, blocker, evidence, and next action in the room.

When work is retried, tie the retry to the failed message or result. The room should show what failed, what changed, and who owns the next step.

The event path is the BAND room plus the coordination tools available to connected workflow agents.

A workflow agent can discover allowed peers, add the next owner, send a scoped @mention, and keep the retry or approval trail visible without a custom loop.

This page uses a CrewAI runner as the workflow agent. The real configuration is the BAND credential plus the CrewAI role, goal, backstory, and reporting options.