Crush's Agent Composition Model - Why A2A support makes Crush amazing

crush-composition-pitch.md

Crush's Agent Composition Model

Layer 1: Local agent composition

You define specialized agents in your config — each with its own tools, model, prompt, and constraints:

# A tester agent with bash + test tools
agent add tester --role dispatch \
  --tools bash,grep,view,todos \
  --prompt "Write and run tests. Be thorough." \
  --model small

# A read-only reviewer
agent add reviewer --role dispatch \
  --tools @read \
  --prompt "Review code for bugs, style, and architecture." \
  --model large

# A docs writer
agent add docs --role dispatch \
  --tools view,edit,write \
  --prompt "Update documentation to match code changes." \
  --model small

The main agent sees all of them in the dispatch_agent tool's enum and dynamically composes them based on the task. "Add tests and update docs" → dispatch tester and docs in parallel, each in its own worktree, each with the right tools and model.

Layer 2: Remote agent composition

Here's where it gets crazy. You can pull in any A2A agent from anywhere:

# Your team's centralized reviewer service
agent add team-reviewer --role dispatch --runtime a2a \
  --card https://reviewer.yourcompany.com/.well-known/agent-card.json \
  --bearer '$TEAM_TOKEN'

# A vendor's security scanner
agent add security-scan --role dispatch --runtime a2a \
  --card https://secscanner.vendor.com/agent-card.json \
  --bearer '$VENDOR_TOKEN'

# An open-source community agent
agent add go-expert --role dispatch --runtime a2a \
  --card https://agents.example.com/go-expert/card.json

Now the main agent can dispatch to remote third-party agents using the same dispatch_agent tool. The Agent Card is the universal interface — it tells Crush what the agent can do, what auth it needs, and where to send tasks. The main agent doesn't care if it's local or remote; it just dispatches by name.

Layer 3: Runtime orchestration

The main agent becomes an orchestrator. It can:

• Dispatch tester locally to write tests
• Dispatch team-reviewer remotely to review the code
• Dispatch security-scan remotely to check for vulnerabilities
• Dispatch docs locally to update documentation

All four run in parallel, each with the right tools/model/credentials, all coordinated through A2A. The main agent reviews each result as it comes in, applies the work, and keeps going.

The ecosystem play

This isn't just about your agents. Any A2A-compatible agent becomes a composable building block:

• Internal tools: Your company's reviewer bot, your CI agent, your deployment agent
• Vendor services: Security scanners, compliance checkers, specialized domain agents
• Community agents: Open-source agents for specific languages, frameworks, or tasks
• Team sharing: Your teammate's specialized agent becomes available to you via their card URL

The Agent Card is like a package manifest — it declares capabilities, auth requirements, and interfaces. Crush's A2A client handles the rest.

Why this matters

Traditional agent systems are monolithic — one agent, one context, one set of tools. Crush's composition model is modular and extensible:

• Specialization: Each agent has focused tools and prompts
• Parallelism: Up to 4 concurrent agents, each isolated in its own worktree
• Extensibility: Add remote agents without changing Crush's code
• Interoperability: Any A2A agent works — you're not locked into a vendor's ecosystem
• Dynamic composition: The main agent decides which agents to use based on the task

The pitch: Crush turns the agent from a monolithic tool into a composable agent platform. You define agents locally, discover them via cards, dispatch them in parallel, and extend to remote third-party agents — all through one standard protocol. That's not just multi-agent; that's agent composition as a first-class feature.