Conversational authoring primary-source research¶
Status: Draft | Last reviewed: 2026-09-10
Use this source record to check the external basis for the authoring recommendation. All sources below were retrieved on 2026-09-10. They are primary provider, protocol, project, or standards sources; repository evidence remains authoritative for what TrueServe actually implements.
Method and limits¶
Review the existing plan and implementation first, then use external material to compare orchestration, prompting, tool discovery, modality handling, and evaluation patterns. Follow redirects and distinguish current guidance from older material that remains useful conceptually.
The architectural choices in this pack are recommendations inferred from those sources and repository constraints. Vendor examples and published benchmarks are not TrueServe feasibility results. Do not copy public model IDs or API features into a draft until live service-definition and tenant-eligibility checks pass.
Retain source URL, retrieval date, applicability, and reviewed content hash in the proposed guidance registry. Re-fetch on a controlled schedule and when a relevant model/API/runtime changes; review diffs before updating published guidance. Do not store whole provider documentation pages in every authoring prompt.
S1 Composable agent workflows¶
Source: Anthropic, Building effective agents.
Finding: The article distinguishes prescribed workflows from model-directed agents and recommends adding complexity when the task needs it. It presents routing and orchestrator/worker patterns.
Application: Start with a coordinator, deterministic enforcement, and scoped workers. Evaluate specialists on difficult tasks rather than adopting one agent per concern.
Limit: The article originates in December 2024 and now flags changes in the tooling landscape. Use its architectural reasoning, not historical library/model examples as current defaults.
S2 Tool discovery and examples¶
Source: Anthropic, Introducing advanced tool use.
Finding: Loading tool definitions on demand can reduce unnecessary context. Schemas describe valid structure, while examples also explain usage conventions.
Application: Return compact search results, fetch selected tool contracts, and include successful/error examples in verified patterns.
Limit: Provider-specific feature availability and benchmark results do not establish support or equivalent gains in the existing TrueServe runner.
S3 Claude prompting¶
Source: Anthropic, Prompting best practices.
Finding: Current guidance emphasizes explicit instructions, useful examples, separation of input material, and model-specific recommendations.
Application: Split shared authoring policy from conditional model guidance. Test prompt examples against the selected authoring model and task.
Limit: A technique measured on one model is not a universal rule. Do not turn example counts, prompt length, or delimiter choice into unsupported global constraints.
S4 OpenAI Realtime prompting¶
Sources: OpenAI, Realtime prompting and Realtime and audio.
Finding: Voice instructions and available tools must agree. The current audio overview distinguishes conversational voice, continuous translation, transcription, and request-based audio architectures.
Application: Retrieve guidance for the actual API/session type. Check tool names against the effective prompt. Keep Translation Agent design separate from conversational voice-agent behavior.
Limit: New provider translation or audio APIs do not automatically exist in TrueServe's runtime adapters. Do not infer transport, tool, or model parity across session types.
S5 Structured outputs¶
Source: OpenAI, Structured model outputs.
Finding: Structured response formats and function calling serve different integration purposes. Supported schema subsets, refusal handling, and incomplete output require explicit handling.
Application: Use typed brief/change-proposal outputs when available, then validate references, permissions, business meaning, and runtime behavior independently.
Limit: Schema adherence does not establish that a tool exists, a provider is configured, or a business action succeeded. The current Claude CLI runner does not inherit OpenAI API features from this recommendation.
S6 Amazon Nova speech guidance¶
Sources: AWS, Voice conversation prompts for Nova 2 and the Nova 1 speech prompting page.
Finding: The older page explicitly directs Nova 2 users to separate guidance. Nova 2 distinguishes general system instructions from specialized speech prompts for particular transcription formatting.
Application: Tag guidance by model generation and purpose. Keep spoken response style, language policy, and specialized transcription settings distinct.
Limit: Do not transplant narrow speech-prompt settings into general instructions or assume that all deployed Nova integrations accept them. Provider examples are candidates for evaluation, not mandatory scripts.
S7 Gemini Live¶
Source: Google, Live API capabilities, reached from the older live-guide path.
Finding: Live API documentation describes its own media-input and function-response behavior.
Application: Attach modality and tool-lifecycle constraints to the exact provider/API adapter. Verify capability availability at design and binding time.
Limit: Native provider media support does not prove that Studio uploads, the phone transport, or the TrueServe runtime can deliver that media. Recheck evolving limits instead of fixing them in generic authoring rules.
S8 Evaluation design¶
Source: OpenAI, Evaluation best practices.
Finding: Generative behavior varies across runs. Evaluations should match the task, combine metrics with human judgment, and expand as failures are discovered.
Application: Compare identical authoring scenarios, preserve held-out cases, and separately grade conversation quality, artifacts, and runtime outcomes.
Limit: Example evaluation thresholds from unrelated tasks do not determine the acceptance thresholds for this product.
S9 Conversation questions¶
Source: Google, Conversation design: questions.
Finding: Question wording changes the range of expected answers. Supply enough information to proceed and add detail when the user needs it.
Application: Ask focused consequential questions, use prior answers, and narrow the question after confusion.
Limit: This is legacy-platform interaction guidance. Its platform is not an implementation recommendation, and its advice still needs validation with TrueServe authors.
S10 Persisted orchestration¶
Source: LangChain, LangGraph persistence, reached from the durable-execution documentation path.
Finding: Checkpoints preserve graph/thread state for continuity, interrupted work, and failure recovery.
Application: Persist the brief and operation results independently of a CLI session. Compare a graph-backed implementation only if the state machine grows complex enough to benefit.
Limit: Checkpoints do not make an external publish/write exactly-once. Reconciliation and idempotency remain application responsibilities; existing workflow-runtime usage is not an authoring implementation.
S11 MCP elicitation¶
Source: MCP, Elicitation, specification 2025-11-25.
Finding: Clients negotiate support for structured form and URL-based elicitation. The specification separates ordinary form answers from sensitive external setup.
Application: Adapt authoring questions to capable MCP clients while preserving the product's own question protocol. Send credential setup through an authorized secure UI.
Limit: Do not assume every client implements elicitation. Do not use authoring forms to collect integration secrets.
S12 MCP tool contracts¶
Source: MCP, Tools, specification 2025-11-25.
Finding: Tool contracts can include structured outputs. Execution failures and protocol errors are distinct, and annotations from untrusted servers are not authority.
Application: Define outputs/errors as carefully as inputs and preserve actionable failure results. Enforce privileges and side-effect policy on the server.
Limit: A readOnlyHint, description, or remote schema is not proof of behavior or permission.
S13 A2UI trust boundary¶
Source: Google A2UI, primary repository README, inspected through its raw source.
Finding: A2UI sends declarative interface descriptions for client-owned components. The component catalog defines what the client can render.
Application: Separate runtime UI intent from generated component source and its build/review boundary.
Limit: Current upstream protocol versions do not establish compatibility with TrueServe's local compiler/renderer. The searched a2ui.org/concepts/security/ path returned 404 during this review and is not used as evidence.
S14 Accessible form errors¶
Source: W3C, Understanding SC 3.3.1: Error identification.
Finding: Users need a textual description identifying erroneous input; color alone is insufficient.
Application: Generated forms identify invalid fields, preserve input, and provide useful correction text, alongside keyboard/focus testing.
Limit: This single criterion does not establish full accessibility compliance. Evaluate the complete interaction.
Repository evidence¶
Additional runtime-selection evidence comes from requirements and runtime selection: the actual text/S2S guard processors, profile derivation, and the existing compliance/governance interfaces. Their limitations take precedence over generic architectural advice.
The capability matrix links each local finding to source or operational documentation. The repository snapshot records HEAD and hashes of key inspected files; the tree contained pre-existing uncommitted work. The validator observations are actual offline outputs, while scenario fixtures are proposed inputs.
Do not reinterpret a prose finding, model-generated example, or source build as a passed runtime experiment.
S15 Voice architecture selection¶
Source: OpenAI, Voice agents: choose the right architecture, retrieved on 2026-09-10.
Finding: Direct speech-to-speech handles live audio input/output; a chained pipeline keeps explicit control over transcription, text reasoning, and speech generation.
Application: Compare runtime shapes against required interception points and measured experience, after filtering mandatory policy constraints.
Limit: This does not establish a universal empathy or latency ranking, or a security guarantee. TrueServe's half-cascade definition and guard behavior come from its own code.