I Built a 6-Agent AI Team That Writes PRDs

A deep-dive into TrelloAgents — the architecture, the thinking, and what you can steal for your own workflows.

I kept running into the same wall.

Every time I wanted to move an idea from “thing I’m excited about” to “thing I can actually build or hand to someone,” I’d hit the spec-writing phase and slow to a crawl. Not because the thinking was hard — the thinking was mostly done. It was the documentation of the thinking. The translation of a fuzzy idea into a structured, coherent, technically rigorous product requirements document. That part was eating hours, sometimes days.

I knew AI could help. But “help” usually meant: open a chat, describe the idea, get a draft, spend the next 45 minutes editing. Better than nothing. Still slow. Still me-dependent.

What I wanted was a system that could take a raw idea and produce a production-ready PRD — autonomously, with built-in quality review — while I was doing something else.

So I built one. And in building it, I accidentally designed something that taught me more about multi-agent AI architecture than any tutorial I’ve read.

This is that story.

The First Question: Where Does State Live?

Before I wrote a single line of code, I had to answer a question that turned out to be more important than any technical choice: where does the system store what it knows?

Most people building agent pipelines reach for a database. A table somewhere. A JSON file. A vector store. All reasonable. But they introduce a problem: the state is invisible. You can’t look at a database row and understand, at a glance, where your idea is in the process, what’s been done to it, what the output looks like.

I wanted the system to be legible. I wanted to be able to open a single view and see the entire pipeline in motion — not read logs, not run queries.

That’s when I looked at my Trello board and had the realization that unlocked everything:

A Kanban board is already a state machine.

Each column is a state. Moving a card is a state transition. The card is the work item, carrying its history with it. Trello wasn’t designed for this, but it’s exactly right for it. The board becomes the database, the dashboard, and the control panel simultaneously.

Concept #1: use the tool that’s already legible. Don’t build infrastructure to track what a visual tool can show you for free.

Pipeline mapped to the board — seven columns:

Intake → Decompose → Spec Write → Spec Review → Assemble → Final Review → Done

Every idea enters at Intake as a card. The card moves right as agents process it. When it reaches Done, the PRD is attached. The board tells the whole story without opening a single log.

The Second Question: Who Does the Work?

First instinct: build a Python orchestrator. A script that polls the board, detects cards, spins up API calls, manages everything. Built that version. It worked, technically. But the agents inside had no real intelligence — just API calls. Dumb executors wrapped in a smart-looking pipeline.

Threw it out. New mental model:

Claude Code is already an orchestrator. It can read files, run commands, spawn sub-agents, track state, make decisions, and loop until a condition is met. Instead of building orchestration infrastructure around dumb agents, Claude Code becomes the coordinator — and each pipeline stage goes to a fully intelligent Claude sub-agent.

Concept #2: don’t build what already exists.

The architecture:

Claude Code = the project manager. Reads the board, decides what needs to happen, delegates to agents, attaches outputs, moves cards.
Agent sub-agents = the specialists. Each gets a focused task, does it with full intelligence, returns the result.

Claude Code doesn’t do the product thinking. The agents don’t do the coordination. Each layer does exactly one thing. Layers are independent — change how an agent thinks (edit a prompt) without touching orchestration, and vice versa.

Building a Team, Not a Tool

Six agents, each with a single responsibility:

Agent	Job
Intake Analyst	Structures a raw idea into a problem statement, audience definition, value prop, and success criteria
Feature Decomposer	Breaks the idea into 3–7 independent, specifiable features
Spec Writer	Writes a detailed feature spec — user stories, acceptance criteria, technical approach, data models
Spec Reviewer	Reviews a spec for completeness, clarity, and alignment with the original idea
PRD Assembler	Takes all approved specs and builds a unified, coherent PRD
Final Reviewer	Reads the finished PRD against the original idea and either approves or requests revisions

Concept #3: division of cognitive labor. Same reason you don’t ask your engineer to review their own code — you don’t ask the Spec Writer to review its own spec. Specialization produces quality. And when quality fails, you know exactly which agent to fix.

The Shape of the Pipeline: 1 → N → 1

The pipeline has a distinct shape: one idea fans out into many parallel workstreams, then converges back into one deliverable.

One idea
    ↓
One Idea Brief
    ↓
N Feature Cards (created by Decomposer)
    ↓ ↓ ↓ ↓ ↓  (each processed in parallel)
N Feature Specs
    ↓ ↓ ↓ ↓ ↓  (each reviewed in parallel)
N Approved Specs
    ↓
One Unified PRD

This 1 → N → 1 shape is a fundamental pattern in agentic workflows. It appears any time you have a problem that can be decomposed into independently addressable subproblems.

Parallelism is where the time savings come from. Five features get written in the time it takes to write one.

Which stages can run in parallel and which can’t:

Intake — Sequential (runs once)
Decompose — Sequential (runs once)
Spec Write — Parallel (no dependencies between features)
Spec Review — Parallel (no dependencies between reviews)
Assemble — Blocks until all N features are approved
Final Review — Sequential (runs once on assembled PRD)

Concept #4: know which work is parallelizable and which isn’t. Getting this right cuts total processing time from 45+ minutes to under 15.

How the Agents Communicate: Memory Built Into the Cards

Agents can’t talk to each other directly. Each runs in its own context, finishes its job, exits. Information flows through the card itself.

A Trello card has exactly the right structure to be a complete unit of agent memory and communication:

Attachments = Working Memory. Each card carries one file attachment — the artifact produced by the most recent stage. “Replace, don’t accumulate” rule: one attachment, always current, always the thing the next agent needs to read. You never wonder which version is latest.
Comments = Agent-to-Agent Communication. When the Spec Reviewer makes a decision, it posts a comment: what it found, what it approved, what it wants revised. When the Spec Writer revises, it reads those comments for context. Comments are also the human interface — add feedback, and the Spec Writer incorporates it on the next pass.
Description + Hidden Metadata = Identity and Lineage. Every card carries a hidden block: . Trello doesn’t render HTML comments, so the card looks clean to a human. But to the code, this is how every feature card knows which idea it belongs to, how many revision cycles it’s been through, and what type it is.
List Position = Current State. Which column the card is in is the state. No status field to check.
Labels = Flags. In Progress, Approved, Needs Revision, Blocked — visible at a glance.

Concept #5: repurpose what’s already there. No external database. No message broker. It’s all on the card.

The deeper insight: agents don’t need to communicate directly. They need shared, persistent memory. Each agent reads the current state, does its work, writes the result back, and exits. Asynchronous by nature — also resilient. If anything fails, state is preserved on the card. Resume from exactly where you stopped.

The Quality Loop: How the System Gets Better at Its Own Work

When the Spec Reviewer finds a spec lacking, it posts a comment with specific feedback, labels the card “Needs Revision,” and moves it back to Spec Write. The Spec Writer reads the feedback, revises, moves it back to Spec Review. Loop runs until the Reviewer approves.

The review-bounce loop is where quality in the output actually comes from. Without it: first-draft quality. With it: reviewed, iterated, refined output.

Guardrail: the iteration counter in the card’s metadata increments on every bounce. Hit the limit, and the card gets flagged Blocked instead of bouncing again. A human decides what to do next.

Concept #6: every autonomous loop needs a termination condition. Not as an afterthought — as a first-class design requirement.

The combination produces a natural quality floor: a spec can’t reach Assemble without surviving Spec Review. The PRD can’t reach Done without surviving Final Review. Quality is structural, not aspirational.

The Configuration Is the Prompt

Every agent’s behavior is defined entirely by a markdown file. Not code. Not configuration. A plain text file. The Spec Writer’s output format, the Reviewer’s criteria, the Assembler’s document structure — all of it lives in agents/spec_writer.md, agents/spec_reviewer.md, etc.

Two reasons this matters:

Accessible. Anyone who can write clearly can change how an agent behaves. No need to understand the Python, the API calls, or the orchestration logic.
Separates concerns cleanly. The what (what the agent should think and produce) is in the prompt. The how (how work flows, how state is managed) is in the orchestration. These evolve independently.

Concept #7: prompt-as-configuration. When behavior is pure text, it’s universally editable.

This Isn’t a PRD Machine. It’s a Pattern.

The system is a general-purpose pattern for any workflow that involves taking a raw input, decomposing it into parallel workstreams, iterating each to quality, and assembling the results into a final deliverable.

Worked Example: Adapting to a Content Marketing Pipeline

Agent File	Original Purpose	Content Marketing Version
intake_analyst.md	Extracts product problem, audience, value prop	Extracts content goals, target audience, tone, platform mix
feature_decomposer.md	Decomposes idea into 3–7 features	Decomposes topic into 3–6 content pieces
spec_writer.md	Writes detailed feature spec	Drafts each content piece in full
spec_reviewer.md	Reviews for completeness, feasibility	Reviews for voice consistency, CTA clarity, audience fit
prd_assembler.md	Assembles specs into unified PRD	Assembles content calendar + full package
final_reviewer.md	Final proofread and polish	Brand alignment and sign-off

Six markdown files. Nothing else changes.

Other applications of the same pattern: sales proposal pipeline, course curriculum development, due diligence pipeline, legal document pipeline.

Concept #8: build the engine, not the application. Once you understand the pattern, the specific content is a configuration choice.

What This Taught Me About AI Systems Design

The best choices weren’t clever. They were simple things used correctly:

A Kanban board used as a state machine instead of building a custom one
A visual tool’s native fields used as agent memory instead of building a custom one
Claude Code used as an orchestrator instead of building a custom one
Markdown files used as behavior configuration instead of building a configuration system

The principle underneath: the complexity of a system should match the complexity of the problem. The infrastructure doesn’t need to be complex. The board handles state. The cards handle memory. Claude Code handles coordination. The prompts handle intelligence.

When those layers fit together correctly, six AI agents collaborate on meaningful intellectual work, produce professional-grade output, and the whole thing is visible in real time on a Kanban board you could explain to anyone in two minutes.

Not architectural sophistication. Appropriate architecture.

How to Customize This for Your Work

Define your input and your output.
Define the decomposition — what are the parallel workstreams?
Define quality — what does good look like for each unit of work? That’s your Reviewer’s criteria.
Edit the six agent files.
Submit something and watch it run.

TrelloAgents is part of the AIMM toolkit. Built April 2026.