Case study
One chat was answering as the whole team
I built Many Hats so one person can work with named specialists who leave citable artifacts. The person using it stays the product owner.
- Role
- Author
- Form
- Thirteen agents and fifteen portable skills, public v0.1
- Runs in
- Cursor, Claude Code, Codex, GitHub Copilot, and Windsurf
- Outcome
- A cloneable team and a fictional Library Holds demo. No adoption count.
Fifty-three methods still had no owner
Design Dash already held 53 stage-oriented methods, from object discovery through ethics review. They worked inside a facilitated workshop. They were a poor fit for ongoing product work, where the same person needs to ask a product lead to frame the problem and a critic who did not write the plan.
A general agent can draft all of those jobs in one thread. Strategy, domain rules, interface language, and implementation advice arrive as one voice. Nothing in that thread has to stay inside a role, cite a project fact, or stop before it sounds like a decision.
I reviewed public agent collections for boundaries and verification patterns, including GitHub’s awesome-copilot, OpenAI’s skills, and Anthropic’s skill packaging. I wrote original contracts. I did not copy their agents.
I separated roles, skills, and project facts
The architecture keeps four things apart. People are stable roles. Practice is a portable skill with a testable contract. Knowledge is shared facts, including the object library. Work is the artifact a role produces on one project.
That split decides where a correction goes. A fix that belongs to one product stays in that project. A reusable change needs a motivating case, an evaluation, and a pull request I approve. I mapped all 53 Design Dash methods onto accountable agents and folded them into fifteen skills. Luke holds the domain methods. Liza holds direction and facilitation. The original methods stay as references, so the fold did not delete the practice.
The object library sits in shared knowledge, not inside one agent’s folder. Luke stewards it. The other roles cite the same objects. A project can reference an object, fork it, or propose a promotion. It does not edit the shared object to satisfy an unreviewed assumption.
The critic can reject the bigger product
Library Holds is the public demo, and it is fictional. Patrons and desk staff need a holds-and-pickup loop they can trust. The tempting version is a platform: branch transfers, waitlist games, and a notification preference center.
Liza’s direction chooses a smaller Hold MVP: place, cancel, ready, fulfill, and expire, with one notice channel. Luke defines Hold, Patron, Item, and Pickup Window. Charlie maps waiting, ready, expired, cancelled, and an empty queue. Echo separates Hold from Reservation and Checkout. Allie challenges the platform version. A text-message preference is an assumption. Waitlist points do not answer when a book must be picked up. Multi-branch transfer is a different product. Liza’s accepted decision cites that challenge and leaves those ideas out of the first version.
Allie does not inherit the plan she is challenging. Across the system, agents may recommend and prepare. They may not claim a stakeholder said yes, merge, deploy, or send anything unless I authorized that exact action.
Outcome
v0.1 is a cloneable team, and the decision stays mine
A builder can clone the repository, install the skills, and replay a pass from scope through objects, flow, language, and an independent challenge. The skills stay the same across hosts. Adapters only change how a tool finds them.
I do not have an adoption count for v0.1, and Library Holds is not a field study. What the repository shows is a way to do product work with AI without collapsing the team into one obliging voice. My takeaway: a useful specialist produces a citable artifact, stays inside a role, and leaves the decision with the person accountable for it.