Skip to content

Conversational design

Status: Preview | Last reviewed: 2026-09-25

/studio now creates and refines real Voice, Chat, Copilot, Translation and Background drafts through the selected Claude Code or OpenAI authoring engine. The author describes business needs in the conversation. Use Cases, Behavior and Validate show committed design output alongside the conversation.

The Multi-agent demo selection creates a project over ordinary drafts, with Journey, Agents, Connections, Preview and Validate tabs. It supports supervisor Chat during self-service and an Agent Assist Copilot for the human-to-human segment. See Multi-agent demos for its separate protocol, scoped component tools, native connections and aggregate build gate.

This is the first live vertical slice. It does not implement the whole authoring research proposal.

Reuse and boundaries

The asynchronous Generate with AI job retains its existing lifecycle. Conversational design uses its interactive counterpart: assistant_sessions, the generation MCP endpoint, the same credential resolution and the runner's persistent as-<session-id> workspace with claude --resume for Claude Code. OpenAI authoring uses managed provider sessions and the same scoped tools. Each design pins its engine and integration when created.

The designer uses one scoped writer. A versioned designer_protocol.md adds functional-user guidance, requirement discovery, type-specific instructions, draft edits and structured design updates. It requires the assistant to re-read the saved draft and design on each turn. Existing discovery tools supply templates, prompting snippets, saved tools, service definitions, workflow node manifests and tenant integrations. The designer also searches existing same-kind agents in the current tenant, shared/tenant capabilities, and published multimodal catalogs. Protocol v11 uses targeted research to inform clarification, then inspects suitable templates/examples when developing the first design. Shared research adds public web search, optional Library video transcripts, focused configuration schemas and detailed capability handbooks. High-level answers are interpreted using verified capabilities and technical defaults; consequential business decisions still require the author. See generation research. Existing agents are read-only references; their current published version is preferred, otherwise their draft is identified explicitly. Catalog discovery reads the published manifest snapshot, including component inputs and emitted actions, rather than unpublished component edits.

No extra model monitors the transcript. A two-second browser poll reads committed design state during a turn; the terminal stream event triggers a refresh after history persistence. Additional analysis workers should use proposals and revision checks rather than write the same draft independently. The browser NDJSON stream sends an empty heartbeat every 15 seconds during quiet model work. This prevents client/proxy idle timeouts without extending the runner's 30-minute deadline or exposing intermediate reasoning. A browser disconnect still leaves the upstream turn draining and saving progress. OpenAI tool-result delivery retries a transient error at most five times, polling pending actions before resending the cached result. Permanent errors fail immediately. Exhausted retries request cancellation and show a provider delivery error with a build-retry instruction, without exposing raw provider payloads. Saved drafts remain available for a build retry, and the underlying mutation is not executed again. An explicit retry after a failed designer turn starts fresh provider context using the same saved design and drafts, even if cancellation made the provider report idle. The runner also recovers an orphaned pending provider turn. Cleanup is requested; the abandoned tool call is not replayed. Normal completed turns keep their existing provider context.

The runner sends only the final Claude response as designer chat text. Tool calls become functional activity labels in a collapsed inline Thinking section. report_design_progress supplies short public updates and design decisions. Up to 60 activities per turn persist across reloads, grouped with the corresponding user message. The browser receives neither private reasoning nor raw tool arguments/results. The editor stream is unchanged.

Starting and resuming

The designer asks only unresolved material questions in a saved form within the conversation. There is no question quota: a sufficient brief needs none. It covers business outcomes, permitted actions and meaningful preferences, skipping information already supplied and choosing verified technical defaults. Technology preference is normally in the first group when unknown; choosing "recommend one" delegates the choice without requiring technical expertise. Existing connections and baseline settings are options, not approval.

During clarification it may update confirmed needs in the overview, but the server rejects executable configuration saves; the prompt also avoids detailed procedures or new goldens. The ask_design_questions tool presents each group after overview updates, then the model ends its turn. Its final reply briefly invites Submit answers without repeating the questions. Intermediate assistant text is hidden; every question is in the saved form, not hidden in the side panel. Behavior and a small set of example test cases can evolve from confirmed needs during clarification; unresolved business decisions precede a detailed design or full suite. Native Performance records wait for Build draft. Deferred decisions are recorded in the overview's description/behavior rather than disguised as questions. Reference agents/templates cannot silently supply business authority, return/refund rules or organizational identity policies. Once the brief is understood, the designer recaps it and develops the proposed responsibilities, tools, capabilities and test cases. A clear brief can proceed directly to a proposed specification. Later small refinements do not require repeating the whole intake.

The selected type bounds the deliverable. A Voice demo brief produces one voice agent, not a portal, agent desktop, presentation or multi-agent demo. Use Cases describes business work. Startup lookup stays in startup logic; authentication stays in capability settings and native verified-state gates; ending and summaries stay in the main prompt. These routine behaviors do not require separate procedures.

get_design_state.authoring_defaults supplies current guidance and redacted tenant authentication readiness on every read. For protected member information, the built-in identity default is native Customer Authentication with passkey, AAL2, on-demand verification and native enrollment enabled. The caller still consents to the link, and enrollment alone does not count as verification. Sensitive tools require native verified state; human escalation remains available before verification. Explicit compatible identity settings take precedence. OIDC tenants receive no invented assurance configuration: their existing identity policy must be checked. Missing setup is an implementation prerequisite, not a question about whether protected information needs authentication.

The initial baseline draft still exists from creation. An older conversation with premature design work retains that draft; the next turn should clarify unconfirmed preferences before further changes.

Question forms

ask_design_questions accepts a title and one to six material questions, each with a stable ID, short navigation label, question text, optional choices and a single/multiple-choice flag. The server assigns the form ID and persists it in assistant_sessions.design_questions. The tool returns immediately; the CLI never waits on a human. Existing turns discover the tool through the same scoped generation MCP endpoint, and the per-turn instruction reinforces it.

The pending form replaces the message composer. Authors move between questions with navigation chips or Back/Next, write a separate answer for each, select choices, add detail, or explicitly choose I’m not sure yet. No option is preselected. Progress counts and Submit answers stay visible; the question body scrolls on small screens. Image/text references remain available. Unsubmitted answers are kept in sessionStorage for this design/form in the current browser tab. They survive reload there, but are not synced to another device or tab. If storage is unavailable, answers remain in memory.

The existing message endpoint accepts question_answers: { question_set_id, answers } instead of message. Inside the turn-admission transaction, it validates the pending form ID, exact question set, option IDs, single/multiple selection, nonblank answers and explicit deferrals. It then saves the answered form and one canonical user message together with the turn lease. Canonical question and choice wording comes from the server; client-provided labels are not trusted. Answer submission advances the design revision to invalidate older build approval. Only the author can submit. Model tools cannot answer, clear or replace a pending form. Duplicate requests return 409; stale forms and ordinary messages while questions are pending are rejected without consuming answers.

The UI restores the normal composer after acceptance. Submitted answers survive a runner failure and are available through history and get_design_state. A failed request before acceptance leaves the form and local answers intact. The server blocks builds, executable saves and handoff while questions are pending. A build that discovers a blocking decision can ask a form and stop; the author discusses the answers before explicitly continuing the build.

Use Cases has no Still to decide section. The legacy open_questions property remains readable for stored overviews, but is not rendered and new updates send an empty array. All question gathering uses the form tool. Behavior and Validate omit default Proposed and Not run badges; the content updates through the existing committed-state polling as the conversation develops. Actual created-tool connection notices and saved Performance references remain visible. Removing default badges does not execute tests or change their status.

Voice stack choices

Voice technology questions can set preset: "voice_stack" and omit options. The server inserts the shared choices from voice-stack-options.ts before saving the form. get_design_state.voice_stack_defaults exposes the same choices and runtime guidance to the model. The standalone Voice prototype shares the labels and records the selected preference in Behavior.

Starting choice Intended trade-off
GPT-Live — experience first Premium budget, quick expressive conversation and natural interruptions.
Deepgram + text AI + ElevenLabs — cost and control first Lower budget, explicit checks before speech, and more response delay.
Preferred platform / Help me choose Respect an approved alternative or discuss the requirements before choosing.

These are product starting positions, not measured cheapest/fastest guarantees. Actual cost depends on selected models, workload and configured checks. GPT-Live has session-duration and separate backend model/tool costs; use the configured cost estimate when comparing a concrete build. Neither architecture establishes compliance by itself. Provider, data location/retention and control requirements take priority; the model can use custom choices when restrictions exclude a default. The preset applies to Voice agents and Multi-agent demos and requires a single selection.

The runtime mapping deliberately distinguishes OpenAILiveLLMService (openai / s2s / GPT Live API) from Realtime and GPT Live Transcribe. Live's speech model and reasoning backend are separate; Live always produces audio. The cascaded mapping uses an approved Deepgram STT service, an efficient text LLM, and ElevenLabsTTSService. Consult current service definitions before building; these options neither switch the saved baseline nor authorize a build. See GPT Live and authored controls.

Built-in actions and telephony escalation

get_builtin_tools is shared by the designer, Generate with AI and the editor assistant. Without name it lists built-ins; with a callable or capability name it returns the actual static runtime schema, configuration notes and examples. get_tool also accepts recognized built-in names/references. Saved-tool search explicitly identifies its narrower scope: an empty result is not evidence that a platform action or existing telephony handoff is unavailable. get_service_definition includes built-in contracts alongside its usual fields; get_design_state supplies balanced scope and capability defaults each turn.

end_session accepts required reason, optional boolean session_escalated, and optional params with custom string values. Human escalation sets the flag to true and returns a concise AI-interaction summary in params.summary to the connected telephony/contact-centre flow. The receiving system performs routing; a real channel test must confirm that behavior. This is separate from External Consult, which dials, briefs and merges another leg. CES S2S uses native endSession.metadata instead.

Protocol v10 treats this as routine main-prompt behavior. It does not ask about phone ownership, hours, queues or summary fields by default. Explicitly supplied custom mappings are respected; custom routing questions apply only to requested actions this agent must implement. The designer answers factual questions directly in its final chat reply; an explanation request does not trigger a discovery questionnaire. Built-ins can be described under Capabilities or as planned tools; they have no saved-tool UUID. Build coverage accepts a selected builtin: reference only when its owning service offers it, and does not query the saved-tool table for that ref.

Sources and update commands:

  • apps/ai-manager/lib/generation-mcp/builtin-tools.ts: discovery and functional design guidance, including handoff versus goodbye and capability-owned names.
  • shared/generation-docs/src/builtin-tools-guide.md: authoring reference.
  • python shared/generation-docs/generate_builtin_contracts.py: export base FunctionSchemas from the runtime helpers into the committed app JSON. test_generation_builtin_contracts.py checks drift without importing providers.
  • shared/generation-docs/build.ts: rebuild the runner bundle, including builtin-tool-reference.md. Refresh the runner while idle so resumed sessions receive the updated protocol and reference bundle.

Build and handoff

Build draft is an explicit author action. It submits a build intent and the viewed design revision through the existing assistant message endpoint. The server snapshots the approved overview and admits one build turn. Build turns use ASSISTANT_TURN_WALL_MS, default 1,800,000 ms (30 minutes), because Design runs through the assistant session path, not the separate GENERATION_WALL_MS job path. Configure the same value on ai-manager and workspace-agent-runner. The internal response stream allows one additional minute of silence for timeout cleanup; Vanguard's proxy allows an hour. Ordinary conversation cannot authorize executable saves, even if the model tries to call a save tool. The snapshot is frozen during generation.

The same Claude engine then creates the actual configuration and native artifacts. complete_design_build must verify:

  • A validated, saved draft newer than the build's starting revision.
  • Every listed procedure as visible step blocks in a real prompt scope. Specialists reference real topic or subagent definitions; background work references implemented nodes. Native translation uses behavior references to incoming/outgoing stage settings.
  • Every listed tool selected in its actual scope, with an inline definition or an available saved tool. Unspecified connections default to working sample tools, created by prepare_mock_tool; deliberately failing scaffolds require an explicit request. These are local tools, not tenant-library entries.
  • Generated sample tools match their stored specification and input schema, and their examples pass in code-executor. This executes only the server's generated sample function, with no integration grants or external actions. Probes run outside database locks; completion rechecks the saved revision.
  • Concrete configuration references for agreed capabilities, including settings, authored rules and supported multimodal mappings.
  • Every proposed agent test saved as a synthetic dialogue in agent_goldens, with its requirement and expected outcome in agent_goals. Both are visible in Performance. Background cases become workflow_test_inputs with real example context; expected outcomes remain in Design because the existing workflow tester does not automatically assert them.

This verifies structural coverage, saved artifacts and generated sample checks, not semantic correctness, successful system connections, compliance or executed evaluations. The server owns the completion receipt; a model's statement that it is done does not make a build ready. Missing artifacts keep the user in Design with Continue build. Retries preserve saved work and reuse generated test IDs. Test fingerprints prevent overwriting a manually edited golden, goal or input. Unrelated tests and earlier cases removed from a later design are retained.

Sample tools and usable test data

lib/generation-mcp/mock-tools.ts owns the shared prepare_mock_tool schema, pure Python generator and executor checks. The model supplies data: parameters, a useful fallback result, ordered matching scenarios, examples and a plain-language test guide. It cannot submit Python to this tool. String matches ignore case, spaces and hyphens; response templates echo inputs and calculate relative dates. Results always carry mock: true and external_changes: false. Every scenario and the fallback need a passing example, including a success. The saved config.mock travels with the source and parameters; mismatched source/schema blocks Design completion. A scaffold labelled as a mock also blocks completion.

Protocol v8 and mock-tools-guide.md require a final-chat list of inputs and outcomes, plus matching fixtures in native test examples. Related tools must agree on sample state and verification details. Generated prompts explain simulated writes without treating all sample results as connection failures. These sample tools are stateless: simulated writes do not alter later lookups. Native Performance evaluations remain unexecuted. Replace sample implementations and remove config.mock when connecting real systems.

After completion, Open draft performs a fresh server check, records the handoff and returns the editor URL. It never navigates automatically. A server layout guard redirects an active, unhanded-off design's direct editor URL back to Design before mounting the autosaving editor. Once handed off, ordinary manual editing remains available. Ended/expired conversations retain the existing manual draft-recovery path.

Changing the overview or saved draft invalidates an older completion receipt. Deleting or editing generated tests, or deleting a referenced saved tool, also prevents a new handoff. Opening never publishes, activates a background agent or runs the test cases.

Availability and persistence

The design Home polls every five seconds while visible. Recent conversations distinguish working, ready and interrupted/failed turns. It also lists the creator's in-progress Generate with AI jobs, including jobs waiting for an answer, and links them to the existing editor/generation experience. Both lists respect tenant and agent/workflow permissions. Each list is capped at 30; active designer turns are ordered first.

The server checks FEATURE_CONVERSATIONAL_DESIGN, the appropriate agent or workflow feature/permission, and all three Generate with AI availability gates. The author chooses a business type before the conversation:

Type Starting artifact
Voice Existing curated voice generation baseline
Chat Existing curated chat generation baseline
Copilot Native Agent Assist baseline with top-level config.copilot
Translation Existing unified translation defaults, retaining directional flows
Background Blank workflow plus a version-0 draft, explicitly inactive
Multi-agent demo Parent project; component drafts are created during the approved build

Creation is one transaction. A creator/tenant/request-key advisory lock and unique key prevent a retry from creating another artifact. Reusing the key for different input returns a conflict. Background version rows explicitly inherit the tenant; the legacy create_workflow_draft SQL helper defaults that column and is unsuitable for this initial insert.

The first message lazily creates the runner workspace through the existing 404-recovery path. Subsequent turns reuse the CLI session. On runner loss, ai-manager rotates the scoped token, reseeds the designer protocol, clears the CLI session and supplies recent conversation context. Saved design state and the real draft remain authoritative.

Conversations belong to their creator and tenant. Explicit tenant comparisons also apply on databases whose backend role bypasses RLS. The existing sliding seven-day assistant expiry applies; ended conversations remain viewable, and the artifact remains accessible through its editor.

State and tools

Migration 057 adds surface, design_type, original request, typed overview, design revision, source draft revision and creation key to assistant_sessions. The active-session index includes surface and access_mode, allowing the editor assistant and designer to coexist. Existing sessions default to surface=editor.

Migration 063 adds demo projects, keyed component membership and human-recorded journey observations. It also permits the Copilot and Multi-agent demo selections. The separate kind=demo is authoring state, not a runtime agent type.

Migration 059 adds server-owned design_build (approved snapshot, request, artifact references, test fingerprints and completion revision), design_handed_off_at, and turn intent. Existing designs have no completion receipt and must build before using the new handoff.

Migration 060 adds design_questions. It is authoring state, separate from executable configuration. Existing sessions can use the new tool on their next turn without recreating their draft; existing prose is not automatically parsed into questions.

assistant_design_turns records a request ID before history/CLI side effects. One unexpired running turn is admitted per session. Repeated accepted request IDs return 409 without replaying the model. A lease lasts the turn wall limit plus one minute (31 minutes by default); expired work is marked interrupted when admitting another turn, never assumed successful.

The designer toolset retains generation discovery/validation and adds:

Tool Contract
ask_design_questions Persist a navigable question form, then end the turn; only the author's subsequent submission can answer it.
get_current_draft Returns editable config and its exact saved revision, even when a published version exists
save_*_draft_config Requires an active authorized build and expected_revision; validates the target config and rejects stale saves
get_design_state Returns type, original request, overview, revision and current build snapshot/receipt
update_design_state Validates a complete overview, locks/checks its source draft, compares the design revision and updates title/description metadata
report_design_progress Appends a short public update to the active turn; the protocol excludes working notes and credentials
search_existing_agents / get_existing_agent Bounded, same-tenant, same-kind references with version provenance; excludes this draft and templates
search_capabilities / get_capability Available capability manifests and configuration requirements
search_multimodal_components / get_multimodal_catalog Published visual components, versioned catalog URI and manifest
list_design_sources / read_design_source Session-scoped references; native MCP image blocks or bounded UTF-8 text
prepare_design_placeholder_tool Returns a complete failing inline-tool scaffold for the model to wire and save
save_design_test_artifacts Saves native Performance goldens/goals or workflow test inputs; protects manual edits and reuses IDs on retry
complete_design_build Checks artifact coverage against the frozen specification and records readiness only after every check passes

Design output is stored outside executable config. Required tools may remain needed, without an executable ID. A selected tool must have an accessible real UUID actually selected in the saved config; selection is not a successful connection test. Built-in features belong in the capabilities overview.

Proposed cases include situations, expected outcomes, requirement descriptions and stable IDs. The schema rejects model-supplied pass/fail status. Validate always shows Not run. Overview fields describe the proposal; they are not proof of enforced security or working runtime behavior.

No designer tool publishes, activates a workflow or executes business actions. Saved draft changes invalidate an older overview. The UI then asks the author to request a review. The shared save helper also resets the collaboration room: revision checks protect saved edits, but do not merge another editor's unflushed keystrokes. Open draft requires a completed build and no active turn.

Image and text references

The conversation accepts up to eight PNG/JPEG/WebP images (5 MiB each) or UTF-8 text/Markdown files (80 KB each). The authenticated upload endpoint caps the multipart body before parsing, checks type/signature or UTF-8, sanitizes the filename and records size/hash. Existing getStore('assets') storage holds the contents under a tenant/session/UUID key; no public object URL is returned. Downloads and removal require the creator, tenant and matching kind permission. Use the existing private assets-bucket configuration; no new bucket is created.

Migration 058_designer_sources_activity.sql adds turn activities and assistant_design_sources, with tenant/session foreign keys and forced RLS. Uploads are idempotent by request UUID and content hash. Upload/removal and turn admission lock the same session row, preventing references changing during a reply. The CLI reads images as native MCP image content and text as reference data. All references and discovered configurations remain untrusted evidence.

Ready to share means stored but not yet requested by the assistant. Sent to designer means the reference reader returned the contents; it is not proof that the model correctly understood them. Uploading does not start a model turn or configure runtime knowledge. Removing a reference deletes the stored file and clears CLI resume context for the next turn. Saved conversation and design summaries may still contain derived information. Ended sessions retain references until explicitly removed; removing them is allowed when no turn is running, even after the conversation ends. Automatic object retention cleanup is not implemented in this preview.

The runner permits bounded JSONL records up to 16 MiB because native image results can repeat base64 content within one record. It bounds its output queue and reports read failures immediately. Designer sessions reject non-JSON stdout as unreadable output instead of displaying raw diagnostic text in chat.

Component discovery supports reuse and planning. Building/publishing new components, PDF/audio/video ingestion and voice input to the designer remain outside this slice.

Where to review prompts and tools

Internal API

These authenticated application routes are not part of the public Integration or Management OpenAPI contracts.

Route Purpose
GET /api/studio/designs Availability, allowed types, recent designs with turn status and in-progress generation jobs
POST /api/studio/designs {type, prompt, creation_key} → saved session ID
GET /api/studio/designs/{id} Conversation, overview, revisions, reference metadata and saved turn activity
POST /api/studio/designs/{id}/sources Multipart file and UUID source_id; private reference upload
GET /api/studio/designs/{id}/sources/{sourceId} Authenticated file download
DELETE /api/studio/designs/{id}/sources/{sourceId} Remove a reference while no turn is running
POST /api/assistant/sessions/{id}/messages Existing NDJSON stream; designer turns require {message, request_id}
POST /api/studio/designs/{id}/handoff Rechecks the completed build, records the author's handoff and returns the editor URL

Build messages also require intent: "build" and the current design_revision. An outdated revision returns 409 before any generation starts.

Browser disconnects do not cancel accepted work. The server drains the runner, saves the response and releases the turn lease. Reload reads saved progress; the browser never automatically resends an accepted request. Interrupted or failed streams show an error and preserve completed draft writes.

Local setup and verification

For a local city instance, set FEATURE_CONVERSATIONAL_DESIGN=true, FEATURE_AI_GENERATION=true and NEXT_PUBLIC_FEATURE_AI_GENERATION=true in .env.local, then restart AI Manager. The tenant must also have Generate with AI enabled with an active supported integration. The navigation context accepts either agent or workflow authoring access; it does not require conversational agents in a workflow-only deployment.

Apply existing migrations 057–063 before starting the updated app: designer state, references/activity, build handoff, questions, authoring provider state and multi-agent demo projects. They are registered in migrate-city-db.sh and included in the canonical baseline. These changes retain existing agent drafts. Rebuild/restart the containerized runner to include its new protocol file:

overmind restart workspace-agent-runner

If Docker fails while loading the public Python base image with “error getting credentials”, a devcontainer may have an unavailable host credential helper. Set WORKSPACE_AGENT_RUNNER_DOCKER_CONFIG to the absolute path of .devcontainer/docker-public in local .env.local. The launcher uses this empty registry configuration only for its public-image build; runtime Docker settings and provider credentials are unchanged.

Restart only when current work has finished. Existing conversations then recover their workspace with the updated protocol on their next turn; saved history and drafts remain in the database. Prompt instructions also appear in the designer MCP initialization message and save/overview tool descriptions, so keep those aligned with designer_protocol.md. The Generate with AI and editor-assistant prompts remain separate.

The existing feature and tenant AI connection settings remain required. npm run dev:prototype deliberately retains scripted browser-local briefs for standalone design exports. A live backend failure never falls back to scripted replies.

Focused checks:

cd apps/ai-manager
npm run typecheck
node --import tsx --test lib/studio/*.test.ts lib/assistant-mcp/tools.test.ts
# Disposable DB with core schema, reference data (001/043) and migrations 057–060.
DESIGN_TEST_DATABASE_URL=… node --import tsx scripts/test-conversational-design-local.ts
DESIGN_TEST_DATABASE_URL=… node --import tsx scripts/test-designer-handoff-local.ts
DESIGN_TEST_DATABASE_URL=… node --import tsx scripts/test-designer-questions-local.ts

The integration script checks all four starting artifacts, inactive background work, tenant/creator isolation, actual RLS, duplicate creation/turn admission, editor coexistence, draft/design conflicts, reference isolation/idempotency, native image responses, durable activity and upload/turn exclusion. Runner tests cover protocol seeding and the unchanged CLI/resume boundary.

For clarification regression checks, start with a short order-support voice request, then submit a group of answers, leaving uncertain choices explicitly undecided. Each group should appear in a saved question form, with no executable draft revision change or new goldens. Supply the remaining brief and verify that the designer prepares an agreed specification without executable saves. Choose Build draft and check both the completion receipt and native Performance goldens/goals (or saved background inputs). Then explicitly open the draft. Checking only the overview misses both hidden questions and missing artifacts.

Protocol v10 planning was checked on 2026-09-18 with live GPT-6 Astra at low reasoning effort, using the Responses evaluation transport, real scoped reference reads and in-memory specification/form writes. A broad health-plan brief asked three questions about the journey, voice platform and data source; none asked about authentication configuration, phone ownership or demo staging. The specified unexpected-bill case asked no questions and proposed one business procedure, native passkey authentication with verified gates, and main-prompt ending/summary behavior. It read actual capability schemas, an existing agent and a Library transcript. These are planning checks, not a completed agent build, native authentication ceremony or phone-routing test.

Protocol v5's form handoff was verified on 2026-09-10 with the real Claude engine. An underspecified library chat request produced a saved six-question form in 44.6 seconds. Submitting explicit undecided answers resumed the same conversation in 61.3 seconds and produced a follow-up form with explanations. Answers appeared once in history; duplicate submission returned 409 and both turns preserved the executable draft. The disposable design was removed. Question-form integration checks passed for all four types, including tenant boundaries, immutable pending forms, atomic retries, malformed/stale answer rejection, build blocking and answer persistence after a failed runner turn. Browser checks cover desktop/mobile navigation, separate answer boxes, multi-select choices, reload, failed submission and the restored composer. The standalone prototype uses the same form and batch-submission contract.

Protocol v4 was verified on 2026-09-10 with the real Claude engine: an agreed chat specification left configuration unchanged, then a separate build created a visible named procedure, an in-conversation specialist, a failing inline lookup scaffold, and three native Performance goldens with matching goals. The specification took 79.7 seconds and the build 206.7 seconds. A direct editor URL returned to Design before completion; the explicit handoff then opened the editor, and browser review confirmed the saved Goldens page. These checks did not execute the resulting agent or claim the goldens passed.

The disposable-database handoff suite covers Voice, Chat, Translation and Background builds, actual native test records, draft authorization, frozen specifications, duplicate requests, retry identity, manual-test conflicts and tenant isolation. Browser contract coverage includes incomplete builds and handoff rejection. The shared prototype separately verifies simulated builds and continued editing; it does not create real Performance records.

Earlier protocol v3 was verified on 2026-09-10 with a real four-turn Claude-backed voice design. The opening reply asked four visible questions, including platform preference; a partial answer produced four visible follow-up questions about privacy, systems, authority and tone. Supplying the remaining brief produced a recap and a question about starting the draft. All three turns left the executable draft unchanged and proposed tests empty. Explicit agreement then saved the draft and 15 unrun cases, with connections and deferred decisions still unresolved. Clarification turns took 46.9, 32.1 and 42.2 seconds; the build took 163.1 seconds. The disposable designs were removed after verification.

Earlier implementation checks, before protocol v3's clarification policy: a real Claude-backed chat design on 2026-09-10 saved its configuration, description and four unrun cases. A second turn after runner restart recovered the workspace, changed Saturday hours and revised the corresponding goldens. Reloading during that turn retained one user entry; repeating the accepted request returned 409. Desktop and 390px mobile review succeeded. These are authoring checks, not executions of the generated library agent. The two measured turns took 90.9 and 89.6 seconds. This is a latency limitation of the current preview, not a conversational-speed target. Progress remains visible while the core engine works; reducing turn time is follow-up work.

The image-reference extension was also verified on 2026-09-10. The first live attempt exposed the runner's 64 KiB line-reader limit: Claude read the image and saved design state, but subsequent stream events stalled. After increasing the bounded limit and adding pump-failure handling, a new image-guided turn finished in 110 seconds with 24 persisted activity updates and four unrun goldens. It searched templates and existing agents, read an older reference agent, and correctly used different hours from the newer attached image. Browser events contained public activity/final text only. Reload and 390px mobile checks passed; the synthetic drafts and uploaded files were removed.

Extension checks: 26 focused TypeScript tests, all 22 runner tests, five live surface browser contract tests (two standalone-prototype cases skipped), the disposable database integration script, type checking, focused lint, 430-route auth audit, migration replay and full schema drift checks passed. Both documentation builds passed with existing handbook link warnings.

Remaining work

  • Executed evaluations, regression suites and evidence-linked results.
  • Explicit runtime eligibility/control decisions beyond prompt guidance.
  • PDF/audio/video ingestion, voice interaction with the designer and component generation.
  • Editable, structured connection requirements beyond the initial named tool intents.
  • Proposal review, audit history, richer artifact dependencies and conflict merging.
  • Migration of older browser-local preview briefs into live sessions.

See also