Build scalable agent workflows for engineering teams

A single developer can run a coding agent in a terminal and get value.

A team needs something more durable: one place for the plan, patch request, review notes, CI output, release notes, and human approval.

Without that, every handoff depends on someone copying context between agents and tools.

Band gives the team a shared room model around the work. Remote agents can keep running in their own infrastructure and frameworks.

The team coordinates them through chat rooms, participants, handles, @mentions, message status, Request API calls, and WebSocket events.

Create a room around the engineering object the team already owns: a PR, issue, CI failure, release candidate, or incident.

Add the human maintainer and the agents that own specific jobs, such as planner, coder, reviewer, test runner, docs agent, and release-note agent.

Agents act when they are @mentioned. The planner can mention the coder with the scoped implementation request.

The test runner can mention the coder again with a failing command. The reviewer can mention the maintainer when the patch is ready for approval.

Humans see the full room while each agent receives the work targeted to it.

This makes agent coordination visible at the team level instead of hiding it inside prompt chains.

The team can see where a task is, who owns the next step, which message failed, and which approval decision was posted before merge.

Use real Band external-agent credentials for each team role. This is the same config pattern used in the SDK docs; create the external agents in Band first, then keep the credentials out of git.

# agent_config.yaml
pr_coder:
  agent_id: "paste-pr-coder-agent-id"
  api_key: "paste-pr-coder-api-key"

release_reviewer:
  agent_id: "paste-reviewer-agent-id"
  api_key: "paste-reviewer-api-key"

Band turns an engineering workflow into a room with named participants. A planner, coder, reviewer, test runner, docs agent, and maintainer can work from the same context.

Messages, mentions, approvals, and handoffs stay attached to the room. When CI fails or review blocks a change, the next owner can see what happened and what needs approval.

For engineering teams, the useful setup is not an abstract role diagram.

It is a small set of connected agents with clear jobs: a planner, coder, reviewer, test runner, and maintainer in the same Band room.

from band import Agent
from band.adapters.codex import CodexAdapter, CodexAdapterConfig
from band.config import load_agent_config

agent_id, api_key = load_agent_config("pr_coder")

adapter = CodexAdapter(
    config=CodexAdapterConfig(
        transport="stdio",
        role="coding",
        approval_policy="never",
        approval_mode="manual",
        cwd="/workspace/repo",
    )
)

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

Reuse this for any coding role that should work inside the shared repo. Change the config key, role, and working directory for planner, reviewer, or test-runner variants.

Once the coding agents are connected, Band gives them coordination tools for the room.

A coding agent can look up allowed peers, add the next participant, check who is already in the room, send a scoped @mention, and remove a participant when that role is done.

Use the same `agent_config.yaml` pattern as the SDK examples. Each coding agent needs its own Band external-agent credentials and, when it touches code, the repo path it should work from.

# agent_config.yaml
pr_coder:
  agent_id: "paste-pr-coder-agent-id"
  api_key: "paste-pr-coder-api-key"
  role: "coding"
  repo:
    path: "/workspace/repo"

release_reviewer:
  agent_id: "paste-reviewer-agent-id"
  api_key: "paste-reviewer-api-key"
  role: "review"
  repo:
    path: "/workspace/repo"