Context engineering
Time-aware context is the missing layer in LLM context engineering.
Many teams focus on retrieval, prompts, and generic memory. Fewer treat time as a first-class serving primitive. That is the opportunity: agents need to know when facts were true, what changed, what expired, what remains open, what was already tried, and which context can be reused safely.
Why it matters
Output quality is decided before the prompt is written.
LLM output quality depends on the context that enters the prompt. If that context is stale, duplicated, unauthorized, or missing recent events, the model can sound confident while doing the wrong thing. Time-aware context gives the application a way to assemble a prompt based on validity, freshness, sequence, and replay — not just semantic similarity.
What it buys you
- Better answers — prompts include current facts, open commitments, recent failures, and the latest source version.
- Fewer wasted tokens — expired summaries, superseded memories, and repeated tool failures are filtered before assembly.
- Safer agents — permissions, policy windows, and approvals are checked against the time of the request.
- Replayable behavior — reconstruct exactly what the model saw, then test new prompts and models against the same context pack.
What it includes
Five questions similarity search cannot answer.
| Context question | Why it helps | Example |
|---|---|---|
| When was this true? | Prevents old facts from overriding current state. | Use the policy version active when the customer asked. |
| What changed? | Highlights deltas instead of resending every fact. | Only include account changes since the last agent turn. |
| What is still open? | Keeps commitments and unfinished tasks visible. | Remind the model about an unresolved refund promise. |
| What was already tried? | Reduces repeated actions and user frustration. | Do not suggest the troubleshooting step that failed yesterday. |
| What can be reused? | Improves token and runtime-cache efficiency. | Reuse stable policy sections while refreshing volatile timeline state. |
Serving semantics
Time-aware context is more than a timestamp column.
The serving layer needs predictable query semantics so prompt assembly stays correct under latency and token-budget pressure. TemporalStore treats context as bounded typed records: nodes, events, index refs, dirty summary markers, and context-pack audits.
- End-time inclusive — a request through “now” includes events at the end timestamp, matching how users expect windows to work.
- Returned-result limits — limits cap matching records, not raw scanned rows, so early nonmatches never hide later valid context.
- Declared filters — status, scope, actor, or type filters compile into indexes rather than hot-path JSON scans.
- Async summaries — event writes stay fast; summary refresh is marked dirty and processed outside the request path.
resolve_time(fact) picks, in order:
1. event_time // when it happened
2. ingest_time // when we indexed it
3. valid_time // when it starts/stops being true
4. source_time // when the source object changed
// LLM extraction only as a last resort,
// with validation and a confidence score.Token savings
Send the smallest valid state, not more background.
Without time-aware context, applications stuff prompts with broad summaries, duplicate retrieval chunks, raw history, and disclaimers because they cannot tell which pieces are current. A time-aware layer sends smaller, sharper context packs and marks stable sections that a runtime cache can reuse. Prompt engineering shifts from “paste more background” to “send the smallest valid state for this request.”
prompt context before:
"Here is the account summary, ticket history,
policy docs, and previous messages..." // large, mostly stale
prompt context with TemporalStore:
latest_valid_facts
changes_since_last_turn
open_commitments
already_tried_and_failed
stale_or_blocked_context // excluded, not pasted
stable_sections_for_cache_reuseWhere it fits
TemporalStore first; hot state and truth as needed.
Most context-engineering use cases start with timelines, freshness, replay, latest values, and prompt-ready memory. Hot state and strong consistency are added only when the workload demands them.
Start on the open-source temporal engine. Add Enterprise MatrixDB for hot state at scale and MatrixKV only when a small set of records needs transactional, strongly consistent truth.
Keep reading