Thoughtware

Context is a feature

What the system knows for this run, from calendar, selection, and endorsed knowledge, is curated and designed, not accidental prompt stuffing.

9 min read

Cover for Context is a feature

A household opens the Meal Companion mid-week. They should not re-explain that Tuesday is busy, that spinach must be used by Wednesday, or that Leena's cashew allergy is confirmed. Asking them to restate settled facts feels like poor service, not a technical limit.

Yet many teams treat context as conversation history bolted onto a model call. In an intelligence-native product, context is a first-class feature: named sources, labelled authority, correctable assumptions, not maximal transcript dump.

Helpful context: Memory and knowledge is endorsed answer what may be believed after today. Conversation becomes state shows how utterances update context for this run.

Context for this run

For one planning run, useful context might include the originating request with busy days and spinach deadline, calendar guests Thursday, endorsed knowledge such as cashew allergy and busy evening rules, active corrections like "avoid pasta this week," and working state with current plan version and accepted meals. Context answers what is happening right now. Memory answers what should survive after today. Mixing them produces amnesia or intrusive recollection.

SourceExampleMemory form
Originating requestbusy days, spinach deadlinecontext
Calendarguests Thursdaycontext
Endorsed knowledgecashew allergy, busy evening ruleknowledge
Active correctionsavoid pasta this weekcontext, not auto-promoted
Working stateplan version, accepted mealsworking state

The distinction matters because context and memory are governed differently. Context-only items show expiry. Endorsed knowledge shows an enforcement badge. Proposed promotions show approval pending. Mixing the forms in one undifferentiated "remembers" list produces "it forgot" complaints when context expired correctly and "it remembered" complaints when rumour promoted silently.

Curated context beats maximal context

More tokens is not more context. Weak context produces either re-asking settled facts or treating rumour as knowledge. Teams sometimes dump entire transcripts, all retrieved chunks, and full preference history into one call. That produces noise, cost, and contamination. Context as a feature means policy selects what each judgment may read.

Each cognitive unit in the chain declares which context sources it may read. InterpretWeek reads calendar and originating request. Allergy enforcement reads endorsed knowledge only. CritiquePlan reads working state and active corrections. Ad hoc chat lines do not flow into enforcement without promotion. Context policy prevents both omission and contamination: omission forces tedious repetition, contamination promotes rumour to law.

Great intelligent products continuously gather and organize these signals without forcing users to provide them repeatedly.

Thoughtware: Designing in the Intelligence Age · Ch. 9

When context is weak, a targeted question beats inventing certainty. When context is strong, re-asking settled facts is a failure of the feature. Ad hoc chat lines rank low for enforcement. See least trustworthy input. Context policy demotes rumour unless promoted through an explicit gate.

The spinach deadline as a context beat

The originating sentence says "use the spinach before Wednesday." Context for this run carries that deadline with source labelled as originating request. GenerateCandidates and ComposeWeek prefer meals that consume spinach early in the week. If the household later says "guests Thursday," calendar context updates and replan may shift spinach usage without re-asking the original sentence.

If context omits the deadline, the plan may place a spinach meal on Friday. The household experiences poor service even when individual meal suggestions sound fine. Context is a feature because omission is a product failure, not a model quirk.

The same principle applies when calendar shows guests Thursday. Context pulls guest count and may trigger variety or portion adjustments. The guest signal arrives labelled from calendar integration, appears in the inspector, and binds replan without the user restating guest plans in chat. One context field propagates across the chain when the feature works.

Context inspector UX

Advanced products expose a context inspector: what was pulled for this run, from where, with what authority. The inspector is useful for trust, debugging, and contestability. Households see calendar, originating request, and active corrections with source badges.

Freshness indicators help contest stale assumptions: "calendar synced two hours ago," "allergy confirmed last month." Households can correct wrong context before it binds the plan. Context inspector or inline "why this" links let users fix calendar misreads or wrong guest assumptions. Contestability at the context layer prevents expensive downstream correction.

Context often arrives from integrations: calendar busy flags, grocery inventory, guest RSVP. Each integration needs an authority label and freshness indicator. Stale calendar context produces wrong busy flags silently. Integration without labelled context is prompt stuffing with extra steps. Tool permission UX that explains what will be read, what will not, and how to revoke is part of the context feature. Silent calendar read feels surveilled.

When calendar access is missing, the honest approach asks whether Thursday is still guest night rather than inventing guests. When allergy endorsement is missing, the product defers or escalates rather than guessing. Weak context handled honestly beats strong context invented silently. Refuse and defer belong in context design as much as in safety policy documents.

Measuring context quality

Tracking re-ask rate for settled facts reveals context failures. If households repeat "busy Tuesday" every week, context failed. If the product asks allergy confirmation when endorsement exists, context failed. Re-ask rate for settled facts belongs on the dashboard beside latency. Wrong-source failures, when calendar was ignored or chat rumour enforced, reveal context contamination.

Context quality predicts trust more than raw retrieval recall on benchmark sets disconnected from product judgments. Curated context also reduces token cost versus dump-all: cost and quality align when context is a feature, not an accident.

Context regression suites include held-out scenarios: guest night, spinach deadline, busy week pattern. Assertions verify correct sources pulled. Context eval runs separate from generation eval. Context debt tracking, where context sources were requested but unavailable, prioritises integrations that reduce re-ask rate.

Enterprise workflows follow the same measurement pattern. Invoice exceptions need vendor history, contract spans, and policy flags for this run. Support tickets need account tier, open incidents, and recent resolutions. Context policy differs per judgment while the design principle stays constant. Field teams experience weak context as disrespect: re-asking busy Tuesday mid-week feels like poor service regardless of model size.

An editable list of context for this run, busy days, guest count, avoid list this week, complements utterance-based input. Some users prefer panel edit over chat for precision. Context inspectors help enterprise admins trust automation enough to expand deployment.

The common mistakes cluster around the same root cause: treating "what the system knows" as an undifferentiated heap rather than a curated, policy-governed feature. Dumping everything in the prompt, treating transcript as context without policy, and mixing context with memory so households experience amnesia or intrusive recall are the three recurring failures. Attaching context source lists to each cognitive unit spec and rejecting specs that say "use relevant history" without naming sources prevents these failures at design time. Context regression tests verify settled facts are not re-asked and rumour is not enforced. The discipline is worth the effort because field teams and households experience weak context as disrespect before they experience it as a technical bug.

What to do next

Listing context sources for the primary AI workflow and marking the authority level for each reveals where context is designed and where it is accidental. Removing one "helpful" source that has no policy and breeds rumour is often the highest-leverage improvement. The next question is how memory surfaces in UX: memory is part of UX describes visibility, editability, and the trust contract that curated context depends on.

See memory as architecture and six forms of memory.

Read next: Memory is part of UX.