Add "How many agents does the user see?" to agentic product design

CHANGELOG.md

@@ -11,6 +11,12 @@ Notable additions to this repo, newest first. Loosely follows the [Keep a Change
 - **`.claude/skills/pm-design-critic/SKILL.md`** — new step 3b, an agentic checklist (attribution, transparency calibration, failure visibility, produce-vs-publish, permissions, stakes routing, constraint spec, approval placement, valued friction) that runs when the design has AI taking actions rather than making suggestions.
 - **`.claude/skills/pm-framework-selector/SKILL.md`** — routing row for agentic product design questions.
 
+## 2026-08-13 (later)
+
+### Added
+
+- **`decision-making/agentic-product-design.md`** — new "How many agents does the user see?" section on whether internal multi-agent topology should surface to the user. Internal decomposition is an engineering and governance decision; the user should still get one conversation and one resolution. Reconciles this with the attribution rule (attribute by system, not by internal boundary) and with named persistent agents. Checklist gains a topology-leakage item (now 14).
+
 ## 2026-06-02
 
 ### Added

decision-making/agentic-product-design.md

@@ -59,6 +59,25 @@ Identity also does organizing work once there's more than one agent. Sheta Chatt
 
 ---
 
+## How many agents does the user see?
+
+Teams building multi-agent systems face a question with no default answer: does the internal topology surface to the user?
+
+Take a customer message like *"my order arrived damaged, I was charged twice, and I want this resolved."* To the customer that's one problem. Internally it may take several capabilities — retrieving the order and transaction history, investigating the duplicate charge, applying return policy, choosing a resolution, executing it, verifying the outcome. Those may be one agent or six.
+
+**The customer should still see one conversation and one resolution.** Internal decomposition is an engineering and governance decision — separate permissions, separate evals, separate release cadences — and it is not a mental model the user asked for. A product that exposes its org chart as a hand-off queue ("transferring you to the Billing Agent") has converted an architecture into a user problem, which is the same mistake as exposing the model.
+
+Two exceptions where agent identity genuinely helps the user, both from the sections above:
+
+- **Persistent agents the user delegates to repeatedly** benefit from a name and a legible remit — that's the messaging-a-coworker model, and it works because the user builds a track record with a stable counterpart.
+- **Attribution is by system, not by internal boundary.** The user needs to know *the agent* did this rather than a human, and needs to reverse it. They do not need to know which of your six agents did it. Your trace needs that resolution; the surface doesn't.
+
+The reconciliation, then: decompose internally for whatever reasons make the system easier to govern and evaluate, and let the seam be invisible unless a named agent is something the user actually forms a relationship with.
+
+**Evaluation question:** does the user experience one coherent resolution, or does your internal decomposition leak as hand-offs, repeated context, and shifts in voice?
+
+---
+
 ## The invisibility rule inverts: attribute every action
 
 [`ai-integration.md`](ai-integration.md) Rule 4 says lead with the outcome, not the model. That holds while the AI is producing a suggestion the user chooses to accept. It stops holding the moment the agent changes shared state, because the user is now accountable for work they didn't personally do.
@@ -206,7 +225,8 @@ Run this alongside the [AI integration checklist](ai-integration.md#the-ai-integ
 10. **Familiar patterns:** is the novelty in the capability rather than the interface?
 11. **Approval placement:** do approvals sit next to the object the agent is shaping, rather than in a separate queue or chat panel?
 12. **Valued friction:** is any step being automated away that the user actually enjoys doing? Time-saved metrics can't detect this.
-13. **Learning loop:** is the instrumentation for where the agent gets stuck and where users drop off built before launch, and is post-launch refinement budgeted?
+13. **Topology leakage:** if the system is multi-agent, does the user still get one conversation and one resolution — or do internal hand-offs surface as repeated context and shifts in voice?
+14. **Learning loop:** is the instrumentation for where the agent gets stuck and where users drop off built before launch, and is post-launch refinement budgeted?
 
 If items 3, 5, or 7 are weak, the product isn't ready for autonomy regardless of how good the model is. Ship the gated version and widen it on evidence.