April 8, 2026
By David Szarzynski · Founding Engineer
An agent tells a customer their order has shipped. It did ship yesterday. The customer is holding the package right now. The agent is not lying. It is not hallucinating. It is confidently stating something that was true twelve hours ago. Its context is stuck in the past.
This failure mode is distinct from hallucination, and in many ways more dangerous. The information is real. It came from a real system. It was accurate when it was indexed. But the world moved on, and the agent did not notice.
The gap between "data changed in the source system" and "the agent knows about it" has a name: context freshness. Every agent system has this gap. Most teams do not measure it. This guide provides a framework for understanding, measuring, and designing for context freshness in agent memory systems.
Context freshness is the end-to-end propagation delay from the moment data changes in a source system to the moment an agent can retrieve the updated information.
Think of it as a chain. A record updates in a source system. A connector detects the change. The change enters an ingestion queue. Processing transforms raw data into structured, retrievable context. The index updates. Only then can the agent retrieve the new information. Every link adds delay.
The full propagation path looks like this:
Pipeline Stage | Latency Source | Typical Delay |
|---|---|---|
Source System to Connector | Polling interval | Seconds to minutes |
Connector to Ingestion Queue | Queue depth | Seconds |
Ingestion Queue to Processing | Chunking, embedding, enrichment | Seconds to minutes |
Processing to Index | Write latency | Milliseconds |
Index to Retrieval | Refresh interval | Seconds to minutes |
Here is a critical distinction: freshness is not the same as latency. An agent can respond in 100ms with context that is six hours old. Fast response, stale context. These are different dimensions, and conflating them is a common architectural mistake.
Freshness matters more for agents than for dashboards. A dashboard informs a human who can judge, cross-reference, and decide to wait for better data. An agent acts autonomously. As Tacnode puts it: "When systems trigger action, context quality determines outcome." And those actions are often irreversible.
Context freshness is the time between "the data changed" and "the agent knows about it." Every agent system has this gap. The question is whether it is seconds, minutes, or hours, and whether that matters for what the agent is doing.
Propagation delay is not a single number. It is the sum of four stages, each with its own failure modes.
The first stage is detection. If a connector polls every 15 minutes, there is up to 15 minutes of staleness before ingestion even begins. That is the floor, not the ceiling.
Webhook-based connectors reduce detection time to near zero. When a source system pushes a change notification, the memory layer learns immediately. But not all source APIs support webhooks, and webhook delivery is not always reliable. Many production systems use a hybrid approach: webhooks for primary detection, with periodic polling as a safety net.
Once a connector detects a change, the event enters an ingestion queue. Under normal load, queue processing is fast. Under spike conditions, queue depth grows. A system processing 10,000 backlogged documents will queue new, time-sensitive events behind them unless the queue implements priority lanes.
A well-designed ingestion pipeline distinguishes bulk historical imports from incremental updates, routing them through separate queues. A large initial sync should never block ongoing freshness.
Raw data is not useful context. It must be chunked, embedded, enriched with entity extraction, and mapped into relationships before it becomes retrievable. Richer processing yields better retrieval quality. Skipping entity extraction gets data into the index faster, but the agent may not find it when it matters. The goal is processing time that is predictable and proportionate to each data source's freshness requirements.
Once processed, data must be written to search indexes and made available for retrieval. Some systems batch index updates for efficiency, adding seconds to minutes of lag. This final stage is often the least visible. Teams assume that once data is processed, it is immediately searchable. In practice, index refresh intervals and cache invalidation add meaningful delay to the end-to-end chain.
Freshness guarantees depend on architecture and cost. Match freshness requirements to the architecture rather than over-engineering for real-time when minutes would suffice, or under-investing when seconds matter.
Freshness Tier | Latency Range | Achievable Via | Best For | Trade-offs |
|---|---|---|---|---|
Near-real-time | Seconds | Webhook triggers, live API queries at retrieval time, streaming pipelines | Order status, incident response, appointment scheduling | Higher infrastructure cost, rate limit pressure on source APIs |
Minutes | 1-15 minutes | Frequent polling intervals, lightweight processing, incremental index updates | CRM updates, document changes, calendar events, most enterprise use cases | Moderate cost, good retrieval quality, manageable API load |
Hours | 1-6 hours | Batch ingestion, full reindexing, heavy NLP processing | Analytics, knowledge base content, historical records | Lowest cost, highest processing quality, significant staleness risk for action-oriented agents |
Most enterprise agent use cases live in the "minutes" tier. Real-time is expensive and usually unnecessary. Hours are cheap but dangerous for agents that take action. Pick the tier that matches what the agent actually does with the data.
Near-real-time freshness is achievable through webhook-triggered updates, live API queries at retrieval time, or streaming pipelines. The trade-offs are real: higher infrastructure costs, potential consistency issues, and rate-limit pressure on source APIs. This tier is appropriate for support ticket status, order tracking, and incident response.
For most enterprise agent use cases, minutes-level freshness is the practical sweet spot. Frequent polling (every 1-5 minutes), lightweight processing, and incremental index updates keep context reasonably current without streaming infrastructure costs. CRM updates, document changes, and calendar events typically fall here. A contact record updated three minutes ago is close enough.
Hours-level freshness suits systems built on batch ingestion and full reindexing. Lowest infrastructure cost, most thorough processing. For agents that act on data rather than report it, this tier carries significant staleness risk. An agent that only summarizes can tolerate hourly freshness. An agent that sends emails or creates tickets based on context will eventually produce a visible failure.
Most teams measure individual component latency but not the full propagation chain. Here is a simple test: change a record in a source system, then query the agent for that information repeatedly until it returns the updated value. The elapsed time is the actual freshness. That number is almost always larger than expected, because it captures every stage, not just the one being optimized.
Not all staleness is equally harmful. A knowledge base article indexed yesterday is probably fine. An order status indexed yesterday is a problem. The severity depends on three factors.
Order status, incident response, financial data, and appointment scheduling. Stale context in these domains causes the agent to make statements the user already knows are wrong. As Materialize documents, AI systems fail when they cannot maintain a consistent view of rapidly changing business data. An agent saying "your appointment is tomorrow" when the user rescheduled it to next week does not seem slightly outdated. It seems broken.
When the user knows something has changed and the agent does not, trust collapses immediately. The user concludes the agent is unreliable, regardless of how accurate it is elsewhere. Confident wrongness erodes trust faster than admitted ignorance. An agent that acknowledges its limitations is forgivable. An agent that states outdated facts with full confidence is not.
When an agent's response triggers a downstream action (sending an email, creating a ticket, updating a record), stale context means the action itself is wrong. A wrong answer is correctable. A wrong action may not be. Tacnode frames this precisely: "the decision is the action, and the action is often irreversible."
Freshness is an architectural decision, not a feature added later. The ingestion architecture, processing pipeline, and retrieval strategy determine the propagation delay chain. Retrofitting freshness into a system designed for batch processing is expensive and fragile.
Not all data sources require the same freshness. Order status and support tickets need near-real-time. CRM records and calendar events need minutes. Knowledge base articles and policy documents can take hours.
A memory layer that connects to dozens of data sources does not need all of them streaming in real time. Each source needs the right freshness tier based on how agents use that data.
Tag each piece of retrieved context with its last-updated timestamp. Pass this metadata to the LLM so it can reason about how current the information is. "Customer order status (last updated: 3 minutes ago)" is fundamentally more useful than the same data with no temporal qualifier.
At Hyperspell, we surface source timestamps in every query response so agents have the information they need to qualify their own answers. Here is what that looks like using the SDK:
from hyperspell import Hyperspell
client = Hyperspell(api_key="YOUR_API_KEY")
results = client.memories.search(query="order status for #4521")
for doc in results.documents:
print(f"{doc.title}")
print(f" Last modified: {doc.metadata.last_modified}")
print(f" Indexed at: {doc.metadata.indexed_at}")
# Agent can compare timestamps to decide:
# use indexed result, or fall back to live search
Each result includes created_at, indexed_at, last_modified, and status fields (see the query memories API reference). When last_modified is significantly older than indexed_at, the agent has the signal it needs to escalate to live search rather than presenting potentially stale data as current fact.
When indexed context may be stale for a given query, the system should fall back to a retrieval mode that queries source APIs directly. This is where a dual-mode architecture proves its value.
At Hyperspell, we provide both indexed search (pre-processed data with fast indexed retrieval) and live search (real-time queries to source APIs). Indexed search handles the majority of queries where minutes-level freshness is sufficient. Live search handles freshness-sensitive queries where the cost of stale data exceeds the cost of higher retrieval latency. The agent detects which mode a query requires and routes accordingly.
Build monitoring that alerts when propagation delay exceeds acceptable thresholds for each source tier. Track freshness SLOs the same way uptime SLOs are tracked.
A memory system with 99.9% uptime but six-hour staleness is not serving action-oriented agents. Measure end-to-end propagation delay for each integration, set thresholds per freshness tier, and alert when those thresholds are breached.
Agents should communicate their confidence in the freshness of context when it matters. "Based on your order status as of 10 minutes ago" is more honest and more useful than a flat assertion. Users can handle uncertainty. They cannot handle confident inaccuracy.
Effective patterns: timestamp qualifiers in responses for time-sensitive data, explicit "let me check the latest information" messages when switching to live search, and proactive disclosure when context may be stale. These are signals of a well-designed system, not weakness.
Our dual search modes make this pattern straightforward to implement: use indexed search for general context, switch to live search for freshness-critical queries, and communicate the transition to the user.
Freshness is not a feature bolted on after launch. The propagation delay chain follows from foundational architectural choices: how data is ingested, processed, indexed, and retrieved. Changing these after deployment is costly.
Start by measuring actual end-to-end freshness. Classify data sources by required freshness tier. Design the architecture to meet those requirements. For teams building agent memory systems, Hyperspell provides continuous indexing across dozens of integrations and the ability to fall back to live API queries, delivering both speed and freshness without building the entire pipeline from scratch.
Context freshness is the propagation delay from source system change to retrievable agent context. Every agent system has this gap. Most teams do not measure it.
The sync latency chain has four stages: connector polling, ingestion queuing, processing, and index propagation. The total is always larger than expected.
Freshness is not latency. An agent can respond in 100ms with context that is six hours old. These are different dimensions.
Stale context is worse than no context when it contradicts user knowledge, concerns time-sensitive data, or triggers irreversible downstream actions.
Classify data sources into freshness tiers (near-real-time, minutes, hours) and allocate infrastructure accordingly.
A dual-mode retrieval architecture (indexed search for speed, live search for freshness) resolves the tension between query latency and context currency.
Communicate freshness to users. Timestamp qualifiers and explicit "checking latest" messages build trust more effectively than confident assertions on stale data.
Context freshness measures how quickly changes in source systems (CRM, email, tickets, documents) appear in an agent's available memory. It is the end-to-end propagation delay from the moment data changes to the moment an agent can retrieve the updated information, spanning connector detection, ingestion, processing, and index propagation. For a broader view, see our guide to context engineering for AI agents.
Change a record in a source system, then measure how long it takes for an agent query to return the updated information. This end-to-end measurement captures connector polling intervals, ingestion queue delays, processing time, and index propagation, giving the actual freshness number rather than the latency of any single component.
Stale context is most dangerous in three scenarios: time-sensitive domains where users already know the current state, situations where it contradicts what users already know, and situations where the agent's response triggers downstream actions such as sending emails or updating records. In all three cases, confident inaccuracy causes more damage than admitted ignorance.
Indexed search queries pre-processed, pre-indexed data for fast retrieval, but reflects data as of the last indexing run. Live search queries source APIs directly at retrieval time for the freshest possible data, but may have higher latency. Hyperspell's dual-mode architecture uses indexed search by default and falls back to live search for freshness-sensitive queries.
Workspace data from email, Slack, CRM, calendars, and documents is the primary source of agent context. Freshness determines whether that workspace data reflects current reality or a past snapshot. The more integrations an agent connects to, the more important a systematic approach to freshness becomes. See our guide on what AI agent memory is for more.