How I built a product-development AI agent team

I stopped thinking about AI as one assistant when I realized I was asking it to behave like a whole product team.

One prompt would need research judgment. The next would need product strategy. The next would need design critique, delivery risk, or engineering discipline. When one assistant wears every hat, it eventually gives you blended answers: good enough to sound helpful, not sharp enough to trust.

So I built a team of five AI agents that share one Obsidian vault as a single brain. The vault holds the memory. The agents bring the lenses. I stay accountable for the decisions.

The five agents

Maren is the user researcher. Her lens is "What is true about mental health providers?" She processes interview notes, distinguishes stated needs from latent needs, and labels every theme by signal strength: strong when it appears across three or more sources, moderate at two sources, weak at one source.

Reid is the product strategist. His lens is "What should we build and why?" He tracks hypotheses as untested, testing, validated, or invalidated. He does not prioritize by stakeholder loudness. He weighs research signal strength against technical feasibility and risk reduction value.

Ava is the senior principal product designer. Her lens is "How should this work and feel?" She owns product-design artifacts, forms design positions, reads across strategy and research and translates decisions for engineering and design audiences, with leadership owning the strategic call.

Kai is the project manager. His lens is "Is this going to ship on time, and what is in the way?" He tracks standups, action items, dependencies, meeting transcripts, delivery risk, plus the Linear mirror files that let other agents see execution state without all operating the integration directly.

Syd is the full-stack engineer. His lens is "Does the code match the spec?" Syd does not redesign. He builds from specs, follows existing patterns, and flags ambiguity, treating the prototype as precedent unless the spec says otherwise.

The vault is the brain

The Obsidian vault is not a storage folder. It is the product brain. The agents read from it, write to it, and use it to maintain continuity across sessions. State lives in markdown files, not in a chat window.

That distinction changed the system. When I close the laptop and come back the next day, the agents can pick up from the vault: state files, decision records, signal registries, inbox messages, action items, PRDs, meeting transcripts, design decisions, plus history files. The memory is local-first and inspectable, versioned through git.

Do not rely on conversation history for product memory. Write the work down where the team can inspect it.

Orchestration, not magic

The agents work through slash commands, cross-pollination, signal maturity gates, disagreement protocol, state files, plus auto-triggers.

Slash commands route work to the right lens. A research synthesis command activates Maren. Scope checks activate Reid. A dashboard can spawn all five agents in parallel, then synthesize their views into one operating picture.

Cross-pollination keeps agents from becoming isolated specialists. A new research signal from Maren notifies Reid and Ava. Scope changes notify Reid and Kai. If design impact appears, Ava gets it. The inbox system is not fancy, but it is essential.

Signal maturity gates prevent building on vibes. A design decision needs at least one moderate or strong research signal before it can be accepted. Sprint scope needs key assumptions to be testing or validated. Engineering handoff waits until design decisions pass the gate.

The disagreement protocol is one of my favorite parts. When Reid says to cut scope and Ava says the surface is strategically important, the system does not silently average them. It surfaces both positions, logs the conflict, and asks me to make the call. Disagreement is not a failure. It is the part of the system where judgment becomes visible.

The operating layer

The interactive agents run mostly through Claude Code as personas with specific commands and state files, plus owned territory.

It began with notes in Obsidian and a single useful persona. I added specialized roles and shared state, plus review gates, only after the workflow proved useful.

Lessons I would keep

The system makes me faster, but speed is not the main value. The value is more deliberate thinking under pressure. Research does not get flattened into strategy. Strategy does not bulldoze evidence. Design decisions have to cite signals. Engineering gets clearer specs. Delivery risk has an owner.

That is what I mean by cloning yourself with AI. Not creating a synthetic Jay who says yes to everything. Creating a set of disciplined lenses that help me think bigger without losing the standards I care about.

FAQ