# Labs — Module 6: The Meta-Agent Factory & Verification Frontier > Five short labs that compose a specialized fleet and gate changes > through it. Each fits in a single focused block; the whole set is > ~95 minutes. The depth scales beyond the labs — see *Stretch* in > each to take them further. | Lab | Title | Time | Maps to | |-----|----------------------------------------------------|---------|--------------------------------------| | 6.1 | Define two specialized agents | 20 min | §6.2 Role-based agent design | | 6.2 | One pass through a Plan → Build → Critic pipeline | 20 min | §6.4 Sequential pipelines | | 6.3 | Run two approaches in parallel via worktrees | 20 min | §6.4 Parallel agents | | 6.4 | CI reviewer comment on one trivial PR | 20 min | §6.6 CI/CD integration | | 6.5 | Red-team one sensitive endpoint | 15 min | §6.7 Adversarial agents | --- ## Lab 6.1 — Define two specialized agents ### Objective Replace a single default agent with two purpose-built ones. The roster grows later; today you need an architect and a critic. ### Time 20 minutes. ### Real-world scenarios - **A — Platform team.** Architect (Opus, read-only) for cross- service decisions; Critic (Sonnet) on every PR diff. - **B — Product team.** Architect (Opus, sparing) on flag-rollout designs; UI-verifier (Sonnet + Chrome MCP) on every PR. - **C — Compliance fintech.** Security-auditor (Opus, ultrathink, read-only); Critic (Sonnet) on all PRs. ### Setup `mkdir -p .claude/agents`. ### Steps 1. Write `.claude/agents/architect.md` with frontmatter (`model: claude-opus-4-7`, `tools: Read, Grep, Glob`) and a body enforcing: weighs ≥2 approaches, no edits, ends with handoff or STOP. 2. Write `.claude/agents/critic.md` with frontmatter (`model: claude-sonnet-4-6`, `tools: Read, Bash(npm test:*)`) and a body demanding per-AC `file:line` evidence + PASS / NEEDS_REVISION. 3. Smoke-test each in a fresh session with a tiny domain-appropriate task. Confirm tool surface holds. ### Deliverable The two agent files committed + `labs/notes/6.1-agents.md` with the two trigger phrases and one smoke-test transcript line each. ### Success criteria - The architect produced no edits (otherwise the tools list is too generous). - The critic produced at least one `file:line` reference. ### Reflection - Where did either agent want to do "just one more thing" outside its lane? That's where the system prompt needs tightening. ### Stretch - Add three more agents (builder, security-auditor, release-manager) over the next week to reach the §6.2 roster. --- ## Lab 6.2 — One pass through a Plan → Build → Critic pipeline ### Objective Ship one *tiny* change through the three-stage handoff. Internalize what changes when your eyes aren't the first reviewer. ### Time 20 minutes. ### Real-world scenarios - **A — Add a new API endpoint** with auth + validation (critic often catches missing rate limit or error-body shape). - **B — Schema migration with backfill** (critic flags lock duration or non-idempotent backfill). - **C — Feature behind a flag** (critic catches flag-check in `useEffect` causing flash of new UI). ### Setup A scratch branch + a tiny spec (one AC from Lab 2.4's proposal is ideal). ### Steps 1. **Architect:** *"Read `<spec>`. Produce a plan with files- touched and acceptance criteria mapped to test names. No edits."* Save to `tmp/plan.md`. 2. **Builder** (default Sonnet session, build mode): *"Execute `tmp/plan.md`. Touch only listed files. Every AC needs a test."* 3. **Critic (fresh session):** *"Review `git diff` against `<spec>`. Per AC, give `file:line` evidence. Verdict: PASS or NEEDS_REVISION."* ### Deliverable `tmp/plan.md`, the committed diff, `tmp/review.md`, and `labs/notes/6.2-pipeline.md` with the critic's catches and a one- line "what this caught I'd have missed." ### Success criteria - The critic surfaces **at least one substantive issue** with `file:line` evidence — not "looks good." - If the critic just rubber-stamps, strengthen its prompt to *demand* one failure mode per AC. ### Reflection - Where did the critic disagree with the builder in a way that *you* would have sided with the critic? ### Stretch - Add a NEEDS_REVISION loop: feed the critic's report back to the builder, re-run critic. Cap at 2 iterations. --- ## Lab 6.3 — Run two approaches in parallel via worktrees ### Objective Genuinely choose between approaches by running both in parallel and comparing artifacts. ### Time 20 minutes. ### Real-world scenarios - **A — Async order events.** Sync vs queue. - **B — Polymorphic comments.** Single-table inheritance vs join table. - **C — Auth migration.** Phased flag vs dual-write. ### Setup ```bash git worktree add ../app-A -b experiment/A git worktree add ../app-B -b experiment/B ``` ### Steps 1. Write two one-paragraph briefs at `tmp/approach-A.md` and `tmp/approach-B.md` — same spec, constrained to different approaches. 2. Launch two builder sessions, one per worktree. Same builder agent, different briefs. Wait for both to converge (use the smallest feasible scope so this fits the window). 3. Critic-compare in a fresh session: *"Compare `tmp/diff-A.patch` and `tmp/diff-B.patch` on correctness, blast radius, simplicity. Recommend one with evidence."* ### Deliverable Two branches + `labs/notes/6.3-parallel.md` with the critic's recommendation, your final choice, and a one-line rationale where they differ. ### Success criteria - The two approaches are *genuinely different* — not variants of the same shape. - The critic's recommendation cites **trade-offs**, not preferences. ### Reflection - Which approach surprised you — better or worse than expected? ### Stretch - Promote the runner-up to a `docs/future-options.md` entry for later revisit. --- ## Lab 6.4 — CI reviewer comment on one trivial PR ### Objective Make agentic review default. One PR opens; the reviewer agent posts a comment via GitHub Actions. ### Time 20 minutes. ### Real-world scenarios - **A — Open-source project.** Welcoming review for new contributors, blocking for maintainers. - **B — Internal monorepo.** Blocks merge only on critical paths (`auth/`, `billing/`, `migrations/`). - **C — Regulated environment.** Output archived for audit. ### Setup ```bash mkdir -p .github/workflows .github/prompts ``` Have `ANTHROPIC_API_KEY` set as a CI secret. ### Steps 1. Copy the workflow template from §6.6 into `.github/workflows/agentic-review.yml`. Adapt the critic agent path and `--max-turns 6`. 2. Add `.github/prompts/pr-review.md` (≤15 lines) demanding `file: line` evidence and a PASS/NEEDS_REVISION ending. 3. Open a trivial PR (one-line change). Confirm the action runs and posts a comment. ### Deliverable Workflow + prompt committed + `labs/notes/6.4-ci.md` with the PR URL (or screenshot) and the per-PR token cost. ### Success criteria - The action runs end-to-end and posts a markdown comment. - The comment contains a verdict and evidence — not generic praise. ### Reflection - What's the bypass procedure for a 2am emergency? Document it now or you'll lose trust in the gate the first time it's wrong. ### Stretch - Add prompt caching (Module 7) for `AGENTS.md` + spec prefix. Re-measure cost. --- ## Lab 6.5 — Red-team one sensitive endpoint ### Objective Run an adversarial agent on one security-sensitive surface and compare its findings to a collaborative critic. ### Time 15 minutes. ### Real-world scenarios - **A — Magic-link auth.** Common finds: token entropy, no browser-binding, log-token echo. - **B — Refund endpoint.** Finds: cap-to-original, idempotency key derivation, error-message enumeration, rounding asymmetry. - **C — Data export.** Finds: IDOR, CSV injection, exported-PII encryption. ### Setup A real change (or a deliberately-flawed branch) on a sensitive path. ### Steps 1. **Collaborative critic** pass on the diff (fresh session). Save findings. 2. **Red-team** pass (`.claude/agents/red-team.md`, Opus, ultrathink): *"Find ≥3 concrete attacks. Each: specific input + incorrect behavior. Cite `file:line`. Do not propose fixes."* 3. Triage: must-fix / nice-to-have / already-mitigated / false- positive. Note the red-team finds that the critic missed. ### Deliverable `labs/notes/6.5-red-team.md` with both findings side-by-side and the triage table. ### Success criteria - Red-team finds **at least one** concrete attack the critic missed. - The triage explicitly accounts for *every* finding, including false positives with reasons. ### Reflection - The prompt tone alone shifts findings. What does that teach about how you frame review requests — to agents *and* to humans? ### Stretch - Wire red-team into CI but **only on paths matching** sensitive directories. Don't run it on every PR. --- ## Wrap-up In the repo (committed): At least two agent files, a workflow + prompt, possibly a red-team agent. In `labs/notes/`: `6.1` through `6.5`. You now have a factory in miniature. Module 7 makes it measurable. **Next:** [Labs — Module 7: The Human-in-the-Loop & Strategic ROI](07-human-in-the-loop-labs.md)