- In short
- Static knowledge such as policies, documentation, or historical records can be served from a periodically refreshed index. Live-state data such as current prices, account balances, or real-time conditions requires a direct tool call at request time, not a cached index. Mixing the two without separation risks serving stale live-state answers from a static index, so the two must be kept distinct.
Two kinds of knowledge, two retrieval mechanisms
Not all data a system retrieves changes at the same rate, and the exam wants you to separate two categories that need different mechanisms. Static knowledge, policies, documentation, historical records, changes slowly and can be served from an index that is refreshed periodically. Live-state data, current prices, account balances, real-time conditions, changes constantly and must be fetched fresh with a direct tool call at request time. Serving live-state from an index is the core error, because an index only reflects the state at its last refresh, so anything that has changed since is served stale.
This is a data-freshness version of the data-shape thinking from method selection: there, the shape of the data chose the method; here, the volatility of the data chooses between an index and a live call.
- Live-state vs static knowledge retrieval
- A separation of retrieval by data volatility: static knowledge (policies, documentation, history) is served from a periodically refreshed index, while live-state data (current prices, balances, real-time conditions) requires a direct tool call at request time. Mixing them risks serving stale live-state answers from a static index.
Static knowledge suits an index
Static knowledge is a good fit for indexed retrieval precisely because it does not change quickly. A policy document, a product manual, a historical record, these are stable between updates, so an index built from them stays accurate until the next refresh, and a periodic reindex keeps it current enough. The staleness window of an index, the gap between refreshes, is acceptable when the underlying data changes more slowly than that window. For static knowledge that changes weekly or monthly, a daily reindex is more than adequate.
So the index is the right mechanism for the slow-moving majority of a knowledge base. It is efficient, it supports similarity and filtered retrieval, and its inherent staleness window does not matter for content that rarely changes.
Live-state data needs a direct call
Live-state data breaks the index model because its staleness window is unacceptable. An account balance, a current price, a real-time status, these can change second to second, and an index refreshed even every few minutes will routinely serve a value that is already wrong. The only correct mechanism is a direct tool call at request time that fetches the current value from the system of record, so the answer reflects the state now, not the state at the last refresh. No reindex schedule short enough to keep up is practical for data that changes every few seconds, and even if it were, it would be a fragile way to do what a direct call does reliably.
The rule, then, is mechanism-by-volatility: if the data must be current to the moment, fetch it live; if it tolerates a refresh window, index it. This mirrors the prompt-caching consistency window, where cached content that must reflect live state can serve stale information, the same staleness risk from a different mechanism.
Keep the two separate
The design consequence is separation. A system that serves both static knowledge and live-state data must keep the two paths distinct: index the static content, and route live-state queries to a direct tool call. Blur them together, put live-state values into the same index as the static knowledge, and the system will happily answer a live-state question from the stale index, because it cannot tell which of its retrieved content needed to be fresh. Explicit separation is what guarantees live-state questions get the live path and static questions get the efficient index.
What the exam trips candidates on
Two traps. The first is serving a live-state query, such as a current account balance, from a nightly-refreshed vector index instead of a live tool call, which returns whatever the value was at the last refresh. The second is assuming a short reindex schedule is fast enough for data that changes every few seconds, which underestimates how stale even a frequent refresh can be for volatile data. The credited answer routes live-state to a direct call and reserves the index for static knowledge.
Worked example
A banking assistant answers two kinds of question: 'what is my current account balance' and 'what is the policy on overdraft fees.' The team indexes both the balances and the policy documents into one nightly-refreshed vector index and retrieves from it for every question. Customers report their balances are sometimes wrong. Diagnose and redesign.
The wrong balances are the predictable result of serving live-state from a static index, the first trap exactly. Account balances are live-state data: they change with every transaction, potentially many times a day. The team's index refreshes nightly, so a balance retrieved from it reflects last night's value, and any transaction since is invisible. A customer who spent money this morning is told last night's balance, which is why the balances are 'sometimes wrong', they are stale by construction. No tightening of the refresh schedule truly fixes this, because balances can change every few seconds and even a frequent reindex would lag, which is the second trap.
The overdraft-fee policy, by contrast, is static knowledge, it changes rarely, so serving it from the nightly index is perfectly fine; its staleness window is far shorter than how often the policy changes. So the redesign is to separate the two paths by data volatility. Route the balance query to a direct tool call against the account system of record, fetching the current balance at request time so the answer is correct to the moment. Keep the policy documents in the periodically refreshed index, where indexed retrieval is efficient and the refresh window is more than adequate. The system decides per query which path to use: live tool call for the volatile balance, index for the stable policy. That separation is what stops the assistant from ever answering a live-state question from a stale index.
Common misreadings to avoid
Misconception
A current account balance or price can be served from a periodically refreshed index like any other content.
What's actually true
Misconception
Making the reindex schedule short enough will keep live-state data fresh in an index.
What's actually true
How this shows up on the exam
Expect a system mixing volatile and stable data in one index, with stale answers to the volatile queries. The reliable reading is to serve static knowledge from a refreshed index and route live-state data to a direct tool call, keeping the paths separate. This knowledge point builds on retrieval method selection by data shape, echoes the staleness risk of prompt caching, relates to monitoring retrieval quality, and feeds the scenario-matching capstone.
A banking assistant serves both current account balances and overdraft-fee policy from one nightly-refreshed index, and balances are sometimes wrong. What is the correct redesign?
People also ask
What is the difference between live-state and static retrieval?
Why not serve a live balance from an index?
What happens if you mix live and static retrieval?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.