AI Product Team

I’ve published AI Product Team, a collection of 64 specialist agents, 28 shared methods and 12 workflows, packaged for Claude Code and Codex. It grew out of reasoning skills and runbooks I drafted earlier this year for discovery, research, design, implementation and review.

A product decision can change meaning as it moves from research into a specification and then into code. An unresolved assumption becomes a requirement, a qualification disappears from a summary, or a passing check is carried forward after the implementation it covered has changed. Each document may look reasonable on its own, while the sequence no longer supports the conclusion being drawn from it.

I wanted to make those handoffs easier to inspect. Each workflow asks the agents to keep a ledger in the project, connecting sources, claims, requirements, decisions and checks to the versions they concern. The next specialist should be able to see what a conclusion rests on, what remains unresolved, and whether the evidence still applies to the work in front of it.

How the team is meant to work

You begin with a request such as “turn these documents into a feature proposal,” “find out why this feature fails,” or “is this ready for a pilot?” The workflows cover work from evaluating an opportunity through design, prototyping, testing, release review and subsequent changes. Each selects the relevant specialists and specifies what they need to produce before work proceeds.

The organization includes researchers, designers, engineers, evaluators and reviewers, alongside roles for challenging assumptions and resolving disagreements. Most requests should use very little of it. A summary calls for a much smaller group than a release review, and a stage can be omitted when a current, accepted artifact already supplies what it needs. The workflow’s review gates remain required. Only the user’s main session dispatches agents; managers and directors return plans and reviews instead of spawning further teams.

Eleven of the shared methods adapt my earlier drafts; the other seventeen are new. Keeping the methods separate lets several roles use the same procedure without maintaining slightly different copies. Each role also names a particular failure it must avoid. The Claim Checker, for example, must reject a citation that exists but supports a different proposition. A role called Decision Authority must refer a production-deployment request back to the human instead of treating its title as permission.

There is also a limit to how much discussion a workflow should generate. Challengers have to identify the premise they dispute, explain why it matters, and name the evidence that could settle it. Debate is capped at two rounds, and a judge can return “unresolved.” Counting how many agents agree would tell us little about whether they had all inherited the same mistaken assumption.

A small example with consequential differences

The repository includes a fictional support team introducing an AI reply-drafting feature. An older presentation proposes automatic sending; the current policy permits drafts only. The expected workflow keeps the conflict visible, respects the current restriction, and leaves the broader sending decision with the human owner. It should neither introduce automatic sending into the requirements nor invent a decision that the earlier ambition has been abandoned.

That distinction has consequences throughout the work. The proposed experience needs a human sending action, the requirements must preserve that boundary, and the acceptance checks need to test that the feature cannot send a message by itself. Recording the disagreement in a research summary would accomplish little if it disappeared from the implementation brief.

A second part introduces new evidence about workspace isolation. An earlier test passed, but a later test on a changed build exposes access across workspace boundaries. The required response is to review the affected implementation and release decision while preserving the isolation requirement. The original test remains a historical pass with a limited scope; it does not become proof that the current build is safe. These are specified expectations for the demo, not results from a completed agent run.

What this first release establishes

Version 0.1.0 contains the role definitions, shared methods, workflows, installer and a searchable agent directory. Structure and format checks have passed, and the installer and supporting code have automated tests. Live loading in both hosts, end-to-end workflow execution and comparisons against a single assistant remain unvalidated. The coordination rules are instructions, with tool restrictions where the host supports them; the experimental controller that would enforce more of those rules is unfinished and disconnected from the agents.

Every additional role introduces cost and another handoff where something can go wrong. The comparison worth making is whether a workflow catches a consequential mistake, preserves a constraint, or helps reach a better-supported decision than the same assistant working without it. Some specialists may earn their place; others may prove unnecessary.

The repository includes installation steps and the support-copilot example. It can be forked, reduced to a few roles, or adapted to another workflow. A run report showing where a handoff succeeded or failed would be especially useful. That is the level at which this team needs to earn its complexity.