Knowledge cutoffs & the model's missing clock.
A model has no clock: ask it today's date and it guesses, ask it for the latest version of anything and it answers with what was true when its training data was collected. The part that catches experienced teams is subtler — knowledge of the months just before the cutoff is far thinner than knowledge of two years earlier, because the internet had not finished writing about them yet.
The cutoff is a gradient, not a wall.
Training data is a snapshot of text that existed when it was collected. But the writing about any event — documentation, tutorials, arguments, corrections, follow-up analysis — accumulates for months and years afterwards. A snapshot taken shortly after an event captures the announcement and almost none of the understanding.
- Recency means thin, not absent. A model may recognise a library released just before its cutoff, know its name and rough purpose, and have essentially no reliable detail about its API. That is a more dangerous state than not knowing it at all, because it produces confident, specific, wrong output.
- The reverse also holds. Knowledge of a stable topic from several years earlier is dense, cross-checked, and usually excellent.
- Do not ask the model for its own cutoff. The date is not a fact it was trained on; it infers it, and it infers it badly — often guessing early, because that is when its evidence thins out. Read it from the provider's documentation instead.
- Post-training moves the line too. Behaviour and knowledge can shift between minor versions of the same model family — see post-training.
"Its cutoff is recent, so it knows about X" is the wrong inference. The right one is: the closer a topic sits to the cutoff, the more the model's confidence outruns its evidence — and the more you should be retrieving rather than recalling.
No clock, and the arithmetic that follows.
A model receives text, not a timestamp. Absent one, "next Tuesday", "how old is this contract", and "is this still under warranty" are all computed against an imagined present — and the answers come back internally consistent and wrong, which is the hardest kind to notice.
- Inject the current date and timezone on every request. One line in the system prompt eliminates an entire class of bug. Timezone matters more than it looks: an agent that books, schedules, or expires things across regions has two clocks to get wrong.
- Put it at the very end of the prompt. A timestamp is volatile content, and volatile content at the top of a system prompt invalidates the cacheable prefix on every single call — a costly way to fix a cheap problem. See prompt caching.
- Give it a date tool rather than mental arithmetic. Business-day counts, month-end rollovers, and timezone conversion are jobs for code, and a tool result is auditable in a way a chain of reasoning is not.
- Stamp relative language out of stored memory. "Last quarter" written into a long-term memory becomes false the moment the quarter turns. Store absolute dates; render relative ones.
Agents convert stale beliefs into actions.
In a chat interface, an outdated fact is a sentence a human reads and discounts. In an agent loop, it is a tool call — and stale procedural knowledge is far more damaging than a stale fact, because it looks exactly like competence.
- The characteristic failures are versioned surfaces. A removed API parameter, a renamed CLI flag, a library whose default changed, a config key that moved. The agent writes the call, it fails, and if the error message is unhelpful the agent retries the same wrong thing.
- Prefer reading over recalling. The environment is ground truth and it is cheap to consult: run
--help, open the actual config file, request the schema. One extra tool call beats a plausible hallucination and a failed run. - Error messages must name the valid options. "Invalid parameter" leaves the model guessing from memory — which is precisely the memory that is out of date. "Invalid parameter
foo; valid:bar,baz" ends the loop in one step; see designing tools for agents. - Pin what you can. If the agent works against a versioned dependency, put the version in the context. Guessing which major version is installed is not a task a model can succeed at.
Make freshness a routing decision, not a disclaimer.
The fix is not a warning appended to the answer. It is deciding, at design time, which questions are time-sensitive and forcing those down a path that reads current data.
- Classify by question, not by confidence. Prices, availability, versions, people in roles, laws, anything phrased with "current" or "latest" — these route to retrieval unconditionally. Do not gate this on the model reporting uncertainty; it is not reliable at knowing what it does not know.
- Grounding converts recall into reading. Putting the current document in context turns a memory question into a comprehension question, which models are far better at — see hallucination and grounding.
- Timestamp retrieved documents in the context. Handed two contradictory passages with no dates, the model has no principled way to choose, and will often merge them. Dates let you instruct it to prefer the newer.
- Watch your own index's cutoff. A RAG system crawled six months ago has recreated the exact problem you adopted it to solve — except this cutoff is yours, and you can fix it.
Two changes cover most of this: inject the current date at the end of your system prompt on every request, and make anything versioned — API surfaces, config formats, CLI flags — something the agent reads from the environment rather than recalls from training. Then put your retrieval index's freshness on the same review schedule as your model version. The cutoff you inherited from a provider is easy to remember; the one you built yourself is the one that quietly ages.
Related: hallucination & grounding for why confident invention is structural, RAG for the retrieval path, and choosing a model for where the cutoff belongs on the checklist.