Lesson 6: Focused Agents

Tactical Agentic Coding

The one tactic: One agent, one prompt, one purpose — use specialized agents with focused prompts to achieve a single purpose.

Overview

This lesson completes the software developer lifecycle by adding the last two steps: review and document. With plan, build, test, review, and document all automated, a single prompt can trigger a fleet of agents that ship your work end to end — using your expertise, in your product, on your domain problems.

Review is distinct from testing and deserves its own step. Every SDLC step is a question and an answer. Plan asks "what are we building?" Build asks "did we make it real?" Test asks "does it work?" Review asks "is what we built what we planned — now prove it?" Document asks "how does it work?" Reviewing is not about code quality or implementation details; it hands those to the agents and asks the single specific question: is what was built what we asked for?

Documentation then closes a full feedback loop. Inside the Agentic layer, documentation gives future agents feedback on work done — and, through conditional documentation, tells them exactly when to pull a given doc into their context.

The tactic that makes all of this work is controversial but powerful: one agent, one prompt, one purpose. No agent runs more than a single prompt — though that prompt may be a large meta prompt, template, or higher-order prompt doing heavy work.

Key concepts

One agent, one prompt, one purpose

More context is not better. Massive context windows produce a distracted, confused agent — context pollution, context overload, toxic context. Overloading the window makes the agent lose focus on the original task. Every piece of context you add increases the variables the agent must reason about. Context-engineer as little as possible: the minimum context required to solve the problem. The compact command is a band-aid; if your agent is compacting, it is losing information.

The three constraints

Agentic engineers face three constraints. Specialized one-purpose agents bypass two of the three:

1. The context window — bypassed by giving the single agent all the space for one problem.
2. The complexity of the codebase / problem — bypassed by working one focused step at a time.
3. Your own abilities — the remaining real constraint.

Model intelligence is not a constraint — treating it as one is a losing mindset. The side effect of one-purpose agents: every prompt is committable, reproducible, and improvable down to the prompt level, which passively forms evals for your Agentic layer.

Review vs test

Testing answers "does it work?" Review answers "is what we built what we asked for?" Group them together and you lose the review velocity that agents unlock. Review produces a hard asset — an image, video, or report — that proves what was built matches what was asked. That proof-of-value directly increases review velocity.

Skippable / tech-debt / blocker triage

When agents review your work they will find issues — they are agreeable and good at debugging, so if you ask them to find something, they will. Give them categories so they know what matters. A review issue is one of three classes:

• Skippable — do not block.
• Tech debt — do not block.
• Blocker — block and resolve agentically.

Only blockers trigger the resolution loop. Resolution loops over blocking issues and runs create and implement patch — a surgical, minimal, targeted change (the slash patch meta prompt), bounded by a max-loop retry count.

The state object

Meta-information travels along every ADW in a state.json: ADW ID, branch name, plan file, issue class. Workflows validate that the state they need exists before running — you cannot review if there is nothing to review against. Plan and build are the essential methods; test, review, and document all run against their output.

Conditional documentation

Documentation has two steps: create docs for the work done, then know when and how to pull docs in. The document step is a template meta prompt that (a) writes concise markdown to app_docs/, and (b) updates a conditional_docs prompt. That conditional-docs file lists conditions and the docs to read when a condition matches. It is referenced inside bug, chore, feature, patch, and prime — so a future agent fixing a bug reads only the docs relevant to its task. This connects the end of the SDLC (documenting) back to the beginning (planning) into one full feedback cycle.

How to apply it

1. Run every agent as one prompt with one purpose — never chain many prompt calls into a single distracted agent.
2. Give the single agent the minimum context needed and the full window for that one problem.
3. Add a distinct review step that answers "is what we built what we asked for?" and produces a hard proof asset (image/video/report).
4. Have review classify issues as skippable, tech-debt, or blocker; only block and auto-resolve on blockers.
5. Resolve blockers with a surgical patch — minimal, targeted changes — bounded by a retry cap.
6. Carry a state.json (ADW ID, branch, plan file, issue class) through every workflow and validate it up front.
7. Document at the end: generate concise markdown and update conditional documentation.
8. Reference conditional docs inside your plan/bug/feature/patch prompts so agents pull the right docs at the right time.
9. Compose the low-level ADWs (plan, build, review, document, patch) into pipelines like plan-build-review or plan-build-document.

Commands & conventions

Command / ADW	Purpose
slash review (ADW)	Find spec from branch, diff vs plan, screenshot, resolve blockers, update PR
slash document (ADW)	Generate app_docs/ markdown + update conditional docs
slash patch	Meta prompt: concise, surgical patch plan for one issue
ADW patch	Create patch plan, then run implement
plan-build-review	Composed workflow
plan-build-document	Composed workflow
slash implement <plan>	Higher-order prompt: read plan, think hard, implement

Review-issue type (three classes) and the R2 upload of review screenshots make proof reviewable on the PR/issue:

review_result:
  success: bool
  review_summary: str
  issues: [ { class: skippable | tech_debt | blocker, ... } ]
  screenshots: [ ... ]
  screenshot_url: str   # uploaded to a public bucket (e.g. Cloudflare R2)

Directory conventions:

adws/            # low-level ADWs + composed workflows + adw_modules/
app_docs/        # agent-generated docs for THIS codebase
ai_docs/         # third-party / external docs
.claude/commands/conditional_docs.md   # condition -> docs to read
agents/<adw-id>/ # per-agent logs + state.json

Key takeaways

• One agent, one prompt, one purpose: focus beats a bloated context window.
• Model intelligence is not a constraint; the context window and codebase complexity are — one-purpose agents bypass both.
• Review is its own step answering "is what we built what we asked for?" — distinct from testing.
• Review produces a hard proof asset (image/video/report) that raises review velocity.
• Triage review issues as skippable / tech-debt / blocker; only block on blockers, resolve with surgical patches.
• A state.json (ADW ID, branch, plan, issue class) threads every workflow; plan + build are the essential methods.
• Conditional documentation connects the end of the SDLC back to the start into one full feedback loop.
• Skipping the test step lets real bugs (like a misplaced button) slip through — keep the steps you need.

Notable quotes

"One agent, one prompt, one purpose."

"Massive context windows often leads to a distracted, confused agent. This is context pollution."

"This isn't about you anymore. This is about your agents... teaching your agents how to build on your behalf."

"Review answers the critical question: is what we built what we asked for?"