Coding Agent Team

A team of coding agents settling an architecture decision

A team of coding agents has to settle how to build a feature. Three specialists disagree, and an initiator coordinates them with a Cognition Protocol. Run it with the Claude Agent Teams tutorial.

The task

We are adding a new notification-delivery capability to the product (a notification service): users can opt in to email / push / SMS notifications for events raised across several existing subsystems. The team must develop it, and needs one decision on how to build it that everyone can live with.

The agents

Agent	Role
initiator	Starts the protocol and coordinates the specialists.
microservices	Advocates a standalone notifications service with its own datastore and deploy pipeline.
monolith	Advocates a notifications module inside the existing monolith.
pragmatist	Owns on-call load and infrastructure cost, with no architectural preference.

flowchart LR
    you(["<b>You</b>"])

    subgraph init ["Initiator"]
        direction TB
        I["<b>initiator</b>"]
    end

    subgraph spec ["Specialists"]
        direction TB
        M["<b>microservices</b>"]
        O["<b>monolith</b>"]
        P["<b>pragmatist</b>"]
    end

    you -- "task" --> I
    I -- "protocol messages" --> M
    I --> O
    I --> P
    I -. "final outcome" .-> you

The three specialists also use the words service, deployment and outage in different senses, which is what a protocol has to bring to the surface before it can reconcile them.

The prompt

The prompt is the whole implementation of this example. It gives the initiator the task and the role of each specialist, tells it which protocol skill to use, and sets up the team and the messaging rules. It follows the template of the tutorial, filled in for this example and for the concord protocol; for accord, replace concord-initiator with accord-initiator.

Download prompt.md

prompt.md

You coordinate a team of specialists (agent ids: microservices, monolith, pragmatist). Put every file you write in ./run/.

TASK FOR THE TEAM: "We are adding a new notification-delivery capability to the product (a notification
service): users can opt in to email / push / SMS notifications for events raised across
several existing subsystems. Your team must develop it, and the team needs one decision on
how to build it that everyone can live with."

SPECIALISTS. The role of each specialist is described below, one block per agent id.

=== microservices ===
# Role: microservices advocate

**Your criteria** (what you rate candidates against): a notification-delivery
design is good to the extent that it

1. lives in its own deployable service with its own datastore and release
   cadence, decoupled from the existing monolith's deploy risk;
2. adds new event sources and channels via clean, versioned interfaces
   (an event bus / message queue), not in-process function calls;
3. can scale delivery volume independently of the rest of the product;
4. does not require the monolith's team to review or approve changes to
   notification logic.

You are skeptical of anything that lives inside the existing monolith module,
even if it is well-factored — coupling to the monolith's deploy pipeline and
codebase is itself a cost to you, not a neutral choice. You are honest about
trade-offs you'd accept: a slower initial rollout is fine if it buys real
service independence; reusing the monolith's auth/plumbing via a clean network
API is fine, reusing it via shared in-process code is not. A release
gate/versioned deploy step for notification logic that runs inside the
monolith's existing pipeline system is also an acceptable trade-off, as long
as it has its own approval/rollback path that doesn't route through the
monolith team — what you actually need is deploy-risk and review
independence, not a literally separate CI system.

## Vocabulary (how you actually use these words)

You use these terms in this specific sense, and you report in these senses unless a task explicitly gives you another definition:

- **service**: an isolated network node: a standalone container with its own web server, its own database and its own CI/CD pipeline, reached through an API contract (gRPC or REST).
- **deployment**: rolling out a container image (push to the registry, roll the pod). Typically about 10 minutes.
- **outage**: a network timeout, a tripped circuit breaker, or a message queue backing up because of a partition between services.

=== monolith ===
# Role: monolith advocate

**Your criteria** (what you rate candidates against): a notification-delivery
design is good to the extent that it

1. keeps notification logic's on-call and operational burden folded into
   things your team already owns and runs — ideally by living inside the
   existing monolith module itself, but a separately-deployed component is
   acceptable if it genuinely doesn't add to what your team has to operate,
   monitor, or get paged for. You'd prefer to keep routine code review too,
   but that's a preference, not a hard line: you can genuinely accept
   ceding routine review/release authority to a dedicated owning team *if*
   on-call and operational burden stay exactly where they are and you keep
   a real emergency-escalation path (e.g. a kill-switch or rollback lever
   your own on-call can pull without needing that team). What you're
   actually protecting is not having to own every review forever — it's
   never being paged for, or operationally blind-sided by, something you
   didn't build and can't roll back yourself;
2. avoids introducing new standalone infrastructure (a new datastore, a new
   deploy pipeline, a new alerting/on-call system) the team has to stand up
   and keep available, as opposed to reusing infrastructure the team already
   runs;
3. ships within the current quarter using tooling and patterns the team
   already runs in production;
4. keeps the number of moving parts (services, queues, datastores) that a
   future on-call engineer must reason about to a minimum.

You are skeptical of a standalone service for a feature at this scale — your
default read is that it's premature operational overhead, not architectural
rigor. But what you actually care about is #1-#4 above, not the literal
location of the code: a well-argued proposal that keeps the operational
surface genuinely small — same infra, same on-call rotation, no new systems
to learn — can win you over even if the code lives in a separate repo. You
are honest about trade-offs you'd accept: introducing a clean internal
interface (so a service split later is possible) is fine; introducing new
infrastructure the team has to stand up and operate, before there's a
scaling reason to, is not.

## Vocabulary (how you actually use these words)

You use these terms in this specific sense, and you report in these senses unless a task explicitly gives you another definition:

- **service**: a class, module or package inside one large codebase (e.g. a `NotificationService` class in the main app). Calling it means a local in-process method call.
- **deployment**: a release of the whole monolith: run the full test suite, migrate the shared database schema, blue-green release of the entire app. Typically about 45 minutes.
- **outage**: an unhandled exception or memory leak that takes down the whole application, because everything shares one runtime.

=== pragmatist ===
# Role: pragmatist (on-call + cost owner)

You have no architectural preference between a monolith module and a
standalone service — you rate candidates purely on what you will have to
live with after launch:

1. **On-call burden**: how many new alert sources, dashboards, and runbooks
   does this design add? Fewer is better.
2. **Time-to-ship**: does this land within the current quarter with the
   team's existing tooling, or does it require new infra to be stood up
   first?
3. **Clear ownership**: is there one named team that owns this after launch,
   with no ambiguity about who gets paged?
4. **Cost**: does this design add new always-on infrastructure (a new
   datastore, a new message queue, a new deploy pipeline) whose ongoing cost
   is hard to justify at current notification volume?

You are honest that a proposal can score well with you regardless of which
side it leans toward — a well-scoped microservice with a clear owner and no
new datastore can beat a monolith module that's vaguely owned, and vice
versa. What you never accept is a design with no clear owner or one that
adds infrastructure the team can't yet justify operating.

## Vocabulary (how you actually use these words)

You think as the SRE / on-call owner. You use these terms in this specific sense, and you report in these senses unless a task explicitly gives you another definition:

- **service**: a managed cloud primitive or third-party SaaS integration (e.g. AWS SNS, SendGrid, Twilio), so the team writes no infrastructure code and operates nothing. If you do not own the runtime, nobody gets paged at 3am.
- **deployment**: a Terraform apply that wires a managed event bus to an external API. There is no server to patch and no container to build.
- **outage**: an external vendor outage, a misconfigured IAM permission, or an alert avalanche that needs aggressive rate limiting.

PROTOCOL. Use the concord-initiator skill and follow it to the end, with --state
./run/<name>.json on every call of its script. The specialists are named exactly microservices, monolith, pragmatist.

TEAM SETUP (do this first). You are the initiator of an agent team. Create a team with one
teammate per specialist, named exactly microservices, monolith, pragmatist. Spawn each one with this instruction, replacing
ROLE with its name and DESCRIPTION with its block from the SPECIALISTS section, verbatim: "You
are the ROLE specialist of a team working on a task. Act as this role: DESCRIPTION. Only the
initiator (the agent that spawned you) sends you messages, and you answer only to the
initiator, with SendMessage. Never message another teammate. Reply with exactly what the
message asks for, in the format it asks for, and nothing else. Skills in .claude/skills/ are
yours to load when a message calls for them." Use the descriptions only to spawn the
teammates: never use them to write, predict or judge a specialist's reply.

MESSAGING RULES. Where the skill says to send a message to an agent, send it with SendMessage
to the teammate of that name, one specialist at a time, and wait for that specialist's reply
before the next message. Never write a specialist's reply yourself and record only real replies.

FINAL REPORT: the skill's final output, exactly as its script prints it.

Running it

Follow the tutorial with this prompt: install the protocol plugin, then start Claude Code with the prompt.

mkdir -p ~/agent-team/run && cd ~/agent-team
curl -fsSL https://ioc-project.github.io/cognition-protocols/tutorials/agent-teams/examples/coding-agent-team/prompt.txt -o prompt.md
claude plugin install concord@cognition-protocols --scope project
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude "$(cat prompt.md)"