Free-text memories can go into a prompt. They can't sync to Salesforce, filter by deal stage, or aggregate across 10,000 entities. That's the downstream dead end.
TL;DR
- Open-set memory (free-text facts) is valuable for prompts but unusable by any downstream system that requires structured, queryable data.
- Schema-enforced memory extracts typed property values — text, number, date, boolean, options, arrays — with confidence scores and validation.
- Neither modality alone captures the full picture: 38% of valuable information is open-set only, 12% is schema-enforced only, and combined recall reaches 82.8%.
- The dual extraction runs in a single LLM call — the same content is processed once, producing both structured properties and atomic facts.
- Schema-enforced memory turns AI memory into an integration layer: CRM sync, analytics aggregation, conditional workflow routing, and structured API consumption become possible.
Most memory systems for AI agents solve one problem well: they store facts and retrieve them into prompts. The agent remembers that the customer prefers email, has a $500K budget, and is evaluating three vendors. Good. The prompt is better. The output is more personalized.
But then what?
The customer's budget needs to update in Salesforce. The deal stage needs to trigger a workflow. The buying signals across 10,000 contacts need to aggregate into a pipeline report. The pain points need to filter into a competitive intelligence dashboard.
Free-text memories can't do any of this. They're terminal. They enter the prompt and stop.
The Downstream Dead End
Here's the concrete version of the problem. Your enrichment agent processes a sales call transcript. It extracts three memories:
- "Sarah mentioned their budget is approximately $450K for the migration project"
- "They're currently evaluating three vendors including us"
- "The CTO expressed frustration with their current provider's API reliability"
These are good, useful facts. They make the next email better. But ask yourself:
- Can your CRM pull the $450K figure and put it in the deal value field?
- Can a workflow trigger because the deal moved to "evaluating vendors" stage?
- Can a dashboard aggregate API reliability as a pain point across all prospects in this segment?
- Can a scoring model use the vendor count as a competitive density signal?
With free-text memories, the answer to all four is no. The information is there, but it's locked in natural language. Extracting it requires another LLM call, another prompt, another chance for hallucination, and another integration to build.
Unstructured memory is useful for prompt augmentation but unusable by any downstream system that requires structured, queryable data.What Schema-Enforced Memory Adds
Schema-enforced memory extracts typed property values according to an organizational schema. You define the properties you care about — their names, descriptions, types, and extraction hints — and the system extracts validated values with confidence scores.
From the same transcript, schema-enforced extraction produces:
budget_range: "$450,000" (type: number, confidence: 0.92)
buying_stage: "Evaluating" (type: options, confidence: 0.88)
pain_points: ["API reliability", "provider switching costs"]
(type: array, confidence: 0.85)
competitor_count: 3 (type: number, confidence: 0.90)
These are typed, validated, queryable values. They can sync to a CRM field. They can trigger a workflow. They can aggregate in a report. They can feed a scoring model. The information isn't locked in prose — it's structured data with a schema contract.
Property types include text, number, date, boolean, options (enum), and arrays. Each value carries a confidence score and explicit update semantics — supporting both single-value replacement (budget changed) and temporal accumulation (pain points accumulate over time).
Property Selection
Before extraction, the system doesn't dump the entire schema into the LLM call. Embedding similarity between the content and property metadata selects only relevant properties, with a minimum score threshold and maximum count cap. If your schema has 200 properties but only 8 are relevant to a sales call transcript, the LLM sees 8 — reducing hallucination and improving type compliance.
This matters at scale. Organizations accumulate hundreds of properties across collections. Without property selection, the LLM is presented with a wall of irrelevant field definitions and starts guessing.
Why You Need Both
The instinct is to pick one: structured or unstructured. Schema-enforced extraction gives you queryable data. Open-set extraction gives you everything. Why not just use one?
Because neither alone captures the full picture. We measured this directly across 20 samples:
| Category | % of Total | |---|---| | Captured by both modalities | 34% | | Open-set only | 38% | | Schema-enforced only | 12% | | Missed by both | 16% | | Combined recall | 82.8% |
38% of valuable information exists only as open-set observations that no schema anticipated. "The CTO mentioned they're building an internal developer platform." "Their VP of Engineering previously worked at a competitor." "The team is planning a conference talk about their migration experience." These are the long-tail insights that competitive intelligence, deal strategy, and relationship building depend on. A schema can't anticipate them because they're specific to each entity's unique context.
12% is captured only by schema enforcement — typed values where the extraction prompt and type validation ensure correct, structured output. Without the schema telling the LLM "extract a number for budget_range," the open-set extractor might produce "Sarah mentioned a budget in the mid-six-figures" — useful for a prompt, useless for a CRM field.
The dual extraction runs in a single LLM call. Both outputs — typed properties and atomic facts — are produced from the same content in the same pass. The cost is one extraction, not two.
The Integration Layer
Schema-enforced memory transforms AI memory from a prompt augmentation tool into an integration layer. Here's what becomes possible:
CRM synchronization. Property values with type validation and confidence scores can map directly to CRM fields. Budget maps to opportunity amount. Buying stage maps to pipeline stage. Pain points map to a custom field. The sync is deterministic — typed values go into typed fields — rather than requiring an LLM to parse free text into structured data at sync time.
Conditional workflow routing. "If buying_stage equals 'Evaluating' and competitor_count is greater than 2, trigger the competitive positioning workflow." This is a simple conditional on structured data. With free-text memory, this requires an LLM call to interpret "they're evaluating three vendors" and determine if it meets the criteria — adding latency, cost, and hallucination risk to every routing decision.
Analytics aggregation. "What are the top 5 pain points across all prospects in the enterprise segment?" With schema-enforced memory, this is a database query on the pain_points array property. With free-text memory, this requires LLM-powered analysis of thousands of unstructured observations — expensive, slow, and unreliable.
Structured API consumption. Any downstream system that consumes entity data through an API gets typed, validated values with confidence scores. Not free text that requires interpretation, but structured data with a schema contract. This enables reliable machine-to-machine integration without LLM intermediation.
Schema Lifecycle
Schemas aren't static. The biggest risk in schema-enforced memory isn't building the initial schema — it's maintaining it as content types shift, organizational priorities change, and extraction quality drifts.
We built a full schema lifecycle with four stages:
AI-assisted authoring. Users describe what they need in natural language. The system generates typed property specifications. This accelerates the translation from user intent to well-formed schema without requiring expertise in schema design.
Interactive enhancement. Operators describe observed issues — "the role field is too vague" or "buying intent should distinguish between active evaluation and future interest" — and receive revised property definitions. This happens at per-property or bulk granularity.
Criteria-based evaluation. Agent interactions are scored against domain-specific rubrics with access to full execution traces. This answers: "Did the agent use the extracted properties? Were they accurate? Did they influence the output quality?"
Automated refinement. A three-phase pipeline: replay extraction, classify each property (extracted/missed/low-confidence/inaccurate), and generate revised definitions. The system tells you which properties are working and which need attention — before a CRM field has been wrong for three months.
Without this lifecycle, schemas age silently. Models get updated. Content types shift. The organization discovers the problem when downstream data has been wrong long enough to cause decisions based on stale or inaccurate information.The Practical Test
If you're evaluating whether your memory system has the downstream dead-end problem, ask:
Can a non-LLM system consume the output? If the only consumer of your memory is an LLM prompt, you have a dead end. Structured properties should be consumable by CRMs, workflows, dashboards, and APIs without LLM intermediation.
Can you filter entities by memory content? "Show me all contacts where buying_stage is 'Evaluating'" should be a database query, not an LLM call. If filtering requires semantic search over free text, you can't build reliable conditional logic on top of it.
Can you aggregate across entities? "Top pain points across enterprise prospects" should aggregate a structured field, not analyze thousands of unstructured observations. If aggregation requires LLM processing, it won't scale and won't be reliable.
Does extraction quality degrade silently? If there's no mechanism to detect that a property extraction has drifted — the model started interpreting "budget" differently after an update, or a new content type doesn't match the extraction hints — you're building on a foundation that can shift without warning.
The memory layer that only serves prompts is a useful tool. The memory layer that serves prompts and CRMs and workflows and analytics is infrastructure. The difference is schema enforcement.
Frequently Asked Questions
Don't CRM integrations already handle this? Traditional CRM integrations move data between systems. Schema-enforced memory creates structured data from unstructured content — call transcripts, emails, chat logs — that would otherwise require manual data entry. The integration layer starts at extraction, not at sync.
What if my schema doesn't cover a new type of information? That's exactly what open-set memory handles. The 38% of information captured only by open-set extraction includes everything the schema didn't anticipate. Over time, patterns in open-set observations can inform schema expansion — if "internal developer platform" keeps appearing as an open-set fact, it might deserve a schema property.
How do you handle schema changes without breaking existing data? Property values carry timestamps and confidence scores. Schema changes affect future extractions, not past data. The automated refinement pipeline can replay extraction against existing content with revised definitions, producing updated values alongside the originals.
What about privacy — does schema-enforced extraction increase PII risk? The two-phase redaction pipeline runs before and after extraction regardless of memory type. Schema-enforced properties go through the same PII scrubbing as open-set facts. Additionally, schema definitions can include redaction hints — marking a property like "personal_email" for automatic redaction.