Multi-Agent Workflow Patterns

Building software with AI agents works better when you give each agent a clear role and wire them together with explicit handoffs. These four workflows cover the core development activities: researching, building, documenting, and assessing security. Each one uses a primary agent that coordinates specialist subagents, and every workflow includes GPT-backed review cycles before the output is finalized.

Research workflow

The research workflow produces a single written deliverable and then improves confidence through separate checks for writing quality and factual accuracy.

The pipeline

1. Draft — the Researcher writes a full markdown document using available tools, saved to disk under documents/research/
2. Self-proofread — the Researcher cleans up grammar, clarity, and structure before sending to external review
3. Proofread (GPT) — a proofreader subagent checks editorial quality: grammar, clarity, structure, consistency, and completeness
4. Accuracy check (GPT) — a separate subagent checks factual accuracy, technical correctness, logical consistency, source validity, and currency
5. Reconcile and save — the Researcher deduplicates findings from both GPT passes, independently verifies each one, applies valid fixes, and saves the final document

Why two reviewers instead of one

Writing quality and factual accuracy are different skills. A single pass tends to blend them, missing issues in both categories. Splitting them lets each reviewer focus on one job and produce sharper findings.

The final output states what was researched, where the file was saved, how many findings came from each reviewer, and how many were accepted versus rejected.

Implementation workflow

The implementation workflow moves from design through code to structured review, with two complete review cycles before delivery.

Choosing the path

The workflow starts with a routing decision:

• Architect path — for larger work that needs design. The Architect scopes the work, offloads codebase research to an Explore subagent, estimates effort, and writes a structured architecture document
• Direct path — for small, well-scoped tasks. The Implementer clarifies requirements, researches patterns, and builds an implementation plan. If the work grows too large, it routes back to Architect

The architect pipeline

1. Design — Architect loads project knowledge, asks clarifying questions, offloads codebase research to Explore, and writes the architecture to .architect-output/architecture.md
2. Scrutinize (GPT) — the architecture is reviewed against requirements coverage, reference patterns, database design, API consistency, permissions, migration sanity, and task split validity
3. Handoff — formal handoff to Implementer with explicit instructions to follow the architecture document

The implementation pipeline

4. Implement — Implementer loads relevant skills, works task by task, and tracks every changed file in .architect-output/changed-files.md
5. Review cycle 1 (GPT) — Code Reviewer checks the full changed file set, self-verifies findings, then runs two GPT scrutiny passes. Findings go back to Implementer
6. Fix — Implementer fixes every finding (minor, major, and critical) before the second review
7. Review cycle 2 (GPT) — Code Reviewer verifies the fixes with another two-pass GPT scrutiny. Any remaining issues are escalated rather than looped
8. Summary — final output includes files created, files modified, migrations, review cycle count, auto-fixed findings, and anything unresolved

Why two review cycles

The first cycle finds issues. The second cycle verifies the fixes actually resolved them without introducing new problems. If issues persist after cycle two, they're escalated to a human rather than spinning in an unbounded loop.

Documentation workflow

The documentation workflow produces matched pairs of business and technical documents, working through a backlog one feature at a time.

The pipeline

1. Queue — Documenter reads documents/documentation-backlog.md and creates a todo list with one feature per item
2. Draft business document — a Draft Documenter subagent reads every relevant source file and writes a business-focused document for PM and analyst audiences
3. Draft technical document — a separate Draft Documenter run reads the same source code plus the sibling business document, then writes the technical reference
4. Verify (GPT) — a verifier reads both documents and the source code together, checking completeness, accuracy, pattern adherence, cross-document consistency, and clarity
5. Fix and update — Documenter applies fixes for critical and major findings, saves the files, and updates the backlog status
6. Repeat — move to the next feature in the backlog

Why sequential, not parallel

Documentation runs one feature at a time so the drafts, checks, and backlog status stay aligned. Parallelizing would risk inconsistencies between the business and technical documents for the same feature.

A key constraint: this workflow deliberately avoids using fast exploration subagents for code reading. Documentation accuracy requires the higher-quality drafting subagent to read source files directly rather than relying on summarized output.

Security workflow

The security workflow is a structured read-only assessment that ends with a prioritized report, not code changes.

The pipeline

1. Scope and threat intelligence — Pen Tester defines the assessment scope and researches current CVEs, advisories, and relevant threat intelligence before touching any code
2. Dependency and config audit — reviews requirements files, security configuration, rate limiting, Docker setup, and secrets handling
3. OWASP Top 10 review — steps through access control, injection, cryptographic failures, misconfiguration, logging gaps, SSRF, and the other OWASP categories. Removes false positives and calibrates severity
4. Scrutiny round 1 (GPT) — verifies exploitability of findings, looks for missed attack paths, challenges severity ratings, and produces merged or rejected findings
5. Scrutiny round 2 (GPT) — checks the merged report for remaining blind spots, severity consistency, and remediation quality
6. Final report — structured report with executive summary, threat intelligence, findings, documented exceptions, and recommendations

Why read-only

The security workflow explicitly prohibits modifying code. The deliverable is a report with prioritized findings and recommendations. Separating assessment from remediation prevents the assessor from silently fixing issues that should be visible to the team, and keeps the assessment independent.

Documented exceptions

Every codebase has intentional security decisions that look like vulnerabilities. The workflow carries a list of documented exceptions — things that are explicitly allowed and should not be flagged. This prevents recurring false positives from polluting the findings.

Common patterns across all four workflows

These workflows share several structural choices:

• Primary agent plus specialist subagents — one coordinator owns the flow; heavy lifting is pushed to focused subagents
• GPT-backed review cycles — external review is always separate from the work itself, with explicit scrutiny passes
• Persisted artifacts — workflow state is saved to disk (architecture docs, changed-file lists, backlog files), not held in memory
• Reconciliation over blind acceptance — GPT findings are deduplicated, independently verified, and can be rejected with justification
• Bounded iteration — review cycles have a fixed count (usually two). Unresolved issues are escalated, not looped
• Completion discipline — every workflow ends with a concrete summary of what was produced, what was reviewed, and what remains open