Status: Draft v2 Date: January 4, 2026 Author: Principal Product Manager Stakeholders: PM (xian), CXO, Chief Architect
Conversational continuity is a first-class product feature, not an infrastructure detail. The connective tissue between Piper’s capabilities—how conversations flow, how context persists, how discovery happens—is as important as the capabilities themselves.
Piper’s value proposition depends on this glue working seamlessly. A feature that exists but cannot be discovered, or that breaks conversational flow to be invoked, fails the colleague test.
The CXO UX Strategy work (Nov 2025 - Jan 2026) revealed a critical insight: Piper’s features are largely built, but users struggle to discover and use them naturally. The gap isn’t capability—it’s continuity.
This manifests as:
Traditional product thinking treats these as UX polish—nice to have after core features work. This PDR establishes the opposite: conversational glue is core functionality.
Piper can perform standup synthesis, issue triage, calendar analysis, document intelligence, and more. But if a user doesn’t know to ask, these capabilities might as well not exist.
The blank prompt pattern (“What can I help you with?”) places full articulation burden on users. Research shows ~50% of users struggle to articulate what they need from AI systems (Nielsen, 2024). These users will never discover Piper’s value—not because Piper can’t help, but because they can’t ask.
A colleague remembers what you discussed yesterday. A colleague notices patterns in your work. A colleague offers relevant help without being asked.
If Piper forgets context between sessions, treats each conversation as isolated, and only helps when explicitly requested—Piper isn’t a colleague. Piper is a tool with a chat interface.
Unsolicited suggestions can be helpful or annoying depending on:
Piper must earn the right to be proactive. This requires a trust model that governs when and how suggestions surface.
1. Discovery Glue: How users learn what Piper can do 2. Context Glue: How information persists and connects across interactions 3. Proactivity Glue: How Piper offers help without being asked
Each component requires explicit product design, not just technical implementation.
Piper articulates the situation first, then offers relevant actions. This inverts the typical AI pattern where users must know what to ask.
Instead of: Blank prompt waiting for user input
Do this: Piper observes context and offers:
“You have 3 GitHub issues that changed overnight and a standup in 2 hours. Want me to summarize the issues, or help you prep for standup?”
After successful task completion, Piper may surface one related capability the user hasn’t used.
Throttling rules (prevent annoyance):
Example:
User completes issue triage Piper: “Nice work. By the way, I can also generate release notes from closed issues if that’s ever useful.”
When users explicitly ask what Piper can do, the response must be:
Anti-pattern: Generic feature list that reads like marketing copy
When Piper can’t help with a request, the response includes alternative paths:
Instead of: “I can’t do that.”
Do this: “I can’t access your email directly, but I could help you draft a response if you paste the thread, or summarize your calendar to help you find time to respond.”
Within a session, Piper maintains full context:
This is table stakes—most chat interfaces do this.
Between sessions, Piper maintains relevant context:
Cross-session greeting follows context-aware pattern (per PDR-001):
| Condition | Greeting Approach |
|---|---|
| Same day, recent session | Reference specific work: “Back already! We were working on [X]—continue?” |
| Next day, active project | Light reference: “Yesterday we discussed [X]. Continue, or different focus?” |
| Week+ gap | Offer choice: “It’s been a bit! Want to pick up where we left off, or start fresh?” |
| Month+ gap | Gentle reorientation: “Welcome back! Want me to catch you up, or start fresh?” |
| Previous session trivial | No reference: “What can I help with?” |
Key principle: Always offer the pivot. Never trap users in previous context.
When users reference entities (projects, issues, people, documents), Piper resolves references across the conversation:
This requires anaphoric reference resolution—understanding what “it,” “that,” and “the thing” refer to.
Piper’s proactivity is governed by earned trust, not user preference. Users cannot simply enable “maximum proactivity”—trust must be demonstrated through competent behavior over time.
| Trust Stage | Piper Behavior | How Earned |
|---|---|---|
| Stage 1 (New) | Responds to queries; no unsolicited help | Default for new users |
| Stage 2 (Building) | Offers related capabilities after task completion | ~10 successful interactions |
| Stage 3 (Established) | Proactive suggestions based on observed context | ~50 interactions + pattern recognition |
| Stage 4 (Trusted) | Anticipates needs; “I’ll do X unless you stop me” | Extended history + explicit user comfort |
Trust can decrease: If Piper makes poor suggestions, misunderstands context repeatedly, or causes user to lose trust, proactivity level regresses.
Added v2 from CXO feedback—this needs architectural implementation (flag for ADR).
Interaction Outcomes:
| Outcome | Trust Effect | Signal |
|---|---|---|
| Successful | +1 toward next stage | User acted on response (clicked, executed, continued meaningfully) |
| Neutral | No change | User acknowledged but didn’t act, or conversation ended naturally |
| Negative | -1 (with floor) | User explicitly rejected, expressed frustration, abandoned mid-task |
Stage Thresholds (calibration needed—starting point):
Regression Rules:
Visibility Decision: Trust level is invisible—no “Your trust level: Established” display. But effects should be noticeable enough that users feel progression. If user asks “Why did you just do that without asking?”, Piper can explain: “Based on our history, I thought this was something you’d want me to handle. Should I check first next time?”
This makes trust discussable without being displayed. Colleagues don’t announce trust scores, but they do explain their assumptions when questioned.
Architectural implication: Trust needs to be computed, stored, and queryable—but not surfaced in UI. Flag for Chief Architect ADR.
At Trust Stage 3+, Piper may initiate based on:
| Trigger | Example Proactive Behavior |
|---|---|
| Calendar event approaching | “Your standup is in 30 minutes. Want me to prep your notes?” |
| GitHub activity spike | “12 new comments on issues you own overnight. Summary?” |
| Document staleness | “Your roadmap doc hasn’t been updated in 2 weeks. Review time?” |
| Pattern recognition | “You usually check PRs on Monday mornings. 3 await your review.” |
Never proactive about:
Always ask before:
| Metric | Target | Rationale |
|---|---|---|
| Unprompted capability discovery (30-day) | ≥3 features per user | Users finding capabilities without explicit instruction |
| “What can you help with?” satisfaction | >4/5 rating | Response quality when explicitly asked |
| Dead-end recovery success | >60% continue conversation | Users don’t abandon after hitting limits |
| Feature tour skip rate | N/A | No feature tour exists; discovery is conversational |
| Metric | Target | Rationale |
|---|---|---|
| Cross-session reference accuracy | >90% | When user references “what we discussed,” Piper resolves correctly |
| Anaphoric resolution success | >85% | “It,” “that,” “the thing” resolved correctly |
| Context-aware greeting relevance | >80% user acceptance | Users don’t immediately redirect after greeting |
| Metric | Target | Rationale |
|---|---|---|
| Proactive suggestion acceptance | >30% at Stage 2, >50% at Stage 3 | Suggestions are relevant enough to act on |
| Proactive suggestion annoyance | <10% “don’t show again” | Not annoying users |
| Trust progression | 50% reach Stage 2 within 30 days | Users earning trust through natural use |
From the CXO UX synthesis: “B2” represents the threshold where conversational glue works well enough that users experience Piper as a colleague, not a chatbot.
B2 is not a feature checklist. B2 is a qualitative assessment:
B2 is a release criterion: Features that work technically but fail the B2 conversational test are not ready for users.
Rejected because: Foreign to colleague metaphor. Colleagues don’t give you achievement badges for discovering they can help with spreadsheets.
Rejected because: Users don’t know what proactivity level is appropriate until they experience it. Trust-based progression is more natural than preference toggles.
Rejected because: Destroys the colleague relationship. Valuable for privacy-conscious users as an option, but not the default.
Rejected because: Creepy. Users should feel Piper remembers what’s relevant, not that Piper is surveillance. Selective memory is more human.
For CXO:
For Chief Architect:
For Implementation:
PDR-001 (First Contact is First Recognition): FTUX is the first expression of conversational glue. The principles established there (Piper speaks first, multiple entry points, onboarding as primer) are specific applications of the glue patterns defined here.
PDR-003 (Multi-Entity Chat) [Pending]: Multi-entity conversations will require extended glue—how context persists when multiple participants are involved, how proactivity works in group settings.
Memory boundaries: How much cross-session context is helpful vs. creepy? What’s the retention policy? CXO “thoughtful colleague” test: remember work context and stated preferences; don’t remember casual asides or inferred personal details.
Trust computation specifics: Resolved v2 — Framework established above (interaction outcomes, stage thresholds, regression rules). Needs architectural ADR for implementation.
Privacy mode: Should there be an explicit “don’t remember this session” option? How does it interact with trust levels?
Multi-device continuity: If a user switches from desktop to mobile mid-task, how does context transfer?
v2 (January 4, 2026):
v1 (January 4, 2026):
| *PDR-002 | Draft v2 | January 4, 2026* |