# AWP Planner-Led Conversation UX **Date:** 2026-08-19 **Status:** Working product-design baseline; approved direction. **Purpose:** Ensure Planning is agent-led, stateful, mode-aware, and self-navigating so the user does not have to remember what to ask next. ## 1. Core interaction contract The planner owns the planning agenda. The user provides intent, corrections, preferences, decisions, and interruptions. The planner is responsible for knowing: ```text what the user asked for what is being worked on now what has been decided what remains unresolved what is blocked what can be inferred without asking which decisions require the user which expert decisions can be delegated what should happen next ``` The planner must not force the user to drive the process by repeatedly asking unrelated follow-up questions or waiting for the user to remember missing planning areas. ## 2. Three persistent questions The Planning UX should answer these at all times: ```text WHAT DID I ASK FOR? visible in the Plan Index / structured plan WHAT ARE YOU DOING NOW? visible in the active conversation/decision area WHAT IS LEFT / WHAT IS NEXT? planner states the next decision/action and remaining blockers itself ``` This is the Planning-specific form of the broader AWP product mental model. ## 3. Planning participation modes Planner leadership operates in two participation modes: ```text Simple planner still performs the full planning job user is asked primarily for OwnerRequired decisions DelegableExpert decisions are resolved by AWP and made visible in structured state technical decisions do not become chat choices by default Expert planner still leads and recommends first DelegableExpert decisions may become active interview items user can deeply review/refute architecture, quality, CI/CD, deployment, execution, etc. ``` Mode does not change authorization/safety gates. Decision participation classes: ```text OwnerRequired user intent/preference/business/product/risk choices that AWP cannot legitimately invent DelegableExpert technical choices AWP can resolve from evidence, Project defaults and expert recommendation PolicyRequired explicit consent/authorization required by security, credentials, budget, production or other policy ``` A technical uncertainty in Simple mode becomes a user question only if its consequence crosses into `OwnerRequired` or `PolicyRequired` territory. ## 4. Planner turn contract For every substantive planning turn, the planner should: ```text 1. Resolve/respond to the user's current input. 2. Update structured Planning state and artifacts. 3. Surface any new Finding/Risk/OpenQuestion caused by that input. 4. Decide whether the current planning area is sufficiently resolved. 5. Select the highest-value next unresolved planning item. 6. Apply the participation mode to determine whether to ask, decide, research, defer, or request policy action. 7. Lead into the next user-relevant item while expert planning continues visibly in structured state. ``` Do not end a planning turn with passive prompts such as: ```text What would you like to discuss next? Anything else? Where should we go from here? ``` when the PlanningWorkflow already knows the next unresolved item. ## 5. Simple-mode conversation contract Simple mode is not shallow planning. It is **low-interruption planning**. ### OwnerRequired item ```text planner explains consequence -> recommends when useful -> asks one consequential question -> records the Decision ``` Examples: ```text product scope pricing brand/taste business policy customer promise budget/risk acceptance ``` ### DelegableExpert item ```text planner inspects evidence/defaults -> resolves recommendation -> records confidence/basis/consequence -> updates Technical plan in the UI -> continues without asking the user ``` The center may show a compact non-blocking activity note such as: ```text Technical plan updated 3 expert decisions resolved from Project defaults. No action required. [Review] ``` This is informational, not an acceptance prompt. ### PolicyRequired item Surface the required user action at the lifecycle point where it is actually needed. Examples: ```text Connect Cloudflare account approve production deployment accept a budget/policy exception confirm an irreversible external commitment ``` ## 6. Expert-mode conversation contract The planner uses the same structured state but can actively interview the user about technical details. Recommendation comes before interrogation: ```text recommendation confidence + basis material consequences 2-4 credible alternatives when useful what would change the recommendation ``` The user may accept, refute, customize, or ask for deeper evidence. Rejected technical recommendations reopen only the affected Decision and its dependents. Expert mode should never degenerate into a blank questionnaire. ## 7. Recommendation before interrogation When enough evidence exists, infer and recommend: ```text Planning Profile architecture direction research/validation need quality/testing strategy CI plan release/deployment strategy ExecutionPolicy provider/account requirements ``` In Simple mode these normally become visible expert state. In Expert mode they may become interactive decision briefs. ## 8. Agenda selection The planner chooses the next item using structured planning state, not conversational recency alone. Priority order should consider: ```text blocking dependencies OwnerRequired decisions that unlock downstream work PolicyRequired actions needed soon high-impact unresolved risks missing information required by the next stage time-sensitive research/setup low-cost decisions that unlock several artifacts DelegableExpert work AWP can resolve without interruption ``` Non-blocking polish and speculative future issues should not displace a decision needed to advance the Plan. The user can override the agenda at any time by selecting a Plan Index item or directly asking about another topic. After that interruption is resolved, the planner resumes the highest-value unresolved item unless scope/agenda was explicitly changed. ## 9. Visible agenda Guided planning remains default, but the agenda is legible: ```text Now Pricing policy Next Scope boundary Later Production connection ``` The user can reorder/park a non-blocking item without switching to a manual agenda mode. The agenda should prioritize user-relevant items in Simple mode. Delegated expert work is visible in the Plan Index/Technical plan and does not crowd the conversational agenda. ## 10. Plan Index as durable memory Stable landmarks: ```text DEFINE DESIGN SPECIFY DELIVER LAUNCH ``` Concrete children are generated from Planning Profile and project facts. Simple-mode example: ```text DEFINE ✓ Intent ● Pricing needs you ✓ Scope DESIGN ✓ User journeys ▸ Technical design 7 decisions · 1 changed SPECIFY ○ Domain contracts ○ Page behavior DELIVER ▸ Quality / CI / CD 9 decisions · inherited ! Production connection required before deploy LAUNCH ○ Readiness ○ Start / Schedule / Park ``` Progressive disclosure keeps current groups expanded, completed groups summarized, and blockers/deferred items visible. ## 11. Active work area The center communicates "what are you doing now?" and keeps one primary action. Example in Simple mode: ```text Current: Pricing policy Recommended Usage-based pricing with a monthly floor. Why Matches variable infrastructure cost while preserving predictable minimum revenue. [ Accept recommendation ] Compare options Technical plan updated Architecture and CI defaults were resolved in the background. [Review] ``` Do not restate the whole Plan. The Plan Index owns persistent context. ## 12. Next-step ownership The planner explicitly carries the conversation forward. Example: ```text This resolves pricing. Next I will confirm the launch-market scope. Technical delivery planning will continue from the Project defaults unless it creates a business or policy decision for you. ``` When the next item is OwnerRequired, ask one question. When it is DelegableExpert in Simple mode, resolve it and continue. When it is PolicyRequired, surface the required action at the right gate. ## 13. Remaining-work summary Keep compact: ```text Remaining 2 decisions needing you 6 expert decisions being resolved 1 deferred connection requirement 0 blockers for specification ``` Avoid fake percentage completion. ## 14. Project defaults and first Expert Plan A user may deliberately use Expert mode on a first substantial Plan to establish reusable technical defaults. At completion, AWP proposes only default-eligible decisions: ```text Use for future Plans architecture conventions quality/testing policy CI/CD defaults provider/deployment roles approval conventions execution policy defaults ``` Plan-specific decisions are excluded. Saving/updating Project defaults requires explicit user action. One Plan exception must not silently redefine future Plans. Later Simple Plans inherit those defaults and focus conversation on owner decisions and genuine deltas. ## 15. Auto-advance and mode switching After a decision resolves: ```text record Decision update affected Artifacts recompute readiness/dependencies select next item auto-advance ``` Switching modes preserves all state: ```text Simple -> Expert technical decisions become eligible for active discussion Expert -> Simple accepted work remains unresolved DelegableExpert decisions return to AWP delegation ``` Mode switching never changes historical meaning of already accepted Decisions. ## 16. Planning completion behavior The planner does not stop because conversation momentum ends. Completion requires: ```text OwnerRequired decisions for the current gate resolved/deferred appropriately DelegableExpert decisions resolved enough by AWP or user PolicyRequired requirements satisfied or deferred to explicit future gates research/validation requirements resolved or accepted as risk quality/CI/release/deployment setup resolved ExecutionPolicy resolved remaining uncertainty bounded/visible PlanLaunch disposition selected: Start now / Schedule / Park ``` ## 17. Communication policy integration `CommunicationPolicy` controls wording. `PlanningWorkflow`, participation mode, decision participation class and readiness state control what must be covered and whether the user is asked. Aliases cannot disable required gap detection, readiness evaluation, user-owned decisions, safety gates or next-step leadership. ## 18. Acceptance criteria Planning fails this contract if users regularly have to ask: ```text What are we missing? What should we do next? Did we already decide this? Where is the plan now? Why did AWP choose this? Can I change the technical plan? Are we ready to proceed? ``` Simple mode additionally fails if users are repeatedly interrogated about technical choices that AWP could safely resolve, or if technical decisions happen invisibly. Expert mode fails if the user must construct technical choices from scratch without useful recommendations.