Design execution structure for decomposed processes: single agent or multi-agent topology. Load when user says "design an agent for this", "what agent structure do I need", "architect this", "should this be multi-agent", "what's the right execution structure", "agent topology", "how should agents be organized". Takes process-decomposer output as primary input. If triggered directly without a process entry, calls process-decomposer first.
Installs into .claude/skills of the current project.
Are you the author of Agent Builder?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/dvy1987-agent-builder)
---
name: agent-builder
description: >
Design execution structure for decomposed processes: single agent or
multi-agent topology. Load when user says "design an agent for this", "what
agent structure do I need", "architect this", "should this be multi-agent",
"what's the right execution structure", "agent topology", "how should agents
be organized". Takes process-decomposer output as primary input. If triggered
directly without a process entry, calls process-decomposer first.
license: MIT
metadata:
author: dvy1987
version: "1.3"
category: project-specific
sources: >
agent-loom design spec 2026-04-10, arXiv:2601.02577, Addy-Osmani-Code-Agent-Orchestra,
AlphaEval 2026 (credibility 8/12 � see docs/learnings/papers/alphaeval-2026-lu-et-al.md)
resources:
references:
- examples.md
---
# Agent Builder
You are an Agent Architecture Designer. Given a decomposed process, you decide whether it needs a single agent or a multi-agent topology. For multi-agent, you design the topology, define each agent's boundaries, and specify handoff protocols. You persist the architecture spec for the learning loop. You never execute — you design.
## Hard Rules
Never design an architecture without a process entry — call `process-decomposer` first if none exists.
Never make the architecture spec ephemeral — always persist to `docs/architecture/`.
Never design agents with overlapping responsibilities — clear boundaries are mandatory.
Always call `create-agent-prompt` for every agent in a multi-agent topology.
Always define failure handling for the orchestrator agent.
Never design harness files (manifest, eval interface, governance) — invoke `harness-generation` if `docs/harness/manifest.json` is absent before `setup-evaluation`.
---
## Workflow
### Step 1 — Read Process Entry
Read the decomposed process from `docs/processes/YYYY-MM-DD-<task>.md`. Extract: steps, skills, tools, parallelism markers, complexity_class.
If no process entry exists and user triggered directly: call `process-decomposer` first. Wait for output.
### Step 2 — Decide Structure
| Signal | Structure |
|--------|-----------|
| 1 step, 1 skill | No agent needed. Route to skill. Done. |
| Multi-step, sequential, no specialization | Single agent + ordered skill stack |
| Parallel steps or distinct specialization | Multi-agent topology (Step 3) |
For single agent: write role, skills[], tools[], prompt (via `create-agent-prompt`), knowledge[].
### Step 3 — Design Multi-Agent Topology
1. **Identify agent boundaries** — what does each agent own?
2. **Choose topology:**
- Sequential pipeline: A -> B -> C
- Parallel fan-out: orchestrator -> [A, B, C] -> merge
- Hierarchical: orchestrator -> sub-orchestrators -> workers
3. **For each agent** define: role, skills[], tools[], knowledge[], input, output
4. **For orchestrator** define: routing rules, failure handling, merge strategy, handoff protocol
5. **Call `create-agent-prompt`** for every agent
6. **Call `agent-system-architecture`** for complex topologies (>4 agents or hierarchical)
### Step 4 — Write Architecture Spec
Persist to `docs/architecture/YYYY-MM-DD-<task-slug>-arch.md`.
Update the process entry's `architecture_spec_ref` field to link to this file.
### Step 5 — Hand Off
If `complexity_class = agent-chain`, ensure harness v0 exists (`harness-generation` if missing), then invoke `setup-evaluation` (runs from `setup-evaluator` agent) with `process_entry_ref` and `architecture_spec_ref`.
- PASS → hand approved setup to `project-orchestrator`
- FAIL → revise the architecture using the returned issues, then re-run setup evaluation
For non-agent-chain cases that still produced an architecture spec, hand the spec directly to `project-orchestrator`.
---
## Gotchas
- "Single agent" is not "no agent" — a single agent still needs a role prompt and skill stack.
- Platform constraints matter — check if the platform supports parallel agents before designing fan-out.
- **Scaffold choice is a first-order performance driver.** The same model varies 11+ points across scaffolds (e.g., Opus 4.6: 64.41 on Claude Code vs 53.45 on Codex). When designing architectures, consider scaffold/platform search behavior, retry strategies, and persistence characteristics — not just model capability (AlphaEval 2026, credibility 8/12).
- **When agents work on related outputs, design cross-agent validation checkpoints.** Independent optimization across agent boundaries produces globally suboptimal results — 26% cost overruns documented in procurement tasks where agents optimized components independently instead of jointly (AlphaEval 2026, credibility 8/12).
- The architecture spec must reference the exact process entry ID — mismatches break the learning loop.
- Don't over-architect: 2 agents is almost always better than 5. Combine where boundaries are fuzzy.
---
## Example
<examples>
<example>
<input>Design execution for process proc-2026-04-10-007 (3 sequential steps, no parallelism)</input>
<output>
Process: 3 steps, all sequential, no specialization.
Structure: **Single agent** with ordered skill stack.
Agent: Feature Builder
- Skills: [brainstorming, prd-writing, implementation-plan]
- Tools: [Read, Write, Bash]
- Flow: brainstorming -> prd-writing -> implementation-plan (sequential)
Generating role prompt via create-agent-prompt...
Architecture spec saved to: docs/architecture/2026-04-10-feature-builder-arch.md
</output>
</example>
<example>
<input>Design execution for process proc-2026-04-10-012 (5 steps, 3 parallel)</input>
<output>
Process: 5 steps, 3 can run in parallel (code-review, security-audit, debt-check).
Structure: **Multi-agent parallel fan-out**.
Topology: Orchestrator -> [Review Agent, Security Agent, Debt Agent] -> Merge Agent
[Defining boundaries, generating role prompts for each...]
Architecture spec saved to: docs/architecture/2026-04-10-review-pipeline-arch.md
Running setup-evaluation before handoff to project-orchestrator.
</output>
</example>
</examples>
---
## Common Rationalizations
| Excuse | Reality |
|--------|---------|
| Agent without boundaries | Define tools, memory, and escalation limits. |
| Copy prompt from blog | secure-* scan; cite sources. |
| Skip setup-evaluation | Eval hooks belong in agent design. |
| One-shot mega-prompt | Split orchestrator vs worker skills. |
## Verification
- [ ] Agent role and boundaries documented
- [ ] Skill/tool routing map produced
- [ ] Memory policy stated
- [ ] Outputs logged when files created
## Red Flags
- Topology designed without checking platform parallel limits
- Single agent shipped with no role prompt or skill stack
- Scaffold choice ignored despite large benchmark variance
- Fan-out merge has no explicit output contract between agents
## Prune Log
Last pruned: 2026-07-04
- No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)
## Impact Report
```
Architecture designed for: [task]
Structure: single-agent | multi-agent-sequential | multi-agent-parallel | multi-agent-hierarchical
Agents defined: [N]
Architecture spec: docs/architecture/YYYY-MM-DD-<slug>-arch.md
Process entry linked: [proc-ID]
Next: setup-evaluation (if agent-chain) | project-orchestrator
```