Use Case
I'm building agents on Hindsight that need to reason about when things happen, not just what happened. A lot of the useful structure in my agents' memory is recurring: a user who tends to do something on certain weekdays, events that cluster at month-end, behavior that shifts with the season. My goal is for the agent to recall and act on those recurring patterns the same way it already recalls topics and entities. When I went looking for how to query memory by recurring time patterns, and by specific datetimes and date ranges, I found Hindsight resolves the time side differently than I expected.
Problem Statement
Hindsight has no way to recall memories by a recurring temporal pattern. Every time-based query resolves to a single absolute date or date range, since the recall path runs the query through a date parser that returns one (start, end) window. So there's no way to express "happens on Fridays," "around month-end," or "every December," and there's no first-class representation of recurrence on a memory, which means the system can't record or learn that something repeats. For an agent whose value comes from learning patterns over time, recurring temporal structure is currently invisible.
How This Feature Would Help
Without it, the temporal logic gets pushed up into my application. I have to tag recurrence myself at write time and post-filter recall results, which duplicates work across every app I build and can't benefit from Hindsight's ranking and fusion. Native support would let the agent ask for recurring patterns directly and let Hindsight surface periodicity as a learned fact. That sits squarely with the "learning, not just remembering" goal, since an agent that knows "this happens weekly" is doing more than replaying four timestamps.
Proposed Solution
Sharing how I'd picture it, though you may well have a better shape in mind.
Three pieces that build on each other:
-
Cyclic temporal dimensions. Derive and store a few cyclic positions from each memory's timestamp (day-of-week, month, quarter, week-of-year, day-of-month, day-of-year, hour-of-day) alongside the absolute timestamp you already keep. At recall, score a queried position with a weighting centered on that position and fuse it into the existing rank step, so "Fridays" or "around the 1st" lights up the right memories.
-
Deterministic-first temporal resolution. Resolve "every Tuesday," "last month," and explicit ranges with calendar arithmetic before reaching for the model, falling back to the model only for ambiguous phrasing. This is cheaper and faster on the temporal path you already run, and it sidesteps the date-arithmetic mistakes models tend to make.
-
A recurring-pattern signal in reflect/consolidation. Let the memory layer record "this recurs weekly/monthly" as a first-class observation or relationship, seeded from memories that share a cyclic position and look similar, so recurrence becomes something the agent learns rather than something I compute outside.
A smaller refinement that pairs well: widen the temporal weighting for older memories, so a still-relevant six-month-old memory isn't buried under last week's.
Alternatives Considered
Tag and filter in my app: store recurrence flags at retain time and post-filter recall output client-side. It works, but it spreads temporal logic across every app I build and doesn't get Hindsight's ranking or fusion.
Pre-resolve to a single window before calling recall, which is effectively what the current analyzer pushes me toward. This loses the pattern itself and gets brittle fast for anything periodic.
Bolt on a separate scheduler or time-series store for the recurrence part. This splits memory across two systems and breaks unified recall and ranking.
I also reviewed an open-source project (ctx, MPL-2.0) that implements all three pieces above. I'm citing it only as prior art that the approach is workable. This isn't a request to reuse its code, and I'd expect any Hindsight implementation to be built independently.
Priority
Critical - blocking my use case
Additional Context
A few concrete examples of the recall queries I'd want an agent to be able to make:
- "What does this user usually do on Friday afternoons?"
- "What tends to come up around month-end?"
- "Show me what happened the last few Decembers."
- "Has this kind of event been recurring, and how often?"
Today these either return a single recent window or nothing useful, because the query collapses to one absolute date range.
If it helps with scoping, as of v0.8.2 the relevant spot looks to be the recall path's temporal handling: engine/search/temporal_extraction.py (via the DateparserQueryAnalyzer in engine/query_analyzer.py) resolves a query to a single (start, end) window, and there's no cyclic position stored on a memory to match a recurring query against. The recurring-pattern signal from piece 3 would most naturally live alongside the existing derived observations in reflect/consolidation, which already has the machinery for that kind of fact.
I checked this against v0.8.2 (latest, shipped 12 Jun 2026) and the time/search engine is untouched there, so this isn't already solved. v0.8.2 did ship reversible curation (manual edit, invalidate, revert of memory units), which is adjacent: it's manual control over the memory lifecycle, where this request is the automatic, time-aware side of the same area. Felt like a natural moment to raise it.
The ctx project referenced under Alternatives implements all three pieces, if a concrete reference implementation is useful to look at.
Checklist
Use Case
I'm building agents on Hindsight that need to reason about when things happen, not just what happened. A lot of the useful structure in my agents' memory is recurring: a user who tends to do something on certain weekdays, events that cluster at month-end, behavior that shifts with the season. My goal is for the agent to recall and act on those recurring patterns the same way it already recalls topics and entities. When I went looking for how to query memory by recurring time patterns, and by specific datetimes and date ranges, I found Hindsight resolves the time side differently than I expected.
Problem Statement
Hindsight has no way to recall memories by a recurring temporal pattern. Every time-based query resolves to a single absolute date or date range, since the recall path runs the query through a date parser that returns one (start, end) window. So there's no way to express "happens on Fridays," "around month-end," or "every December," and there's no first-class representation of recurrence on a memory, which means the system can't record or learn that something repeats. For an agent whose value comes from learning patterns over time, recurring temporal structure is currently invisible.
How This Feature Would Help
Without it, the temporal logic gets pushed up into my application. I have to tag recurrence myself at write time and post-filter recall results, which duplicates work across every app I build and can't benefit from Hindsight's ranking and fusion. Native support would let the agent ask for recurring patterns directly and let Hindsight surface periodicity as a learned fact. That sits squarely with the "learning, not just remembering" goal, since an agent that knows "this happens weekly" is doing more than replaying four timestamps.
Proposed Solution
Sharing how I'd picture it, though you may well have a better shape in mind.
Three pieces that build on each other:
Cyclic temporal dimensions. Derive and store a few cyclic positions from each memory's timestamp (day-of-week, month, quarter, week-of-year, day-of-month, day-of-year, hour-of-day) alongside the absolute timestamp you already keep. At recall, score a queried position with a weighting centered on that position and fuse it into the existing rank step, so "Fridays" or "around the 1st" lights up the right memories.
Deterministic-first temporal resolution. Resolve "every Tuesday," "last month," and explicit ranges with calendar arithmetic before reaching for the model, falling back to the model only for ambiguous phrasing. This is cheaper and faster on the temporal path you already run, and it sidesteps the date-arithmetic mistakes models tend to make.
A recurring-pattern signal in reflect/consolidation. Let the memory layer record "this recurs weekly/monthly" as a first-class observation or relationship, seeded from memories that share a cyclic position and look similar, so recurrence becomes something the agent learns rather than something I compute outside.
A smaller refinement that pairs well: widen the temporal weighting for older memories, so a still-relevant six-month-old memory isn't buried under last week's.
Alternatives Considered
Tag and filter in my app: store recurrence flags at retain time and post-filter recall output client-side. It works, but it spreads temporal logic across every app I build and doesn't get Hindsight's ranking or fusion.
Pre-resolve to a single window before calling recall, which is effectively what the current analyzer pushes me toward. This loses the pattern itself and gets brittle fast for anything periodic.
Bolt on a separate scheduler or time-series store for the recurrence part. This splits memory across two systems and breaks unified recall and ranking.
I also reviewed an open-source project (ctx, MPL-2.0) that implements all three pieces above. I'm citing it only as prior art that the approach is workable. This isn't a request to reuse its code, and I'd expect any Hindsight implementation to be built independently.
Priority
Critical - blocking my use case
Additional Context
A few concrete examples of the recall queries I'd want an agent to be able to make:
Today these either return a single recent window or nothing useful, because the query collapses to one absolute date range.
If it helps with scoping, as of v0.8.2 the relevant spot looks to be the recall path's temporal handling:
engine/search/temporal_extraction.py(via theDateparserQueryAnalyzerinengine/query_analyzer.py) resolves a query to a single(start, end)window, and there's no cyclic position stored on a memory to match a recurring query against. The recurring-pattern signal from piece 3 would most naturally live alongside the existing derived observations in reflect/consolidation, which already has the machinery for that kind of fact.I checked this against v0.8.2 (latest, shipped 12 Jun 2026) and the time/search engine is untouched there, so this isn't already solved. v0.8.2 did ship reversible curation (manual edit, invalidate, revert of memory units), which is adjacent: it's manual control over the memory lifecycle, where this request is the automatic, time-aware side of the same area. Felt like a natural moment to raise it.
The ctx project referenced under Alternatives implements all three pieces, if a concrete reference implementation is useful to look at.
Checklist