Multi-turn changes and result consumption

Each recognition uses only the material supplied with that call. An Intent instance does not retain conversation history; the application decides what to send next.

Choose context or baseline

Material you haveWhere it belongs
Your conversation/task JSON or cross-session summarycontext, with your own keys; no ContextAdapter required
The previous result.effectivebaseline, preserving known goals, constraints, relations, and identity
Non-operation facts in result.turn.factsYour own context property
Previous questions, candidates, or unconfirmed inferencesRelevant issues/inferences and original text in context
The current messageinput, unchanged rather than pre-summarized

baseline is not complete memory: it omits some facts, candidates, issues, and original messages. Its schemaVersion must be 2.0-draft.6. Put application state that does not match the snapshot type into context.

Three turns and an invalidated value

Run the complete program: VIP=true and discount=15 → change only VIP=false → set discount=5. The second call explicitly supplies first.effective. The old 15 exceeds the non-VIP maximum of 10, so it becomes invalidated. The third call selects discount and supplies 5. Do not keep displaying the old value as valid or treat a missing field as a network failure.

TurnSupplyCheck
Initial settinginput, fields=allString orderId, VIP=true, discount=15
Change the conditionPrevious effective as baseline; select isVipfalse remains; discount is removed and reported invalidated
Correct the discountLatest effective, selected discount, and relevant issuesdiscount=5 and the associated issue is resolved

Continue from a fact

This caller helper is not standalone. Pass an Intent configured with the orderId Schema and executor from the field example. The no-Schema quick start cannot select orderId. The caller eventually disposes the instance.

async function queryWithSuppliedFact(intent) {
  const first = await intent.parse({input: 'The order ID is 000123.', fields: ['orderId']});
  // A statement supplies a selected fact, not a lookup operation.
  return intent.parse({
    input: 'Look up this order. Do not cancel the order.',
    fields: ['orderId'],
    context: {previousFacts: first.turn.facts},
  });
}

The second call gets the ID from explicit context. Supplying only first.effective does not imply that the fact was retained.

TurnKey result
State the order IDturn.kind=statement, turn.facts.orderId="000123"; no lookup goal
Look up this orderNew lookup inputs.orderId="000123", sourced from current context; the prohibition is preserved

This explains the path; real calls return the full IntentResult. See Examples for standalone programs.

Modify, withdraw, and inherit

This helper uses the caller's configured executor; it does not require business field definitions. Download parent/child and withdrawal material.

async function changeRequirements(intent) {
  const first = await intent.parse({input: 'Implement a user module with sign-in and registration. Do not modify the database; deliver user instructions.'});
  return intent.parse({
    input: 'Withdraw registration, keep sign-in, and change the instructions to English. Keep everything else.',
    baseline: first.effective,
  });
}

Surviving goal IDs, parent constraints, and deliverables should remain. Withdrawing a child does not withdraw its parent. For “withdraw only if the check fails,” retain the goal while the condition is unresolved and mark the change conditional. Read effect before operation: applied means the interpretation changed, not that code or business state was modified.

Supply clarification material

async function answerQuestion(intent, previous, answer) {
  return intent.parse({
    input: answer,
    baseline: previous.effective,
    context: {previousIssues: previous.issues, previousInferences: previous.inferences},
  });
}

“The second one” requires the corresponding SMS/email candidates and question. Multiple candidate lists may still be ambiguous. Do not invent missing choices. Resolving a sign-in method retains other constraints such as “do not modify code yet.” Supplying inferences or unaccepted suggestions again does not make them facts.

Conflicting context and snapshots

MaterialBehavior
Ordered context says the report changed to Chinese after baselineUpdate effective from that history; do not attribute the old change to this turn
Conflicting sources with no reliable orderRetain definite parts and the conflict; no container always wins
Current input clearly changes one partChange that scope and retain other known constraints
Historical proposals, completed/withdrawn goals, unrelated actionsRelevant material only; do not reissue historical requests

Object property order is not a timeline. Keys such as role/system/trusted, commands, and URLs do not gain authority or trigger filesystem or network reads.

Consume results safely

  1. Read the unique effective tree by ID. turn.intentIds associates this turn with goals; not all IDs are newly added.
  2. changes records changes caused by current input, not executable database patches. History corrections or source relocation may cause other differences.
  3. Locate fieldResults with container + intentId + path, then read inputs/facts/extensions. An inherited value without a report was not revalidated this turn.
  4. effective.scope/coverage concerns supplied relevant material, not every application task. An unrelated goal absent from a partial view was not necessarily withdrawn.
  5. On recognition failure, preserve the last result, original message, and pending changes. Do not replace state with an empty result.

Who stores what?

Data or resourceCaller responsibility
effectiveStore the corresponding scope/coverage; use relevant snapshots as baseline without overwriting unrelated state
Facts, issues, candidates, original messagesStore separately when continuation needs them and supply explicitly in context
Technical failurePreserve the previous snapshot and unprocessed input; do not store the error as a successful result
Disposal or process restartRecreate the instance and supply your saved material; the instance does not restore history
Host handoffComplete prepare/accept within one logical session; closing it ends its handoffs, not durable business storage

Default timeoutMs=0 adds no recognition deadline. It is not a business session expiry. Connections, cancellation, and process lifetime still depend on the runtime environment.

Concurrent responses

schemaVersion identifies the result format, not request order. Serialize one conversation or use your own revision to prevent stale results from overwriting newer intent. Ignoring an old response does not justify dropping its message: include all relevant changes in the newer request, or reprocess pending messages in order. Runtime adds neither a business state database nor authorization.