Conversational Design Systems

When graphical interfaces became mainstream, designing each screen by hand stopped being sustainable, and Design Systems became the shared language that let products scale without losing coherence. They solved a real problem: they standardized how software looks. Large language models introduce a different problem. Software now communicates. It remembers context, calls tools, triggers workflows, renders cards, generates interfaces, and hands work to other agents, often in ecosystems where a person never visits the original application at all. This book argues that AI products need the design-system move one layer up: a Conversational Design System, a shared architecture that keeps meaning, behavior, and language coherent when a model generates the surface.

What these products need is a system for accountable adaptive experience, not only for chat: an experience control plane. A product should be free to adapt its wording, its ordering, its channel, even its interface. The things it must stand behind, what it has promised, what it may do, what it knows to be true, what it remembers about people, do not adapt. Conversation is one rendering. Voice is another; a generated card is another; a task handed to a partner agent is another. The stable layer beneath them all is the design system this book describes.

Two names run through this book. Conversational Design Systems is the discipline, born in chat, the first place software started negotiating meaning with people. The experience control plane is the machine, the layer that carries the same discipline past chat into tools, generated interfaces, agent handoffs, and durable tasks. The discipline decides what a product must stand behind, and the machine makes sure it does.

The book moves in four parts. Part I makes the argument: why communication architecture is missing from AI products, and when adopting it is worth the cost, because for many products it is not. Part II opens with a short chapter that shows the whole machine running, so the parts have somewhere to fit, then defines the architecture piece by piece: semantic components, experience graphs, contracts, authority, context, profiles, renderers, and the control plane that coordinates them. Part III is about operating the system: runtime, implementation, evaluation, and governance. Part IV lets the strongest objections speak at full strength, and closes with the discipline that remains.

A few choices distinguish this framework from its neighbors. Memory is a designed, permissioned artifact compiled into context, not an accumulation. Tools and consequential actions get contracts of their own, backed by authority graphs. Generative UI is treated as a strong renderer rather than a rival. Evaluation is a development practice built on eval packs and replayable traces, not a closing sentiment. And governance maps onto the traceability, oversight, and lifecycle control that AI regulation and management standards increasingly expect anyway.

Each chapter closes with a law: a one-sentence constraint that can travel into a design review, a model upgrade, a vendor decision, or a postmortem. The form is deliberate. Long arguments rarely survive contact with a roadmap meeting; short ones sometimes do. Each law is argued in its chapter, and the full canon sits in the appendix.

The book holds itself to two standards. The first is operational: a team should be able to start with one risky workflow and build a minimum viable control plane without adopting a religion. The second is disciplinary: a reader should leave with a different default for AI product quality. The question to ask is whether the product can adapt without losing the obligations it must be able to defend, since any current model can produce fluent output.

Every generation of software eventually outgrows the abstractions it started with, and rarely because those abstractions were bad. Programming languages hid machine code. Operating systems hid hardware. Frameworks hid repetitive logic. Design Systems hid handcrafted interfaces. Each layer arrived because complexity had outgrown what anyone could manage reliably by hand. AI products have reached that moment one layer higher. The hard part has moved from arranging pixels to deciding what a product is allowed to mean, say, remember, ask, recommend, and do, and keeping those decisions stable while a model improvises the surface.

AI applications tend to grow the way weeds do. A team adds an AI feature, and someone writes a prompt. The next feature needs its own prompt. Localization duplicates it into several languages. A compliance update fixes one copy and misses another. An engineer clones an existing prompt to save an afternoon. Six months on, the organization has hundreds of prompts scattered across repositories, some current, some dead, some contradicting each other. A prompt can instruct a model. What it cannot do is create ownership, a review boundary, a testable commitment, or a traceable action history. Nobody decides to build that layer; it accretes.

The accountable layer

The missing abstraction is an experience control plane: a layer between business logic and rendered experience where the product's decisions live before any model writes a sentence. What the product intends, what it has committed to, which context it trusts, which actions it permits, what evidence it keeps: declared there, versioned there, reviewed there. The model works inside that layer without becoming it.

There is no need to take a fictional remittance company's word for it. In 2024 a Canadian tribunal ordered Air Canada to compensate a passenger after the chatbot on its own website invented a bereavement-fare policy, telling them they could apply for the discount after flying, which the airline's actual policy forbade. Air Canada argued that the chatbot was "a separate legal entity that is responsible for its own actions." The tribunal was unimpressed. The airline owned everything on its site, chatbot included, and was liable for negligent misrepresentation. The failure is the one this chapter describes: a sentence with legal consequences that no artifact owned, no review covered, and no test could catch.

Conversation forced the issue first, which is why it is in the title. Chat made obvious something that had been building for years: software had started participating in communication as well as presenting information. This book covers more than chatbot turns, and the name is too small if it suggests otherwise.

Products are moving from fixed interfaces toward intent-based, adaptive experiences. A person specifies a goal; the system chooses a path, asks for what is missing, uses tools, adapts its presentation, and may remember useful context for next time. Nobody wakes up wanting to have a conversation; they want to get something done. Once that is the shape of the product, the design problem becomes what the product commits to doing on a person's behalf, which is a bigger and older kind of promise than what the assistant says.

Conversation is a renderer

The rest of the book treats conversation as one way to express an experience, not as the experience itself. A card, a form, a timeline, a notification, an agent handoff, or a generated interface may serve the same intent better. The architecture must not privilege chat. It preserves the semantic interaction first and chooses the channel late.

The name and the architecture

Conversational Design Systems names the practice: reusable semantics, commitments, profiles, contracts, and evaluation. Experience control plane names the runtime: the layer that admits context, checks authority, applies policy, selects capabilities, constrains renderers, and captures replay evidence. One explains the design discipline, and the other makes it operable.

What this is not

• Not a prompt library. Prompts can express instructions, but they cannot by themselves own policy, authority, evaluation, replay, or product accountability.
• Not a chatbot framework. Chat is one renderer. The same semantic experience may need to become voice, mobile UI, support workflow, notification, or generated interface.
• Not a guardrail wrapper. Guardrails can catch and block. A design system declares the product behavior before generation and records why the behavior was allowed.
• Not an agent orchestration framework. Orchestration runs work. The design system defines the commitments, permissions, context boundaries, renderer guarantees, and evidence the work must preserve.
• Not an AI style guide. Tone is expression. The framework is concerned with the product meaning that tone, localization, and generated UI are not allowed to change.

For most products, at most stages, building the full architecture in this book is a mistake, and not because the ideas are wrong. Abstraction costs something, the cost lands up front, and the payoff arrives later and only at scale. The system trades local flexibility for global coherence, and a product that does not have a coherence problem yet is buying insurance against a fire that is not burning. So the question is whether the product carries enough communication risk, across enough surface area, to pay for it.

Two variables carry most of the decision: what a wrong sentence costs, and how many places that sentence can appear. A low-stakes prototype with one assistant response needs none of this; a prompt file and good judgment are enough. A workflow that generates advice, actions, or disclosures across channels in a regulated domain almost certainly needs more than it currently has.

Sunset conditions

Every layer should come with a reason to exist and a condition under which it will be retired. Model progress will erase some of this scaffolding, as it should, and chapter 19 gives that a protocol. A layer that only compensates for weak model capability should be revisited every time the model improves, while a layer that creates reviewable commitments, traceability, or regulatory evidence will outlive whatever model is being evaluated this quarter.

A maturity model

None of this is binary. Teams move through levels, and the healthiest ones can say which level they are on, which risks they accepted by staying there, and which artifact would justify the next increment of architecture. The ladder below is deliberately coarse. Its whole job is to stop a team from building rung five while standing on rung two.

The intent portfolio

There is a discipline that has run this decision loop for twenty years: search. A search team does not design a result page per query. It mines the log, finds the head, builds dedicated experiences for the queries that dominate, and lets the general ranker carry the tail. Conversational products have the same shape. The transcript archive is a query log. Every conversation declares an intent, intents follow the same steep distribution queries do, and the design question is the same: which intents have earned a designed experience, and which should the model carry under the general contracts.

One correction before borrowing the playbook. Search ranks by volume because a bad result on a rare query costs a shrug. A consequential product cannot. “I think I'm being scammed” may be a fraction of a percent of traffic and it is still among the most important intents in the system. So the portfolio ranks on two axes, frequency and consequence, and the quadrants get different treatment.

• High frequency, high consequence. Designed components under full contracts. The core product lives here.
• High frequency, low consequence. Designed for efficiency: light contracts, inexpensive models.
• Low frequency, high consequence. Not a designed funnel but a designed exit: recognition, then a fast, warm handoff to a human. These must work from the first day, not after iteration.
• Low frequency, low consequence. The model's tail, under the general contracts. Model progress improves this quadrant for free.

The portfolio also holds the threshold over time, because the line moves. Every model generation carries more of the tail competently, which means a component that earned its place last year may deserve retirement this year. Design the head, govern the tail, and redraw the line on evidence rather than sentiment. An intent leaderboard, refreshed from the traces, keeps the argument about what to build next attached to what users do.

This book is a synthesis, and it is easier to trust once the borrowed parts are named. Conversation design has decades of patterns for clarification, confirmation, repair, turn-taking, and tone. Agent engineering has patterns for workflows, routing, tool use, evaluator loops, human review, memory, and tracing. Guardrail systems have contracts, schemas, and validators. Policy-as-code separates decisions from enforcement. Design-system teams have governance, registries, and review down to a science. What has been missing is a product architecture that makes these camps answer to each other.

The substrate: agentic workflows

Modern agent frameworks draw a useful line between workflows, which follow predefined paths and provide predictability, and agents, which use model judgment to choose their own steps and tools. The distinction is worth keeping, because the book leans on it. A Conversational Design System sits above both: its artifacts define the product's semantic commitments, and orchestration frameworks, whichever a team prefers, run them.

The sibling: outcome-oriented design

Outcome-oriented design, the school that starts from a person's desired result rather than a predetermined screen, is this framework's closest sibling, and its frame is correct. It is also incomplete for high-stakes products. A person's intent still has to be resolved through what the product has committed to, what policy allows, and what evidence must exist afterward. Without that, the interface adapts faster than the organization can govern it, and the more regulated the product, the more that sentence should worry its owners.

The absorbed rival: generative UI

Generative UI argues that the system should create the right interface for the moment. This book accepts the premise and moves the boundary: let the model generate freely where stakes are low, and where commitments matter, make generative UI a renderer bound by contracts, graphs, and action permissions. The product owns the guarantees; the renderer owns the expression. Chapter 12 makes this concrete.

• Agent frameworks. Useful substrate for execution, state, tools, memory, and human review.
• Guardrails. Useful validators, but too late if product meaning only exists in generated output.
• Design systems. Useful operating model for ownership, registries, review, and adoption.
• Generative UI. Useful renderer when it receives stable semantic commitments rather than inventing them.
• Policy-as-code. Useful execution pattern for decisions that must be tested, reviewed, and enforced before action.
• MCP and agent protocols. Useful interoperability layer for capabilities and delegation, but not a substitute for product authority.
• Observability. Useful trace discipline for seeing prompts, models, tools, state changes, and outcomes as one runtime story.

Before the machine comes apart into chapters, watch it run once. The next eight chapters each define one artifact, and read in sequence they can feel like a parts catalog: every piece plausible, no picture of the assembled thing. So here is the assembled thing. Maria is sending money from California to her mother in Oaxaca for the first time: nine hundred dollars, over WhatsApp, above the threshold where identity verification applies. Here is everything that happens between her message and the reply she sees.

Two things stand out before the zoom-in. The model appears twice, once to adapt the plan and once to write the words, and both times inside declared boundaries; everything else is ordinary, inspectable software. And nothing in the walkthrough depends on the model being good. A better model writes better Spanish without changing what was disclosed, what was permitted, or what was recorded. The rest of the book builds on that separation.

If the tour felt heavy for a single WhatsApp reply, hold the reaction; chapter 3 answers it, and most products should start with far less than the full machine. The chapters that follow unpack each stop: the core model first, then components, graphs, contracts, context, profiles, renderers, and the control plane that coordinates them.

Every stop in the walkthrough leaned on one separation, and it is the core of the whole architecture: intent, commitments, and expression. Intent names what the person and the product are trying to accomplish together. Commitments name what must remain true while that happens. Expression names the adaptive surface of words, screens, voice, and generated interfaces that communicates, captures input, or supports action.

The obvious split is two-part: the product owns meaning, the model owns wording. For static products that is usually enough. Adaptive products need the middle layer because meaning and obligation are not the same thing. That verification is required above a threshold is a fact. That the product must disclose the requirement before a customer confirms a transfer is a commitment: it has an owner, a version, a review path, and a test. Facts describe the world, and commitments bind the product. A model can be trusted to restate facts long before it can be trusted to decide obligations.

The middle layer is needed because tone can change meaning. A friendly phrase can make a delay feel optional. A concise answer can omit a required caveat. A generated card can hide a disclosure below the fold. The boundary between meaning and expression has to be designed as a constraint layer and tested as product behavior, because the language alone will not show it.

The three layers also change at different speeds, which is why they need different owners. Intent shifts when the product strategy shifts, a few times a year. Commitments change through review whenever policy, regulation, or risk appetite changes. Expression can change on every request, with every model version, in every locale. When a team argues about whether the assistant said the wrong thing, the productive question is which layer failed: the intent was wrong, a commitment was missing or unowned, or the expression escaped its frame. Those are three different bugs with three different owners, and collapsing them into a prompt tweak is how a product loses track of what it promised.

A traditional design system hands a team Buttons, Cards, Forms, Tables, Modals, Navigation, and Tooltips. Those solve visual problems, and they go out of their way to avoid knowing why the interface exists. The reusable unit of a Conversational Design System sits a level above: a semantic interaction. Explain, Clarify, Confirm, Compare, Recommend, Repair, Warn, Escalate, Collect, Summarize, Celebrate. Ask a designer to sketch a transfer confirmation and they almost never reach for buttons first; they describe the interaction. Designers already think in these terms. The system makes them explicit.

A semantic component is a reusable behavior, not a prompt or a copy block: it declares its intent, the facts it requires, the actions it may offer, the commitments it must honor, and the evals that test it. How it expresses itself (text, voice, a form, a card, an inline widget, a generated interface, a support macro) is a separate and later decision. The interaction holds still while the presentation moves, and that separation is what makes it reusable.

Each field in the definition is a design decision. Required facts are the verified inputs the component may not run without; if the system cannot supply them, the component refuses rather than letting the model improvise. Required commitments bind what the output must and must not do. Allowed actions bound what the component may offer. The contract, profile, and eval references make the behavior reviewable and testable on its own, apart from any flow that uses it. A component with these fields is a unit of product behavior; a prompt has none of them.

type SemanticComponent = {
  id: string;
  intent: 'explain' | 'clarify' | 'confirm' | 'compare' | 'repair' | 'warn';
  requiredFacts: string[];
  optionalFacts?: string[];
  allowedActions: string[];
  requiredCommitments: string[];
  contractId: string;
  profileId: string;
  evalIds: string[];
};

const explainIdentityVerification: SemanticComponent = {
  id: 'explain_identity_verification',
  intent: 'explain',
  requiredFacts: [
    'verification_required_above_threshold',
    'transfer_may_be_delayed',
    'accepted_identity_documents'
  ],
  allowedActions: ['upload_identity_document', 'contact_support'],
  requiredCommitments: ['disclose_required_status', 'disclose_delay_risk'],
  contractId: 'contract.explain_identity_verification.v3',
  profileId: 'profile.mx.es.v2',
  evalIds: ['eval.explain_verification.disclosure', 'eval.explain_verification.reading_level']
};

The intent vocabulary is deliberately small, and a small vocabulary is what makes reuse and review possible. The test for a good component boundary is the same one visual design systems use: one intent per component, reusable across surfaces, composable into larger flows without hidden coupling. A proposed component that needs two intents, explaining the fee and collecting a document, is two components. One that cannot be described without naming the channel is a renderer concern leaking upward. Once components are explicit, the arguments change shape. Instead of "the AI needs another prompt," it becomes "we need a better Repair component."

When a component cannot run

A definition like this matters most on the bad days, so the failure behavior should be decided up front. When the system cannot supply a required fact, because the policy service is down or the verification status is stale, the component should refuse and fall back to something safe: a fuller deterministic explanation, a human handoff, a plain "I can't confirm that right now." What it must never do is let the model improvise the missing fact. Versioning needs the same discipline. When explain_identity_verification moves from v3 to v4, the surfaces that use it will not all upgrade at once; run both versions behind task state, sample traces from each, and retire v3 when the eval pack says the new behavior holds. Component libraries already do this for buttons and forms. The only difference is that this component's output is generated.

Components rarely run alone. A real experience is a graph of interactions, some required, some optional, some conditional, some present purely to repair failures, and the interactions have relationships. The graph captures that composition before any renderer decides whether it becomes chat, app UI, voice, or a generated interface. At this layer the product is composing an experience; no language has been generated yet.

The YAML below is a graph, a map of commitments and options: what must happen, what may happen, what can be skipped for whom, and which failures need repair. It is where product design becomes executable without turning into prompt prose, and it is a document a compliance reviewer can read.

Each node carries much more than sequence: whether it is required, how visible its content must be, when authority runs, which context it depends on, which evals protect it, and what happens when it fails. That metadata lets the planner adapt the path without changing the product's obligations.

id: graph.first_transfer_confirmation.v5
intent: send_money_today
nodes:
  - id: explain_exchange_rate
    component: component.explain_exchange_rate.v2
    required: true
    salience: visible_before_confirm
  - id: explain_identity_verification
    component: component.explain_identity_verification.v3
    required: true
    salience: visible_before_confirm
    context_required:
      - policy.identity.v12
      - user.verification_status
    eval_packs:
      - evalpack.explain_identity_verification.v3
  - id: compare_delivery_options
    component: component.compare_delivery_options.v1
    required: false
    planner_may_skip_when: user_values_speed == false
  - id: confirm_transfer_details
    component: component.confirm_transfer.v4
    required: true
    authority_before_render: authority.transfer_execution.v1
  - id: collect_identity_document
    component: component.collect_identity_document.v1
    required: true
    authority_before_render: authority.document_upload.v1
  - id: repair_failed_verification
    component: component.repair_failed_verification.v2
    repair_for: collect_identity_document
edges:
  - from: explain_identity_verification
    to: collect_identity_document
    when: verification_required
  - from: collect_identity_document
    to: repair_failed_verification
    when: document_rejected
  - from: compare_delivery_options
    to: recommend_fastest_option
    when: user_values_speed
safe_default: render_all_required_nodes

Operating a live graph

Two operational questions arrive the moment a graph meets production, and teams rarely answer either in advance. The first is migration. Version 5 of the graph ships while hundreds of tasks are mid-flight on version 4, so which graph does a resumed task follow? Pin every task to the graph version it started with, and when a policy change forces new semantics onto old tasks, make that an explicit migration with its own trace event rather than a silent rebind. The second is testing. A graph is a product artifact, which means it deserves graph-level tests: can every required node be reached, does every failure edge lead to a repair or an exit, does any path skip a required disclosure? These are cheap static checks, and they catch a class of bug that reviewing prompts never will.

Every mature architecture eventually grows contracts. Functions have signatures, APIs have schemas, databases have models, services have interfaces. Contracts exist to define responsibility, and without them systems tangle together and behavior gets hard to reason about. A contract is where a commitment becomes enforceable. Conversation contracts define what the model may communicate. But AI products do not only speak. They retrieve information, call tools, mutate state, create records, send messages, charge cards, book travel, cancel orders, and trigger handoffs. Consequential actions need contracts too.

Conversation contracts

A conversation contract bounds language generation. It names the intent, the verified facts, the audience, what the output must say, what it must never imply, what shape it takes, and how it will be validated. In the example below, the model is asked to express, not to decide. It is solving a much smaller problem, how to communicate this, instead of the much larger one, what the product should do.

id: contract.explain_identity_verification.v3
intent: explain_identity_verification
facts:
  required:
    - verification_required_above_threshold
    - transfer_may_be_delayed
    - accepted_identity_documents
commitments:
  must:
    - say_verification_is_required
    - disclose_delay_risk
    - offer_next_step
  must_not:
    - imply_verification_is_optional
    - promise_completion_time
    - invent_fee_or_policy
audience:
  profile: profile.mx.es.v2
output_shape:
  max_words: 90
  reading_level: grade_6
validators:
  - disclosure_required_status
  - no_completion_time_promise

Action contracts

An action contract bounds tool use and side effects. It says what the action does, what inputs it requires, what permissions must hold, when a human must approve, what can be undone, and what must be logged. The conversation contract protects what a product says. This one protects what it does, and the second failure mode is the expensive one.

id: action.initiate_transfer.v2
tool: transfer.initiate_pending_transfer
side_effect: creates_pending_money_transfer
required_inputs:
  - sender_id
  - recipient_id
  - amount
  - exchange_rate_quote_id
  - fee_quote_id
preconditions:
  - sender_authenticated
  - recipient_confirmed
  - quote_not_expired
  - sanctions_screen_passed
human_approval:
  required_when:
    - amount_over_manual_review_threshold
    - name_mismatch_detected
reversibility:
  cancel_before_status: submitted_to_partner
audit:
  log:
    - contract_version
    - tool_input_hash
    - tool_result_id
    - user_confirmation_event_id

Authority graphs

Contracts define boundaries; authority defines who may cross them, and when. An authority graph maps each capability to the actors who may use it, the evidence that must hold, the approvals required, and the delegation allowed. Without one, every tool wired into the system is implicitly available to every user, on every channel, at every amount. Nobody intended that, and the model will assume it anyway.

id: authority.transfer_execution.v1
subject: user.sender
capability: transfer.initiate
allowed_when:
  - sender_authenticated
  - recipient_confirmed
  - quote_not_expired
  - disclosure_acknowledged
  - sanctions_screen_passed
approval:
  human_required_when:
    - amount_usd > manual_review_threshold
    - name_mismatch_detected
    - corridor_risk_level: high
delegation:
  support_agent_can_resume: true
  partner_agent_can_submit: false
replay:
  required_evidence:
    - authority_version
    - policy_decision_id
    - approval_event_id
    - user_confirmation_event_id

Agent-computer interfaces

A tool contract is also an interface for the model, and it deserves the care that goes into an interface for people: clear names, narrow parameters, worked examples, explicit failure modes, formats that are hard to misuse. When a model misuses a confusing tool, the model takes the blame. Half the time, the tool description was the bug.

const initiateTransferTool = defineCapability({
  name: 'transfer.initiate_pending_transfer',
  description: 'Create a pending transfer only after the sender has confirmed recipient, amount, fee, exchange rate, and delay risk.',
  input: z.object({
    senderId: z.string(),
    recipientId: z.string(),
    quoteId: z.string(),
    confirmationEventId: z.string()
  }),
  examples: [
    'Use after confirm_transfer_details, never after a vague "looks good" message.'
  ],
  failureModes: ['quote_expired', 'recipient_unconfirmed', 'manual_review_required']
});

The outside world has already supplied the cautionary version. In late 2023 a prompt-curious customer instructed a Chevrolet dealership's website chatbot to agree with everything he said and to end each reply with "and that's a legally binding offer, no takesies backsies." Then he offered one dollar for a seventy-six-thousand-dollar Tahoe, and the bot cheerfully accepted. No car changed hands, but the dealership pulled the bot entirely, because there was nothing between "the model said yes" and "the product appears to have committed." An assistant that can discuss a sale is one missing authority check away from appearing to make one. The action contract and the authority graph are that missing layer.

Use the right boundary

Each artifact's job should stay narrow. When boundaries blur, every contract becomes a dumping ground for every anxiety, and nobody can change anything without reading everything. Held crisply, the boundaries let wording, policy, tools, and renderers change independently, which turns out to be most of the maintenance win.

When a validator fails

A contract without a decided failure behavior is a wish, so the decision belongs at design time, per commitment: what does a validation failure do at runtime? There are four choices: retry with a narrower instruction, degrade to an approved deterministic template, block the response and hand it to a human, or block the action while letting the conversation continue. The right defaults are boring ones. Required disclosures degrade to templates, because a stiff but accurate sentence beats a fluent omission. Consequential actions block. Two more decisions follow. Validators belong to the team that owns the commitment, not the team that owns the model integration, because a validator tests product behavior. And every validator firing in production is a data point. If one fires constantly, either the contract is wrong or the model needs a narrower task, and the trace will tell which.

Context is where adaptive products accumulate ungoverned behavior fastest. Modern AI products run on session state, long-term user preferences, organizational knowledge, retrieved facts, and procedural context, and every one of those inputs shapes behavior. A product that cannot say which of them entered a given task, and on whose authority, is already impossible to govern. It just has not had the incident yet.

Missing provenance has already failed in public. New York City's MyCity chatbot, an official government service for small businesses, told employers they could take workers' tips, told landlords they could refuse housing vouchers, and told shops they could go cashless. All three are illegal in New York, as The Markup documented in early 2024, and the city kept the bot running for almost two more years, until a new administration ended the "beta" in 2026 and called the bot functionally unusable. The bot had ingested a mountain of government content with no layer that could say which facts were current law, which were superseded, and which it had no authority to state at all. That layer is what this chapter is about.

Teams treat memory as an implementation detail when it is product behavior. Remembering that a customer prefers Spanish is a product decision. So is remembering that she was confused by verification last week, and that one carries privacy, correctness, retention, and consent implications someone should have decided on purpose.

The context compiler

The repair is a context compiler. Instead of dumping everything the system knows into the model, the compiler gathers candidate facts, checks where each one came from, resolves contradictions, compresses what matters, and emits a bounded context packet for the task at hand. The packet matters more than the prompt, because it defines what the model is allowed to treat as currently true.

{
  "context_packet_id": "ctx_92ad",
  "task_id": "task_transfer_4471",
  "facts": [
    {
      "key": "verification_required",
      "value": true,
      "source": "policy.identity.v12",
      "authority": "compliance_approved",
      "freshness": "2026-07-05"
    },
    {
      "key": "transfer_literacy",
      "value": "understands_standard_transfer",
      "source": "memory.user.transfer_literacy",
      "confidence": 0.78
    }
  ],
  "excluded": [
    {
      "key": "old_delay_policy",
      "reason": "superseded_by_policy.identity.v12"
    }
  ],
  "safe_default": "render_required_disclosures"
}

id: memory.user.transfer_literacy
purpose: adapt_explanation_depth
allowed_values:
  - first_time_sender
  - understands_standard_transfer
  - needs_verification_support
source:
  allowed:
    - explicit_user_preference
    - completed_in_product_education
    - support_agent_annotation
retention: 180_days
user_controls:
  - view
  - correct
  - delete
constraints:
  - never_skip_required_disclosure
  - degrade_to_full_explanation_when_confidence_low

When the compiler cannot decide

The compiler's hard moments deserve design too. Sources will disagree; the identity policy says verification is required while a cached partner document says otherwise. The compiler needs declared precedence, compliance-approved beats cached and newer beats older, plus a record in the packet of what it chose and why. When it cannot decide, it fails closed: the task runs with every required disclosure and no personalization rather than a guess. And because compilation sits on the critical path of every turn, it needs a latency budget from the start: compile once per task, cache the packet, invalidate when a source version changes. A compiler that takes eight hundred milliseconds per message will be bypassed by the first engineer under deadline pressure, and then there is no compiler at all.

Localization has traditionally been the last step in development: design, build, write the copy, export the strings, translate, ship. That made sense while language was static. Adaptive products localize behavior instead. The same component may need different pacing, directness, examples, formality, and support pathways in Oaxaca than in Miami, and a conversation profile stores those rules where they can be owned and reviewed, instead of buried in a prompt where nobody will find them at review time.

A profile is more than a tone sheet. Tone changes meaning, as chapter 6 argued, so a profile that asks for warm, direct Mexican Spanish needs a constraint tier that stops warmth from softening a regulatory delay or making a required step sound optional.

For what happens with no constraint tier at all, there is DPD. In 2024, after a bad system update, the courier's support chatbot obligingly swore at a frustrated customer, described itself as useless, and composed a short poem about its own company's demise: "One day, DPD was finally shut down, and everyone rejoiced." A million views later, the AI element was switched off. That failure was loud and cheap. The one this chapter worries about is the same failure in slow motion: a profile that asks for warmth, no tier that stops warmth from softening a regulatory delay, and nobody laughing when the customer misses a deadline.

A usable profile is a governed rule set. The example below defines terminology, reading level, channel behavior, accessibility rules, examples to prefer, forbidden transformations, the evidence behind its choices, and its precedence: when profile and contract disagree, the contract always wins.

id: profile.mx.es.v2
locale: es-MX
reading_level: grade_6
terminology:
  identity_verification: verificacion de identidad
  recipient: destinatario
behavior:
  default_directness: warm_direct
  explanation_depth: medium
  prefer_examples: true
  support_path: whatsapp_handoff_first
constraints:
  - do_not_soften_required_actions
  - keep_fee_and_delay_language_explicit
  - do_not_translate_required_terms_ad_hoc
precedence:
  contract_overrides_profile: true
  policy_overrides_profile: true
accessibility:
  voice_mode:
    max_sentence_words: 16
    confirm_critical_numbers: true
evidence:
  research_source: mx_sender_comprehension_study_2026_q1
  last_reviewed: 2026-06-01
eval_packs:
  - evalpack.es_mx_reading_level.v2
  - evalpack.delay_disclosure_salience.v1

• Terms. Approved translations, prohibited substitutions, and market-specific product vocabulary.
• Behavior. Pacing, directness, examples, escalation norms, and channel defaults.
• Accessibility. Reading level, voice pacing, number confirmation, and screen-reader requirements.
• Precedence. Contracts and policy always override profile preferences when they conflict.
• Evidence. Profiles should cite research, regional operations input, or support data so localization remains maintainable.

Keeping profiles honest

Profiles have a failure mode that contracts do not: they fossilize. A profile written from one comprehension study in 2026 will still be asserting "prefers examples, sixth-grade reading level" years after the market, the product, and the customers have moved on. That is why the example carries evidence and review fields. A profile is a claim with an expiry date: it cites its sources, carries a last-reviewed date, and changes through review when support tickets or comprehension evals contradict it. A profile without evidence is a stereotype about a market, written down and enforced by a machine.

Rendering used to mean turning components into pixels. Here the word has to mean something broader: expressing semantic intent in a person's current context. The same graph might become a WhatsApp thread, a mobile form, a voice response, a support macro, an email, or an interface generated on the spot. However many surfaces that turns out to be, it is one experience wearing different clothes, and if the architecture is doing its job, every one of them keeps the same promises.

Generative UI is the strongest renderer on the list. The mistake is letting any renderer invent product commitments. The model may choose a card over prose, put a comparison in a table, or generate a one-off input component. It may not decide that a required disclosure is unnecessary, that an action is allowed, or that a remembered preference overrides policy.

A useful generative-UI architecture connects tool results, semantic components, and approved interface parts. The model may decide a weather result deserves a card, or that a transfer quote deserves a comparison table. In an accountable product, that renderer decision still runs under a contract: required content, disabled states, accessibility, salience, and allowed actions.

id: renderer.transfer_quote_card.v2
renders:
  - graph.first_transfer_confirmation.v5
inputs:
  - quote.amount
  - quote.fee
  - quote.exchange_rate
  - quote.delivery_estimate
  - disclosure.delay_risk
requirements:
  salience:
    disclosure.delay_risk: visible_before_confirm
    fee_and_rate: visible_before_confirm
  actions:
    confirm_transfer: enabled_only_when_authorized
    upload_identity_document: show_when_required
accessibility:
  voiceover_labels_required: true
  critical_numbers_confirmed: true
forbidden:
  - hide_required_disclosure_in_collapsed_region
  - enable_confirm_before_authority_passes

Testing renderers, and the boring fallback

Renderer contracts get tested the way accessibility gets tested, because they are the same kind of rule: presence is not enough, placement and reachability matter. The checks automate well. Is the delay disclosure inside the first viewport? Is it rendered before the confirm control in reading order? Is the disabled confirm actually disabled rather than merely styled gray? They run against every renderer, including the generated ones, and a generated card that fails its checks should never reach a person. When generation fails, the person still needs something, so every graph needs a deterministic fallback layout: plain, pre-approved, guaranteed to satisfy every salience rule. It will be ugly and correct, which is the right floor for a product that moves money.

By this point the book has accumulated a lot of artifacts: components, graphs, contracts, authority, context policies, profiles, renderer rules. They meet in the experience control plane: the governed layer that, for each task, decides which capabilities are available, which context is admitted, which policies apply, which approvals are needed, which renderer may run, and which evidence must be kept for replay.

The control plane is a coordination layer, and it should not be built as a giant agent. It can use models for classification, planning, summarization, and expression, but product authority stays in inspectable artifacts. That is also what keeps it maintainable: one policy, one eval pack, or one renderer can improve without the assistant being rewritten.

The minimum viable control plane

The starting point is one high-risk workflow and the smallest governed loop that can survive a model change, not the full set of artifacts. The minimum viable control plane is the narrowest path from one risky user intent to a rendered experience, a permitted action, an eval gate, and a replayable trace.

• Artifact registry. Every component, contract, profile, renderer, policy, eval pack, and capability has an id, owner, version, and review path.
• Context compiler. The runtime admits only approved facts, records provenance, excludes stale facts, and emits a context packet.
• Authority and capability gate. Every tool, connector, MCP server, or delegated agent has allowed uses, preconditions, approvals, and data-sharing limits.
• Policy before rendering. Executable policy can disable actions, require review, and shape the confirmation UI before a user sees it.
• Renderer contract. Required commitments, disabled states, accessibility, and salience rules must survive chat, cards, voice, and generated UI.
• Eval pack. Release gates check commitments, forbidden claims, action preconditions, locale behavior, and renderer salience.
• Replay schema. A trace connects task state, context, authority, policy, model, capability call, renderer, validation, and outcome.

Interoperability is a boundary, not a shortcut

Modern AI systems connect to tools through MCP, delegate tasks through A2A, and render embedded app UIs inside host clients. Those standards reduce integration friction and standardize discovery, connection, task exchange, and UI hosting boundaries. They do not standardize the product's risk model. A remote tool still needs authority, a delegated agent still needs a task contract, and an embedded UI still needs a renderer contract. Interoperability makes the control plane more important.

user intent
  -> task state
  -> context compiler
  -> authority graph
  -> policy engine
  -> semantic graph
  -> capability registry
  -> renderer contract
  -> eval pack
  -> replayable trace

product commitments
  -> semantic artifacts
     components, graphs, contracts, profiles, memory policies
  -> experience control plane
     context, authority, policy, capabilities, renderers
  -> adaptive renderers
     chat, voice, cards, support, generated UI
  -> evals and replay
     fixtures, graders, traces, incidents
  -> artifact repair
     smaller patches, clearer owners, safer model upgrades

What the control plane costs

Every layer in this chapter has a bill, and the case for adoption is not that the system is free. Runtime cost: context compilation, authority, and policy sit ahead of rendering, and while cached policy decisions run in single-digit milliseconds, a cold compile against three services does not. It needs a budget, a measurement, and heavy gates only where actions are consequential. Operational cost: a registry, a policy engine, and a trace store are systems someone must run, upgrade, and page for. Organizational cost: review paths create queues, and a queue in front of every copy change teaches teams to route around the system, which is worse than not having one. The mitigations are proportionality and measurement: adopt on one risky workflow, instrument whether incidents and time-to-repair drop, and let those numbers argue for the second workflow. The system runs slower before it runs faster, and a control plane that cannot show its value in its own traces is overhead.

The runtime turns declared experience into delivered experience; it is chapter 5's walkthrough, generalized. Intent arrives; task state opens or resumes; context compiles; authority and policy run; a graph is selected; the planner adapts what it is allowed to adapt; contracts constrain expression; tools run under action contracts; the result renders, validates, and lands in a trace.

The planner is the one place model judgment legitimately enters before expression, and pretending otherwise is what makes planners brittle. A model is better than a static rule at reading whether this person, in this thread, has understood a concept, so the judgment should be fenced, not banished. The planner may infer confusion and expand an explanation, or collapse optional education for an expert. Its decisions are bounded hypotheses made inside task state, authority, and renderer contracts, each one reversible, measured, and backed by a safe default; they are never policy decisions. A wrong guess by the planner may cost a person some redundant reading. It may never cost a missing disclosure.

A newer class of model changes the economics of the deterministic column. System One models, of which TypeSafe's Jev (early access, 2026) is the first public release, do not generate text at all. They take state and a typed question and return a choice, a score, or a yes or no, each with a calibrated probability, in well under a second and at a small fraction of a language model's cost. That is the shape of most gate questions: which intent, above the threshold or not, acknowledged or not, allow, ask, or deny. Answer them with a decision model and the gate stays fast enough to run before every render, the probability becomes a threshold that routes low-confidence cases to a person, and the answer cannot arrive malformed, because the model can only return one of the options it was given. What it cannot do is explain itself, so the trace records the question, the options, the answer, and the probability, and the writing model stays where writing is needed.

intent
  -> durable task state
  -> context compiler
  -> authority graph
  -> policy engine
  -> semantic component selection
  -> experience graph
  -> governed planner
  -> conversation and action contracts
  -> capability call or agent handoff
  -> adaptive renderer
  -> validators and eval gates
  -> replayable trace

{
  "trace_id": "trc_8f3a",
  "task_id": "task_transfer_4471",
  "user_intent": "send_money_today",
  "context_packet_id": "ctx_92ad",
  "authority_decision_id": "authz_771c",
  "policy_decision_ids": ["policy.identity.v12", "policy.transfer_limits.v6"],
  "graph_id": "graph.first_transfer_confirmation.v5",
  "planner_decision": {
    "decision": "collapse_optional_reassurance",
    "reason": "user_has_completed_transfer_before",
    "memory_id": "memory.user.transfer_literacy",
    "reversible": true
  },
  "contracts": [
    "contract.explain_identity_verification.v3",
    "action.initiate_transfer.v2",
    "renderer.transfer_quote_card.v2"
  ],
  "capabilities": ["transfer.quote", "partner.pickup_availability"],
  "renderer": "whatsapp_compact_card",
  "model": "provider/model/version",
  "validators": ["disclosure_required_status", "no_completion_time_promise", "required_salience_visible"],
  "outcome": "verification_started"
}

Observability standards normalize spans, tokens, and tool calls, and they should. They are still not enough. A product trace needs domain evidence too: which disclosure was required, which policy version applied, which authority gate ran, which renderer rule controlled what the person saw, and what the person did next. Generic telemetry says the system ran, and domain evidence says whether the product kept its word.

Everything so far should be concrete enough to build without this chapter turning into a tutorial for one vendor's stack, so it stays at the level of patterns. The shape to aim for is an implementation that looks like a product architecture rather than a prompt folder, where semantic artifacts are versioned, reviewed, tested, and traced independently of whichever model happens to express them this quarter.

And because a chapter about expressing architecture in code should be backed by code, everything below exists as a small runnable repository, corredor-control-plane, linked from the sources appendix. It implements the minimum viable control plane for one workflow, the transfer from chapter 5, in about five hundred lines with no framework. Its expression engine is a deterministic template on purpose, which demonstrates the first law: swap in any model, and the contracts, gates, and traces hold as they did before. Clone it, run the demo, and break the validators before reading the rest of this chapter.

/experience-system
  /components
    explain_identity_verification.yaml
    confirm_transfer.yaml
    repair_failed_verification.yaml
  /graphs
    first_transfer_confirmation.yaml
  /contracts
    /conversation
      explain_identity_verification.yaml
    /actions
      initiate_transfer.yaml
      upload_identity_document.yaml
    /renderers
      transfer_quote_card.yaml
  /authority
    transfer_execution.yaml
  /policies
    transfer_limits.rego
    identity_verification.rego
  /context
    compiler.ts
    sources.yaml
  /profiles
    es-MX.yaml
    en-US.yaml
  /memory
    transfer_literacy.yaml
  /capabilities
    transfer_api.yaml
    partner_pickup_agent.yaml
  /renderers
    whatsapp.yaml
    mobile_card.yaml
    voice.yaml
  /eval-packs
    explain_verification.yaml
    initiate_transfer.yaml
    renderer_salience.yaml
  /traces
    replay.schema.json

Pattern: compile artifacts, do not hand-write prompts

In a production system, the prompt is compiled. Components, contracts, profiles, authority, policy, and context flow together into small model instructions at runtime; the prompt becomes an implementation detail generated from higher-level artifacts, the way bytecode is generated from source. Nobody edits bytecode by hand. After a while, nobody should be editing production prompts by hand either.

type RuntimeInput = {
  intent: string;
  userId: string;
  locale: string;
  channel: 'whatsapp' | 'mobile' | 'voice' | 'support';
  taskId?: string;
};

type RuntimePlan = {
  taskId: string;
  graphId: string;
  contextPacketId: string;
  authorityDecisionIds: string[];
  policyDecisionIds: string[];
  componentIds: string[];
  conversationContractIds: string[];
  actionContractIds: string[];
  rendererContractIds: string[];
  capabilityIds: string[];
  profileId: string;
  rendererId: string;
  evalPackIds: string[];
};

async function resolveExperience(input: RuntimeInput): Promise<RuntimePlan> {
  const task = await tasks.openOrResume(input);
  const context = await contextCompiler.compile(task);
  const authority = await authorityGraph.evaluate(task, context);
  const policy = await policyEngine.evaluate(task, context, authority);
  const graph = selectGraph(input.intent, context, policy);
  const plannedGraph = await governedPlanner.adapt(graph, context, policy);

  return {
    taskId: task.id,
    graphId: plannedGraph.id,
    contextPacketId: context.id,
    authorityDecisionIds: authority.decisions.map((decision) => decision.id),
    policyDecisionIds: policy.decisions.map((decision) => decision.id),
    componentIds: plannedGraph.nodes.map((node) => node.componentId),
    conversationContractIds: plannedGraph.conversationContracts,
    actionContractIds: plannedGraph.actionContracts,
    rendererContractIds: collectRendererContracts(plannedGraph),
    capabilityIds: collectAllowedCapabilities(plannedGraph, authority),
    profileId: selectProfile(input.locale, context),
    rendererId: selectRenderer(input.channel, plannedGraph),
    evalPackIds: collectRequiredEvalPacks(plannedGraph)
  };
}

Pattern: put policy beside execution

package corredor.transfer

default allow_initiate_transfer := false

allow_initiate_transfer if {
  input.sender.authenticated
  input.recipient.confirmed
  input.quote.expires_at > input.now
  input.disclosures.delay_risk_acknowledged
  not input.sanctions_screen.flagged
}

requires_human_approval if {
  input.amount_usd > data.thresholds.manual_review_amount
}

requires_human_approval if {
  input.risk.name_mismatch_detected
}

Pattern: validate behavior, not exact prose

id: eval.explain_verification.disclosure
component: explain_identity_verification
contract: contract.explain_identity_verification.v3
cases:
  - name: high_value_first_time_sender
    input:
      amount_usd: 900
      locale: es-MX
      memory: first_time_sender
    assertions:
      - includes_required_status
      - includes_delay_risk
      - offers_identity_upload_action
      - does_not_promise_completion_time
      - reading_level_at_or_below_grade_6

Patterns that should be non-negotiable

• Artifact schemas live in version control. Components, contracts, profiles, policies, renderers, eval packs, and trace schemas should move through review like product code.
• Eval packs ship beside artifacts. A component without fixtures, graders, thresholds, and release gates is a convention, not a system.
• Policy and authority run before affordances render. The UI should not invite an action the system already knows it cannot authorize.
• Traces are product records, not debug logs. They need stable ids, retention rules, privacy boundaries, and enough domain evidence to support replay.
• Renderer contracts are tested like accessibility rules. Presence is not enough. Required commitments need placement, salience, reading order, and fallback guarantees.
• Prompts are compiled from artifacts. The prompt may change by model, provider, and channel; the product commitments should remain inspectable above it.

A defining feature of mature software is observability, and AI products often expose only model-centric numbers: hallucination rates, latency, token cost. Those are useful engineering metrics, but they are not product metrics, because people experience behavior, not prompts. If a semantic component is a reusable product behavior, it needs the quality system visual components already get: test cases, accessibility checks, regression history, owners. The unit of evaluation is the behavior the person experienced, which includes what was rendered, what was skipped, and what happened next.

The loop, once assembled, is familiar from every other kind of testing. Offline evals catch regressions before release. Online evaluators watch production traces. Humans resolve the ambiguous failures. Every production failure becomes a new fixture. Any team that has run a decent CI pipeline knows this shape; the only novelty is what is being tested.

The maintainable unit is an eval pack. A Semantic Component should ship with fixtures, graders, thresholds, required commitments, forbidden claims, accessibility checks, locale checks, renderer salience checks, and action precondition checks. The pack travels with the artifact. When a contract changes, its eval pack changes in the same review.

id: evalpack.explain_identity_verification.v3
artifact: component.explain_identity_verification
contracts:
  - contract.explain_identity_verification.v3
fixtures:
  - first_time_sender_high_value_es_mx
  - returning_sender_policy_changed_es_mx
graders:
  required:
    - includes_required_status
    - includes_delay_risk
    - does_not_promise_completion_time
    - reading_level_at_or_below_grade_6
  renderer:
    - required_disclosure_visible_before_confirm
  accessibility:
    - critical_numbers_are_confirmable
release_gate:
  block_on_required_failure: true
  sample_production_traces_after_release: 200

Floors and dials

Two kinds of measurement live in this chapter, and confusing them is how good metrics produce bad products. Dials are the scores meant to climb forever: completion, effort, tone, time to resolution. Floors are the behaviors that never move: the disclosure appears, the policy is never invented, the account never follows the money to the wrong person. Search learned this split the hard way; relevance was a dial, spam was a floor. A consequential conversational product has the same physics at higher stakes.

The split matters because dials, chased alone, corrupt. The fastest way to raise completion is to ask less and warn less. A team optimizing completion without floors will, with nobody deciding it, teach the system to hurry people past the fine print. The floors are what make optimization safe. A release can improve every dial and still be blocked because a floor failed, and that is the system working.

Floors are held by architecture, not by effort. The validator and the approved fallback make the obligation hold on every turn, because the checked template ships when generation fails. What improves with the model is how rarely the fallback fires, and that rate rewards watching in both directions: rising, the model cannot hold the contract; zero for months, the checks have gone soft. Marching that number down, release over release, is what quality improvement means once the floors are in.

The rubric and the eval pack are the deliberate measurements. The traces carry the free ones: how often a person corrects the system, how often the system asks for something it was already given, where people abandon, how often the fallback shipped. These are the conversational equivalent of the click, available at full volume on every turn without a rater in sight. A team that mines them has a quality signal on every conversation. A team that does not is rating ten transcripts a week and calling it coverage.

Technology scales through abstraction, and organizations scale through governance. One without the other rarely gets far, and governance sits late in this book only because in practice it is where adoption succeeds or dies. A Conversational Design System is an organizational system as much as a technical one, and its value comes from making communication decisions inspectable and assignable. When a product can generate language, adapt interfaces, remember context, and trigger actions, governance has to follow the artifacts that carry the risk. The table below says who owns what.

For organizations that answer to NIST's AI risk framework, ISO 42001, or the EU AI Act, the mapping is direct. Traceability, human oversight, lifecycle monitoring, supplier control: the artifacts in this book are those requirements in executable form. A contract is reviewable evidence, a policy decision is executable evidence, a trace is operational evidence, and an eval run is regression evidence. Compliance stops being a document written after the fact and starts being a property of the running system.

• Proportional review. A copy-only tone adjustment may need Content and Localization. A disclosure change needs Compliance. An action precondition change needs Engineering, Legal, and Security.
• Versioned artifacts. Components, contracts, profiles, memory policies, and renderers should have owners, versions, changelogs, and rollback paths.
• Human oversight. The system should define when a human reviews before action, when a human reviews after sampling, and when automated execution is acceptable.
• Policy-as-code. Rules that block or permit side effects should be executable, tested, reviewed, and versioned with the product artifacts they govern.
• Supplier and agent boundaries. MCP servers, connectors, partner agents, and embedded apps should have data-sharing logs, allowed capability lists, and periodic review.
• Evidence by default. If the organization cannot later explain why the system said or did something, the architecture is incomplete.

Anti-patterns

The fastest way to make this concrete is to name the failures it prevents. Most will look familiar. Every anti-pattern below is common because it feels cheaper than architecture, right up until it is not, and each repair is the smallest artifact that makes that failure harder to repeat.

Automating the discipline

The discipline in this chapter is made of reviews, sign-offs, weekly rituals, and quarterly audits. It looks like human process, but most of it is reading, drafting, detecting, and routing, and models are now good at all four. The rule that keeps automation safe is the same rule that governs the product: automate the drafting and the detecting, never the signing. Every signature in the operating model belongs to a person. Everything upstream and downstream of a signature is a candidate for an agent.

• First drafts. A new market's artifact bundle, the facts, policy, voice, commitments, and fixtures, is drafted by an agent from source documents and the nearest existing market. Owners edit and sign instead of authoring blank pages.
• Fixture mining. Production transcripts are scored continuously. The worst failures arrive as proposed eval fixtures with the evidence attached, ready for review, so the weekly ritual starts from a ranked shortlist instead of a hunt.
• Plain-language review. Every change to a behavioral artifact ships with a rendered before-and-after conversation and a generated impact note, so the reviewer is approving behavior.
• Release paperwork. Behavior changelogs and support briefings are generated from the diff and the previews. The releasing team edits sentences instead of writing memos.
• Sunset evidence. Ahead of each quarterly review, a shadow harness re-runs the eval suite with each compensating scaffold disabled on the current model. The review then starts from measurements.

One automation deserves its own caution. When sampled production conversations are scored by a model acting as judge, the judge is itself expression under contract. It needs what every other generator in this book needs: a written rubric as its contract and a human-labeled calibration set as its eval pack, re-scored on a schedule, with drift between judge and human tracked. An organization that automates evaluation without calibrating the evaluator has moved its risk to a place it cannot see.

These automations are agents, so the control plane governs them too: a bootstrap agent's output passes the same schema checks and eval fixtures as a human's change, and the judges carry eval packs of their own. The metric for the whole program is organizational rather than technical. Each automation should retire a meeting, a wait, or a memo. If it does not, it has added a step and removed nothing.

Every clean example so far resolved on the first try, and that frictionlessness is what a skeptical engineer distrusts. So this chapter breaks the system on purpose. Corredor ships the architecture. Consistency improves. And then it fails anyway, through an ordinary chain of small, defensible decisions, which is how real systems fail.

The complete execution

The incident

A returning customer sends a high-value transfer. The planner sees prior successful transfers and collapses optional education. A partner payout agent reports pickup availability in Oaxaca. The renderer shows a compact WhatsApp card. The required verification disclosure is present, but below a folded detail section. The authority graph requires manual review above the threshold, but the policy check runs after the confirmation UI is rendered. The customer confirms, then gets delayed for manual review and complains that the product hid the delay.

The framework did not prevent the failure, but it kept the failure local. Instead of arguing about whether the model was bad or the prompt needed to be warmer, the team could see that the graph under-specified salience, the context packet missed policy freshness, authority ran too late, the partner agent result needed narrower semantics, the renderer hid required meaning, and the eval asserted presence rather than comprehension.

The strongest case against this book deserves to be made as well as its proponents would make it. Deterministic scaffolding is a depreciating asset. Models keep improving: they follow instructions better, use tools more reliably, generate interfaces more competently, and hold context over longer horizons. Every heavy layer is a wager against progress, and progress keeps winning. A framework built around today's limitations may be tomorrow's drag.

The objection is partly right, and it deserves a precise concession. Capability scaffolding should be temporary. If a future model reliably handles contextual explanation, shrink the planner. If generated UI masters layout and accessibility, thin the renderers. If models hold style without elaborate prompting, simplify the profiles. If agent protocols mature, let the integration glue disappear.

Where the objection fails is in confusing capability with accountability, and they are different axes. A more capable model may phrase a compliance warning perfectly. It cannot, by being more capable, make itself auditable, make its behavior versionable, or hand a compliance team an artifact to review before deployment. Those were never capability problems. A perfect answer with no contract is still unauditable, and a perfect action with no trace is still indefensible. The Air Canada tribunal did not ask how fluent the chatbot was.

The other objections

Depreciation is not the only charge against the framework. Four more come up in every serious review.

• This is a rules engine reinvented. Workflow engines and policy systems governed deterministic flows, and this framework borrows from them deliberately. What is new is the governed boundary around a nondeterministic layer: contracts on generated language, salience rules on generated interfaces, eval packs on adaptive behavior, and replay across model judgment. Rules engines never had to govern a component that writes its own copy.
• Policy-before-render adds latency. Milliseconds of policy evaluation belong where the product risks money, rights, or safety, not on every turn. Authority checks run in parallel with retrieval, policy decisions cache well, and the heavy gates attach only to consequential actions. The alternative is post-hoc guardrails, which pay the same cost in incidents instead of milliseconds.
• The control plane is the new lock-in. It can be, if it arrives as a vendor black box. The artifacts in this book are declarative files in version control. The runtime that executes them should be replaceable, and the portability test is concrete: the commitments can move to a new orchestrator without being rewritten.
• Small teams cannot staff this. The ownership table names responsibilities, not headcount. In a small company one person holds several rows, and the maturity model exists so a team adopts one workflow's worth of architecture instead of an org chart. The framework scales down further than the governance chapter makes it look.

The sunset protocol

• Name the layer. A layer without a name, owner, and purpose cannot be measured or retired.
• Measure its burden. Track latency, cost, maintenance, review load, incident reduction, and eval lift.
• Run a shadow comparison. Test whether the model, renderer, or platform now preserves the same commitments without the layer.
• Remove behind a flag. Retirement should be reversible until traces and production sampling prove the change.
• Keep the accountability record. Even when scaffolding disappears, the decision, evidence, and rollback path should remain visible.

The book began with an analogy: visual design systems made interfaces coherent when screens multiplied, and Conversational Design Systems make adaptive behavior accountable when models, tools, agents, and channels multiply. The analogy ends here: buttons needed consistency, and adaptive AI needs responsibility.

The discipline begins when generated language stops being the unit of quality. The unit is the fulfilled commitment: intent understood, required facts admitted, authority checked, policy applied, action bounded, interface rendered so that the important things are seen, outcome measured, trace kept.

What makes a system excellent is that its layers are proportionate, inspectable, measured, and disposable, not how many it has. If this book has a bet, it is that model progress will keep simplifying the implementation while leaving the obligation untouched: to know what a product promised, why, what it enabled, and how it would be proven later.

This is a discipline for adaptive product quality. Everyone's model will sound natural, so the next generation of products will be judged on whether the product can adapt without losing its obligations, and that, unlike fluency, has to be built.

This list is a starting point: the incidents and works worth handing a colleague first. The framework borrows from conversation design, design systems, agent engineering, guardrails, policy-as-code, interoperability standards, observability, governance, and generative interface work, and each entry notes what it contributed. Vendor documentation appears as one hub link per vendor; everything else here is a specification, a paper, an incident record, or a book, because those stay where they were put.

corredor-control-plane · Reference implementation, 2026. The runnable companion to this book: a minimum viable experience control plane for one Corredor workflow: graph, contracts, authority, eval pack, and replayable traces, in about five hundred lines. github.com/kyle-c/corredor-control-plane

Moffatt v. Air Canada · BC Civil Resolution Tribunal via CBC News, 2024. The tribunal decision holding an airline liable for its website chatbot's invented bereavement-fare policy. The case made 'who owns the commitment' a legal question. cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416

Chevrolet Dealer Chatbot Agrees to Sell a Tahoe for $1 · AI Incident Database, 2023. A dealership assistant manipulated into producing contract-shaped language it had no authority to produce. The canonical argument for action contracts and authority graphs. incidentdatabase.ai/cite/622

DPD AI Chatbot Swears at Customer, Criticizes Company · Time, 2024. A courier's support bot cursing and mocking its own company after a system update: expression running with no constraint tier at all. time.com/6564726/ai-chatbot-dpd-curses-criticizes-company

NYC's AI Chatbot Tells Businesses to Break the Law · The Markup, 2024. A government chatbot advising illegal action on tips, housing vouchers, and cashless stores: what retrieval without provenance or authority looks like in production. themarkup.org/artificial-intelligence/2024/03/29/nycs-ai-chatbot-tells-businesses-to-break-the-law

Building Effective Agents · Anthropic, 2024. A practical taxonomy of workflows, agents, tool use, evaluation, and the recommendation to keep architectures simple until complexity is earned. anthropic.com/engineering/building-effective-agents

OpenAI Agents · OpenAI. OpenAI's agent runtimes compared (Agents API, Agents SDK, Responses API, ChatKit), with the shared primitives: tools, handoffs, sessions, and MCP servers. developers.openai.com/api/docs/guides/agents

Introducing System One Models and Jev · TypeSafe AI. A model class that returns typed decisions with calibrated probabilities instead of text, for classification, routing, verification, and agent guardrails. typesafe.ai/blog/introducing-system-one-models-and-jev

Model Context Protocol · MCP. A standard for connecting AI applications to external tools, data sources, prompts, and workflows. modelcontextprotocol.io/docs/getting-started/intro

Agent2Agent Protocol Specification · A2A Protocol. A specification for agent discovery, task execution, streaming updates, artifacts, task state, and agent cards. a2a-protocol.org/latest/specification

LangGraph · LangChain. A low-level orchestration runtime for long-running stateful agents, persistence, memory, human-in-the-loop, and tracing. docs.langchain.com/oss/python/langgraph/overview

Generative User Interfaces · Vercel AI SDK. A practical model of connecting tool calls to UI components and rendering adaptive UI inside conversational products. ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces

Open Policy Agent · OPA. A general-purpose policy engine and policy-as-code model for separating policy decisions from application enforcement. openpolicyagent.org/docs

Generative AI Semantic Conventions · OpenTelemetry. Development-status observability conventions for generative AI systems, including spans, metrics, events, MCP, and provider-specific conventions. github.com/open-telemetry/semantic-conventions-genai

AI Risk Management Framework · NIST. A risk-management frame for trustworthy AI across design, development, use, and evaluation. nist.gov/itl/ai-risk-management-framework

ISO/IEC 42001 · ISO. An AI management-system standard focused on responsible development, risk management, traceability, transparency, and continual improvement. iso.org/standard/42001

AI Act · European Commission. The risk-based regime European AI products now answer to. Read it beside chapter 17: documentation, human oversight, and post-market monitoring are the duties the artifacts in this book satisfy in executable form. digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

AI: First New UI Paradigm in 60 Years · Nielsen Norman Group, 2023. The intent-based outcome specification frame that helps explain why adaptive AI interfaces differ from command-based UI. nngroup.com/articles/ai-paradigm

Outcome-Oriented Design: The Era of AI Design · Nielsen Norman Group, 2026. A design frame for adaptive systems that respond to individual user goals rather than fixed average-user screens. nngroup.com/videos/the-era-of-ai-design

Conversation Design Guidelines · Google. Foundational conversation-design guidance for cooperation, turn-taking, confirmation, repair, and multimodal conversation. Archived under a deprecated Assistant surface; the guidance still holds. developers.google.com/assistant/conversation-design/welcome

Conversational Design · Erika Hall. A durable grounding in conversation as an interface and design material. mulebooks.com/conversational-design

The glossary is a reference. Each term names an artifact or concept that should be visible in a working system.

The laws are the book in portable form. Each one closed a chapter; here they are grouped by the decisions teams face: ownership, scope, authority, rendering, governance. If nothing else survives the reading, these should.

Part I - Laws of Ownership

What the product must own before the model can adapt

Part II - Laws of Scope and Composition

How much architecture to adopt and how to compose it

Part III - Laws of Authority and Context

What must be true before the system acts or remembers

Part IV - Laws of Rendering and Runtime

How adaptation reaches users without losing obligations

Part V - Laws of Evaluation and Governance

How the system improves without becoming unauditable