Thoughtware

Conversation before configuration panels

Structured conversation replaces dense settings for everyday intent. Conversation must compile to inspectable state, not remain an ephemeral transcript.

8 min read

Cover for Conversation before configuration panels

A household wants the Meal Companion to prefer vegetarian options on Mondays. In an Information Age product, they hunt Settings, Dietary Preferences, Day Rules, Add Rule. In an Intelligence Age product, they say: "Mondays are usually vegetarian here."

Both paths can work. The failure mode is letting conversation replace governance, or letting settings ignore how people naturally express intent.

Helpful context: Intent over instructions names the outcome conversation serves. Conversation becomes state is the architectural requirement that makes this principle honest.

Three layers of control

Most products need all three layers, not a binary switch. Conversational intent describes behaviour when needed, and it is fast for reversible, low-consequence preferences and exploratory work. A structured preference store holds accepted choices as editable state with provenance, distinct from chat memory that cannot be challenged cleanly. Deterministic configuration holds permanent rules, permissions, and compliance constraints, visible, auditable, and deliberately changed.

The Monday vegetarian preference illustrates how the layers cooperate. The household says "Mondays are usually vegetarian here." The product asks whether this is for this week only or generally. They choose generally. The system writes a proposed preference with provenance and shows it in the preference panel. They approve. GenerateCandidates reads the endorsed rule on future Monday planning runs. If they had chosen "this week only," the write lands in context for this run and expires appropriately. Same utterance, different scope, different memory form. That scope confirmation is how conversation stays honest.

Reserve settings for decisions that genuinely benefit from permanence, visibility, and deliberate control.

Thoughtware: Designing in the Intelligence Age · Ch. 8

The split matters because misclassification produces either form fatigue or governance risk. Mushroom dislike promoted without approval feels surveilled. Purchase auto-enabled through chat feels dangerous. Product teams classify preferences by consequence and permanence: reversible week-level tweaks flow through conversation, standing household rules flow through endorsement, and org policy flows through configuration.

When settings still matter

Conversation is not an excuse to eliminate control. Privacy, security, compliance, and organisational policy still deserve explicit controls people can find without reconstructing a transcript. A financial approval workflow does not silently change itself. Grocery purchase in the Meal Companion still requires approval. Conversation does not grant authority.

High-stakes permanence belongs in settings with audit trails. Reversible preferences belong in conversation that compiles to state. Multi-factor auth, billing addresses, and regulatory attestations stay in settings. Attempting to capture them through casual chat creates fraud and compliance risk. Conversation-over-configuration is not conversation-for-everything.

Enterprise buyers ask which rules live in configuration versus conversation. That split is documented publicly so auditors find policy without transcript search. Support teams need the same map, because misanswered questions about where allergy rules live produce incidents even when models are capable.

Dialogue that updates working state

"Tuesday got harder this week" updates context for this run and triggers replan where the constraint binds, in addition to appending a chat line. The household adjusts the week through dialogue. The backend updates working state and preferences through approval paths.

When every change hides inside chat alone, the product collapsed conversation and configuration into an opaque transcript. When every preference requires a form, the product ignored Intelligence Age interaction. Honest implementation shows the difference: reversible preferences set in chat appear in a preference panel, and policy changes require a settings screen with audit trail.

Exploratory work benefits from low-friction dialogue. "What if we tried more fish this month?" Configuration holds what must survive audits. "Which accounts may auto-approve under what dollar limit?" Mixing the two produces either form fatigue or silent policy drift. Design reviews classify each control by layer before debating visual treatment, because layer errors are architecture errors even when the chat copy sounds friendly.

The same layered approach shapes onboarding. Outcome sentences come first. The preference panel comes second. Policy configuration comes third. Households learn direction before they learn law. Enterprise rollouts follow the same sequence at role level: clerks learn domain direction, admins learn policy panels.

Chat-as-database is the common failure

Chat memory can help interpretation, but it is a poor authority for configuration. See preference store versus chat memory and memory is part of UX. Products that treat the transcript as the database cannot answer "what does the product believe," "who approved it," or "how to remove it" without archaeology.

Products that store preferences only in transcript cannot answer audit questions. Who said mushrooms were disliked? Is that still active? Did it apply to one week or forever? Conversation-over-configuration fails when conversation never compiles. The fix is state objects with scope and provenance, not longer chat memory.

Silent promotion is a subtler version of the same failure. A one-run exception written as standing policy is a governance failure. A standing preference hidden only in chat is an editability failure. "Avoid pasta this week" maps to context only. "We generally avoid pasta" maps to proposed endorsement and requires approval. Scope confirmation is how conversation stays honest, and without it households cannot tell whether Tuesday's exception became household law.

The broader failure pattern includes settings-only approaches that ignore how people speak, missing scope confirmation that turns week exceptions into household policy, and full replan on small utterance that violates point and fix. Each failure has a named repair in linked notes. The Designing track is cumulative: conversation over configuration sits between intent capture and state compilation. Some preferences start in conversation and finish in a settings panel for fine tuning. Hybrid flows are valid when scope is general and details need precision: conversation opens, settings refine, endorsement closes. Org admin may set policy that conversation cannot override, and household conversation respects admin law.

Governance reviews ask which preferences may enter through conversation versus configuration. Documenting the classification publicly helps support teams answer consistently. Audit trails for policy changes remain in settings even when day-to-day tweaks happen in dialogue. Buyers ask where permanent rules live, and chat-only governance fails enterprise procurement.

Measuring the split

Listing ten preferences and classifying each as conversation, preference store, or configuration reveals governance defects before incidents arrive. Any chat-only high-stakes item is a governance risk waiting for its moment. Quarterly preference audits reclassify items that moved layers without documentation.

Support macros that explain where households can edit standing rules without reconstructing chat reduce friction. Enterprise admins need configuration paths for policy even when day-to-day tweaks use dialogue. Mis-layered preferences produce governance incidents, and both chat-only purchase rules and form-only reversible tweaks are failures of this principle.

What to do next

The three-layer model, conversation for reversible intent, preference store for endorsed standing choices, and deterministic configuration for law, provides a classification framework that every product control benefits from. The architectural connection is direct: conversation becomes state describes the mechanism by which utterances update structured objects with scope and provenance, and context is a feature shows how curated context for each run prevents both re-asking settled facts and treating rumour as knowledge.

See preference store versus chat memory and memory is part of UX.

Read next: Conversation becomes state.