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, technical feasibility, and risk reduction value.

Hermes is the senior principal product designer. His lens is "How should this work and feel?" Hermes is different because he runs persistently through Hermes Agent on an always-on Oracle cloud server. He owns product-design artifacts, forms design positions, reads across strategy and research, and translates decisions for engineering, leadership, and design audiences.

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, and 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, flags ambiguity, and treats 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, and history files. The memory is local-first, inspectable, and 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, and auto-triggers.

Slash commands route work to the right lens. A research synthesis command activates Maren. A scope check activates Reid. A dashboard can spawn Kai, Reid, Hermes, and Maren in parallel, then synthesize their views into one operating picture.

Cross-pollination keeps agents from becoming isolated specialists. When Maren finds a new research signal, Reid and Hermes get notified. When scope changes, Reid and Kai get notified. When design impact appears, Hermes 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 Hermes 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 infrastructure

The interactive agents run mostly through Claude Code: Maren, Reid, Kai, and Syd are personas with specific commands, state files, and owned territories. Hermes runs separately as an always-on agent using OpenRouter for model access and a layered knowledge system: SOUL.md for identity, MEMORY.md for persistent facts, USER.md for preferences, AGENTS.md for project conventions, and skills organized by depth.

The Oracle server runs scheduled automation: vault auto-sync every five minutes, sync health monitoring, review watching, a morning briefing, Maren's competitive digest, and night shift maintenance. A Slack bot connects the system to team channels. Three devices share the vault through git: MacBook, Mac mini, and Oracle server.

That sounds like a lot because it is. It did not start that way. The system began with notes in Obsidian and a single useful persona. The infrastructure came later, when Hermes needed to work persistently and the vault needed health checks.

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