Before an answer,
resolve the context.
MCIR stands for Memory Context & Intent Response. This is the technical view of the intent-driven memory path: resolve the task, select sources, assemble context, then generate. The full pipeline is gated; ordinary built-in recall is a separate supported path.
01the request view
Four stages, from intent to generation.
The first three stages prepare context; generation is the fourth. This describes the full MCIR path when enabled, not four extra model calls or a pipeline every completion executes.
- Produces: Task intent
Intent resolution
Resolve the action, object, time window, and referenced artifact. “Resume last week’s draft” is more specific than a bag of keywords.
- Produces: Source-linked fragments
Memory context assembly
Gather relevant fragments from available memory layers. Keep their origin attached and respect the caller’s scope.
- Produces: Context envelope
Context fusion
Combine the original prompt, intent, fragments, and reconstructed prompt. Preserve references rather than quietly replacing the source.
- Produces: Response
Response generation
The orchestrator hands the assembled context to the selected capability. A generated answer still needs application-level validation.
02the memory view
Eight stages describe a memory’s life.
Capture → Classify → Index → Retrieve → Validate → Apply → Expire → Audit. These are lifecycle responsibilities, not eight synchronous steps that every completion visibly executes.
- 01
Capture
What is worth remembering?Identify facts, preferences, decisions, and unresolved questions from an interaction.
- 02
Classify
What kind of memory is it?Distinguish a preference, business rule, task, or other contextual fact.
- 03
Index
Whose context is this?Associate the memory with its owner and the scope in which it may be retrieved.
- 04
Retrieve
Does it help with this intent?Surface relevant context for the current task, not every stored item.
- 05
Validate
Is it still appropriate to use?Check for stale or contradicted context before applying it.
- 06
Apply
How does it influence the answer?Use the fragment as a fact, preference, warning, or instruction with its provenance.
- 07
Expire
Should its influence change?Use freshness and revalidation rules. Declared durable facts need separate treatment.
- 08
Audit
Can we trace what happened?Record retrieval and use so that an application can investigate the decision.
Lifecycle descriptions explain the protocol’s design. Exact behavior and feature availability depend on the implementation and deployment; decay of influence is not deletion of a record.
03an inspectable handoff
Carry references forward, not just a longer prompt.
{
"originalPrompt": "Resume the release draft.",
"intent": {
"verb": "resume",
"object": "the release draft"
},
"memoryFragments": [
{
"source": "episodic",
"content": "The release remains a draft until reviewer sign-off.",
"provenance": {
"messageId": "message-demo-03",
"conversationId": "conversation-demo-01"
}
}
],
"reconstructedPrompt": "Resume the release draft. [ref: message-demo-03]"
}Original task. Added context. Visible origin.
On the enabled MCIR path, the model-independent context envelope preserves the original prompt, resolved intent, and selected fragments. It prepares a handoff to a qualified model route. Connected channels do not automatically imply the full pipeline is enabled for every caller.
In this specimen, the source establishes a review requirement. It does not establish that a review happened. A careful response should preserve that distinction, and the application should let a reviewer inspect it.
04supported, gated, and planned
Built-in recall. Explicit activation boundaries.
- Built-in memory Documented · supported paths
- No separate memory API is required for supported integrations. Ordinary recall is distinct from the full intent-and-envelope pipeline.
- MCIR intent pipeline Implemented / gated
- The intent, source selection, and context handoff shown here have activation and caller-eligibility requirements. Not every completion uses this full path.
- Memory Chain Implemented / gated
- Conversation summaries, open loops, and behavioral context have a separate activation gate. Confirm availability before depending on proactive cross-thread recall.
- Learning and recall upgrades Next / planned
- The published roadmap separates outcome-driven scoring, vector recall, and compression upgrades from the currently available paths.
resolve the terminology
Three views. No conflicting stage count.
Why do the API docs describe five stages?
The broader API overview groups work into classification, skill loading, engine routing, the agent loop, and response formatting. MCIR’s four-stage request view describes intent and memory preparation through generation. They are different architectural views, not interchangeable counts of a single pipeline.
Do the eight lifecycle stages happen before every answer?
No. The lifecycle includes events such as capture, expiry, and audit that occur across a memory’s life. It should not be drawn as eight mandatory model calls or eight guaranteed events for every request.
Is the protocol a guarantee of correct memory?
No. Provenance, validation, and freshness handling make context easier to inspect; they do not prove that a source is true or remove the need for application review. Gated and planned capabilities must be evaluated within their stated scope.
Read the memory behind the response.
Inspect a source, compare it with a newer decision, and see why context needs a lifecycle, not just a storage location.