PDR-101: Multi-Entity Conversation Support

Status: Draft v2 Date: January 4, 2026 Author: Principal Product Manager Input: Ted Nadeau, “NewApp – Multi-Party, Multi-Agent Conversational Modeling Platform” PRD v0.3 Stakeholders: PM (xian), Chief Architect, Ted Nadeau (Advisor/Contributor)

Decision

Piper Morgan will support multi-entity conversations as a core capability, operating in two modalities:

  1. Host Mode: Piper hosts multi-entity conversations within its environment, coordinating between human users and AI agents
  2. Participant Mode: Piper participates as an agent in externally-hosted multi-agent contexts

This is not a new invention—it’s a productization of patterns already present in our development methodology. The asynchronous, human-orchestrated multi-agent coordination we use daily (GitHub issues, session logs, handoffs between specialized agents) is the prototype for this capability.

Context

The Methodology as Prototype

Our current development process involves:

This is multi-entity conversation—just asynchronous and human-mediated. The product question is: how do we formalize this into a capability Piper can offer users?

Ted’s Contribution

Ted Nadeau’s “NewApp” PRD (v0.3) provides a comprehensive vision for multi-party, multi-agent conversational platforms. Key concepts:

Ted’s PRD is a substantial architectural contribution that will inform both this PDR and subsequent ADRs. The relationship is:

User Need

For Individual PM Users (Current Focus)

PMs already work in multi-entity contexts:

Piper currently supports 1:1 conversation. But PM work is inherently multi-party. Users need:

For Team/Org Users (Future)

As Piper expands beyond individual users:

Two Modalities

Host Mode: Piper as Conversation Platform

Piper hosts conversations where:

Example: A product planning session where PM, designer, and engineer discuss a feature. Piper captures the conversation as structured data, tracks decisions vs. open questions, and maintains context for follow-up.

Key capabilities:

Participant Mode: Piper as Agent in External Contexts

Piper joins conversations hosted elsewhere:

Example: A Slack channel where team discusses a bug. Piper is @mentioned, reads context, contributes analysis, and offers to create a GitHub issue.

Key capabilities:

Relationship to Existing PDRs

PDR-001 (FTUX as First Recognition)

Multi-entity support extends the recognition interface pattern. When multiple entities are present, Piper must:

PDR-002 (Conversational Glue)

Multi-entity conversations require enhanced glue:

The B2 quality gate applies here too—multi-entity conversations should feel natural, not like a conference call with a bot.

Design Principles

Strategic Stance: Participant-First

Added v2 from CXO feedback.

Piper should be an excellent participant before becoming a capable host.

Rationale:

The colleague metaphor supports this: colleagues join your meetings, contribute to your threads, show up where you’re working. They don’t ask you to come to their office for every interaction.

The invitation pattern: Rather than building Host Mode and expecting users to come to it, Piper-as-participant recognizes when a conversation has outgrown its platform and offers:

“This discussion is getting complex. Want me to capture it in a structured format you can navigate?”

This keeps participant-first as default while creating natural paths to host mode when conversations need structure that external platforms can’t provide—decision tracking, version-controlled artifacts, multi-view navigation.

Numbered Principles

1. Conversation is a model, not a log

Per Ted’s insight: the underlying structure is a graph of typed elements with relationships, not a linear transcript. This enables:

2. Each participant has context

What each person sees, what they’ve contributed, what they care about—this is per-participant state. The facilitator (Piper) sees everything; personal views are filtered.

3. Facilitation is a capability, not a requirement

Piper can facilitate (summarize, highlight, suggest) but participants can also just converse. Facilitation is offered, not imposed.

In multi-party contexts, Piper should not take unilateral action. Creating issues, updating docs, sending messages—these need explicit authorization, especially when multiple humans are involved.

5. Graceful degradation to current model

If a conversation starts as multi-entity but only one person remains, it should gracefully become a normal 1:1 Piper conversation. No special “exit multi-entity mode” required.

Implementation Path

Phase 0: Methodology Continues (Now)

The current development methodology IS the prototype. Document patterns, refine handoffs, extract reusable components.

Phase 1: Participant Mode MVP

Piper as effective participant in Slack conversations:

This extends existing Slack integration; doesn’t require new UI.

Phase 2: Host Mode Foundation

Basic multi-participant support in Piper’s native interface:

Phase 3: Personal Agents

Per-participant AI assistance:

Future: Federation

Piper instances communicating with each other and external AI systems. This is where Ted’s full vision lives—but it’s beyond current scope.

Open Questions

  1. Governance model: When multiple humans are present, who can authorize Piper actions? Consensus? Any participant? Designated owner?

  2. Privacy boundaries: What does one participant see about another’s interactions with Piper? Full transparency? Selective?

  3. Conflict handling: When participants disagree, how does Piper facilitate? Neutral presentation? Active mediation?

  4. Versioning UI: Ted’s model supports version control for evolving content. How do we expose “diffs” without overwhelming users?

  5. External platform constraints: Slack, Teams, etc. have their own limitations. How much of the model can we preserve when participating in constrained environments?

  6. Scope boundary: Where does Piper’s multi-entity capability end and a full “NewApp” product begin? Are these the same thing eventually, or complementary?

Ted’s Contribution Path

Ted is empowered to develop this capability with the following workflow:

  1. Ted’s internal coherency: Develops rich documentation with AI assistance (ChatGPT), maintaining his own structure
  2. Translation to our vernacular: PPM/PM help map Ted’s artifacts to PDR/ADR/UX formats
  3. Architectural review: Chief Architect ensures alignment with Piper patterns
  4. Implementation: Ted proceeds to vibe-coding/AI-assisted development
  5. PR submission: Code submitted for review
  6. Compliance check: Pattern and architecture compliance verified
  7. Integration: Accepted PRs merged into Piper

This is exactly the contributor model our methodology envisions—Ted is the first external test case.

Success Criteria

Phase 1 (Participant Mode)

| Metric | Target | |——–|——–| | Slack thread context retention | >80% accuracy on “what was discussed” | | Appropriate response rate | >70% of @mentions get useful response | | Action completion | >90% of authorized actions succeed | | User satisfaction | >4/5 on “Piper was helpful in team context” |

Phase 2 (Host Mode)

| Metric | Target | |——–|——–| | Multi-view usage | >50% of sessions use at least 2 views | | Facilitation acceptance | >40% of suggestions acted upon | | Context persistence | >90% accuracy on cross-session references | | Participant satisfaction | >4/5 per participant |

References

Changelog

v2 (January 4, 2026):

v1 (January 4, 2026):

*PDR-101 Draft v2 January 4, 2026*