Conversational designer prototype iterations¶
Status: Draft | Last reviewed: 2026-09-10
Evolve the current design prototype alongside the authoring implementation. The primary author understands the business process and may know nothing about models, integrations or prompt syntax. The conversation gathers requirements; the adjacent panel visualizes the emerging agent. It should not be a second input form.
The live build now adds generation status on Design Home, collapsed per-turn Thinking activity, private image/text references, and discovery of existing agents, capabilities and published visual components. These use the real Claude Code assistant engine. The implementation record documents supported formats, prompt/tool locations and validation. The standalone scripted export remains a separate demonstration.
Source and scope¶
Work in apps/ai-manager/components/studio/, lib/studio/ and the scoped
app/(main)/studio/design-preview.css. Run the current app in
prototype mode. Keep its browser
mocks and captured fixtures intact. The older studio/real tree is a reference,
not the source of the next export.
Standalone prototype mode has scripted replies and browser-local briefs. Its draft adapter supports voice/chat configurations. Translation and Background Agents exist elsewhere in the app, but this conversational adapter does not yet create them. These distinctions must remain visible while the prototype explores a broader experience.
The regular app now has a separate live implementation of these three views, backed by the existing Claude Code engine. It creates all four types and stores conversations and design output on the server. The scripted preview remains available for offline exports.
Current iteration implemented¶
| Change | Reason | Boundary |
|---|---|---|
| Use Cases replaces Steps | Show specialist responsibilities and procedures with functional descriptions | Suggestions and discussed items are distinguished; no runtime subagent/procedure compilation |
| Description updates from conversation | Show the effect of each answer above the tabs | Scripted choices plus verbatim ordinary answers, not live model synthesis |
| Read-only Behavior overview | Combine channels, capabilities, tools, tone, boundaries and stack | Existing settings are preserved; detailed changes use the agent editor |
| Validate replaces Tests | Prepare test cases and expected outcomes as the design evolves | Local deterministic examples, always not_run; no execution claims |
| Remove Plan, Connections and References tabs | Make conversation the primary input surface | Older notes, source lists, tools and settings remain in stored briefs |
| Persist question/answer records | Restore the same visual output after reload | Optional fields retain older-brief compatibility; metadata stays out of runtime config |
This supersedes the initial Plan-form iteration. It does not complete the authoring spike. Detailed configuration remains available in the agent editor.
Target interaction¶
Start with an invitation to describe the work. Infer the likely agent type, then confirm only a material ambiguity. For example, “Should it answer people straight away, or work through requests for your team later?” Map the answer to the technical target internally.
The conversation asks the next useful question. It can offer known systems, show an example, accept “not decided”, or explain a limitation. The design updates with a small, reviewable change and its reason. Do not force users through a fixed questionnaire or require them to fill in a form beside the conversation.
Gather these business questions in conversation and reflect them in the output:
| Area | Plain-language content | Underlying artifact |
|---|---|---|
| Purpose | Who it helps, what it does, what success looks like | Typed brief, target kind and success criteria |
| Experience | Where it is used, languages, tone, when a person helps | Channel, modality, handoff and accessibility choices |
| Work | Steps to follow, conditions, exceptions and specialist tasks | Rules, procedures, subagents or workflow nodes as appropriate |
| Information and actions | What it may read/change; what needs checking first | Data boundaries, permissions, input/output and action contracts |
| Connections | Which system owns the work and what is still missing | Real bindings, unbound tool intents and test fixtures |
| Evidence | Why a choice was made, which guidance was used, what was tested | Versioned sources, artifact revisions and execution records |
Technical details remain inspectable. User-facing choices describe consequences without requiring authors to select an implementation mechanism.
Next iterations and acceptance¶
These are planned work, not controls already present in the prototype. Use explicit demonstration data for UI exploration and replace it with the listed backend contract before claiming working generation.
| Iteration | Experience to prototype | Backend dependencies | Acceptance |
|---|---|---|---|
| 2: Grounded conversation and decisions | Extend the scripted output updates with adaptive questions, corrected answers, “not decided”, and reasons for recommendations | B1–B3 in the delivery backlog | An answer updates the output, survives resume and is not asked again; manual edits are preserved |
| 3: Four agent paths | Voice, Chat, Translation and Background with appropriate steps and test examples | Type-specific generation adapters and B7 | Translation shows both directions; Background shows trigger, timezone, destination and inactive status; neither is disguised as chat |
| 4: Protections and voice choices | Explain required checks and eligible experience choices in everyday language | B11 policy/capability resolution | Ineligible choices cannot be selected; unresolved policy is visible; no “compliant” badge from a prompt |
| 5: Connections and placeholders | Discover existing systems, specify a missing action, show sample results and connection tasks | B4 and B8 | Missing connections remain explicit; sample actions cannot be published or called as real tools |
| 6: Tests and evidence | Extend prepared examples into grounded cases linked to requirements, real run status and failure explanation | B12 and real test adapters | New cases start unrun; results name real/simulated dependencies; edits invalidate affected evidence |
| 7: Multimodal and revisions | Review extracted document/image observations, branded form preview, voice fallback, changed-source handling | B5–B6 and B9–B10 | A submitted form leads to an observed action result; interrupted work resumes without overwriting edits or duplicating artifacts |
The sequence can be explored with prototype fixtures before backend completion. Backend delivery order follows evaluation and delivery. Keep fixture-backed demonstrations visibly separate from connected results.
Security needs and voice setup¶
Ask concrete questions such as “Does the agent need to check who someone is before sharing account details?” and “Are there details it must never send to an outside service?” Use known tenant policy first; do not ask a business user to restate settings the system can inspect.
Explain an eligible recommendation in terms of the experience, for example: “This setup lets us check the response before it is spoken. We still need to measure how the pause feels.” Put cascade/half-cascade/S2S, provider and guard placement under technical details, with the actual eligibility evidence.
Follow the runtime-selection contract. Checking outgoing speech does not establish that incoming sensitive audio was withheld from a provider. Do not present “empathy versus security” as a slider that can override a mandatory restriction. Compare conversational quality and latency only after required protections are satisfied.
Rules, procedures and specialist tasks¶
Let an author express “Check these details before issuing a refund” or “Ask a specialist to review exceptions.” The designer resolves whether this needs a tool permission, enforced checklist, routing rule, subagent or a prompt instruction. Show the proposed business behavior and any missing support.
When one requirement produces several artifacts, retain a link from the requirement to each artifact and its tests. Do not silently reduce a mandatory procedure to prose in the Behavior tab.
Placeholder connections¶
Show the intended action, system, information required, expected result and unanswered questions. Suggested labels are Needs a connection, Uses sample results, Connected · not tested and Tested in [environment].
Let authors sketch with a missing system while making the task needed to connect it explicit. The existing action picker remains available. A planned action needs a separate tool-intent artifact; inserting a fictitious tool ID into today's picker is not an implementation.
Multimodal work¶
Distinguish material supplied to the designer from what customers will see or hear. A file reference is not extracted evidence; an extracted observation is not a connected knowledge source. Show page/image/time references and let the author correct an interpretation.
A generated form needs its field purpose, destination, submit result, error state and voice-only fallback designed together. Voice interaction with the designer is a separate transport project after shared session state works.
Usability checks¶
Run short task-based sessions with functional users before polishing further:
- Describe an order-support agent without technical vocabulary.
- State an identity-check requirement and explain whether it is enforced yet.
- Identify where real requests will go when the desired system is missing.
- Review a voice recommendation and explain its practical consequence.
- Distinguish a sample test from a successful connected test.
- Resume the brief, change one requirement and find the affected tests.
- Complete the same review with keyboard controls and a narrow screen.
Observe whether people can explain the agent's behavior and remaining work without an engineer translating the interface. Record confusing terms, unnecessary questions and mistaken readiness assumptions. These sessions have not yet run; do not substitute automated UI checks for user evidence.
Verification of the current iteration¶
Verification on 2026-09-10:
npm run typecheckand focused ESLint checks passed.- All twelve output/brief/payload/feature-gate tests passed, including ordinary answers, revised expectations, explicit channel choices, older-brief compatibility and exclusion of design metadata from runtime config.
- An isolated Chromium walkthrough against browser MSW passed: three output tabs, updating summaries from buttons and ordinary answers, read-only Behavior, generated expectations, filters, saved answers, keyboard controls and 390px panel navigation. No browser exceptions were observed.
- Both documentation builds passed. The handbook retains existing warnings, including repository-source links outside its site directory; all local link targets in the touched design documents were checked separately.
This evidence concerns the interface and persistence. The live-stack E2E suite, functional-user sessions and generated-agent runtime evaluations were not run for this UI iteration.