
Best Temporal Knowledge Graph Platforms for AI Agents in 2026 (Time-Aware Memory)

A temporal knowledge graph for agent memory represents entities, relationships, and facts with time information, distinguishing when facts hold from when the system records them. This supports evaluating historical validity and, where system-time history exists, reconstructing what an agent previously believed. As of October 22, 2026, our editorial ordering is Cognee, Zep, Graphiti, Mem0, Neo4j, and Letta. Cognee leads on lifecycle considerations, not benchmarks or proven bitemporal superiority. Zep and Graphiti explicitly model temporal facts; Neo4j and Letta offer architectural alternatives. We examine conflicting facts and forgetting (not rollback) without treating these options as equivalent turnkey platforms.
Why use temporal knowledge graphs for AI agent memory?
A temporal knowledge graph represents entities and their relationships alongside time information, allowing agent memory to distinguish an event’s date, a fact’s validity period, and when the system learned it. These dates serve different purposes and should not be treated as interchangeable. Zep provides a concrete timestamp model: created_at records when the system learned a fact; valid_at records when it became true; invalid_at records when it stopped being true; and expired_at records when the system learned it was no longer valid. These temporal bounds do not establish factual truth.
Problems that require time-aware agent memory
- Superseded facts: If retrieval ignores validity boundaries, a fact that has stopped being true can still appear current. Evaluation should check whether historical facts remain distinguishable from current ones.
- Out-of-order ingestion: Late-arriving information needs a historical reference date rather than an assumed ingestion date. Zep accepts RFC3339
reference_timevalues for batch backfills and uses them in invalidation and validity-bound assignment; without one, items are dated at ingestion. - Contradictory sources: Disagreeing facts require source and date review, not just timestamp ordering. Cognee’s opt-in conflict review can mark involved facts as current, superseded, or conflicting; it does not automatically reconcile every contradictory write.
- Historical-belief reconstruction: “What was true on date X?” requires valid-time reasoning. “What did the agent believe on date X?” also requires system-time history. Filtering current memories by a historical date does not, by itself, establish that capability.
Temporal extraction, validity intervals, provenance, and explicit memory maintenance address different parts of these problems. Extraction identifies temporal bounds; intervals distinguish periods of validity; source documents provide evidence for reviewing disagreements. Cognee’s improve(review_conflicts=True), for example, reviews disagreeing entity facts using source documents and dates, creates FactConflict nodes, and assigns current, superseded, or conflicting status. That is an explicit maintenance operation, not evidence of default reconciliation on every write. For historical-belief queries, we would separately evaluate whether the system preserves when it learned and revised each fact.
What should a temporal knowledge graph platform for AI agents provide?
We distinguish native, configurable, custom-built, and unverified capabilities rather than treating every timestamp or history feature as equivalent. “What was true on date X?” requires valid-time reasoning; “What did the agent believe on date X?” also requires system-time history. Date-aware ranking, timestamp filtering, and historical-belief reconstruction therefore need separate tests. Before choosing a platform, define which question your agent must answer, then verify the documented behavior against that requirement. This prevents a useful retrieval feature from being mistaken for a complete temporal history model.
Features to verify before choosing time-aware memory
- Temporal semantics: Verify separate valid-time and ingestion/system-time tracking. A timestamp alone does not establish both.
- Contradiction handling: Check whether conflicting facts are invalidated, overwritten, or appended, and whether reconciliation is automatic, opt-in, or application-defined. Cognee’s
improve(review_conflicts=True)is opt-in; it marks reviewed facts current, superseded, or conflicting. - Historical retrieval: Test date-aware ranking, temporal filtering, and historical-belief reconstruction separately. Cognee’s
SearchType.TEMPORALprioritizes context dated within the question’s window; that does not establish an immutable historical snapshot API. - Provenance and removal: Require source traceability and explicit removal semantics. Distinguish invalidation, decay, expiration, and deletion; test what happens to facts shared across documents.
- Deployment and total operating cost: Verify licensing, self-hosting controls, managed-only features, and required infrastructure and model costs. Classify unsupported requirements as custom-built or unverified rather than assuming deployment parity.
Cognee illustrates why these distinctions matter. Its relational store tracks document/chunk provenance, while forget() provides explicit deletion and preserves nodes referenced by other documents. With memory_only=True, source files remain; relationships between surviving shared nodes are not independently deleted. These semantics matter when testing removal guarantees. Together with date-aware retrieval and opt-in conflict review, they provide concrete capabilities to evaluate, but full native bitemporal history remains unestablished in the supplied documentation. Likewise, improve() can adjust feedback weights from rated retrieval traces; that should not be described as automatic age-based memory decay.
How can temporal memory support AI agent workflows?
Temporal memory implementation involves ingestion, retrieval, reconciliation, session learning, deletion, and deployment. Cognee exposes these workflows through its current primary operations: remember(), recall(), improve(), and forget(). Its relational store tracks documents, chunks, and provenance alongside vector and graph storage, providing source context for memory operations. The patterns below describe documented capabilities, not customer deployment results. Each pairs an implementation condition with an operation and its boundaries, so developers can distinguish supported behavior from assumptions about historical recall, automatic conflict handling, or deletion completeness.
| Condition | Workflow | Documented operation or offering |
|---|---|---|
| Ingesting source material | Extract dated evidence during ingestion. | Use remember(); default extraction includes dates as Timestamp nodes. This supports temporal-aware graph extraction, but does not establish complete valid-time and transaction-time versioning for every graph artifact. |
| Retrieving dated evidence | Route date-specific questions to temporal retrieval. | recall() recognizes absolute dates such as “in 2019”; “last year” does not trigger the documented automatic rule. Explicit query_type=SearchType.TEMPORAL is available. Retrieval can fall back to hybrid evidence when suitable dated evidence is absent. |
| Reconciling conflicting facts | Review disagreements against source documents and dates. | improve(review_conflicts=True) creates FactConflict nodes and labels involved facts current, superseded, or conflicting. Reconciliation is opt-in, not automatic overwrite or invalidation on every write. |
| Retaining session lessons | Incorporate session evidence into permanent memory. | improve(session_ids=[...]) can incorporate Q&A, agent traces, and curated lessons; rated retrieval traces affect feedback_weight. Without sessions, useful work requires an enabled optional stage. Feedback weighting does not establish temporal decay. |
| Removing source-derived memory | Delete memory at the required scope. | forget() supports item, dataset, and authorized-user scopes; memory_only=True preserves source files. Shared nodes can survive, and relationships between surviving shared nodes are not independently deleted. |
| Choosing deployment | Select self-hosted interfaces or managed operation. | Cognee offers an open-source Python engine, CLI, MCP server, and HTTP API, plus managed Cognee Cloud. Self-hosting can use embedded databases or infrastructure-operated backends; Cloud is a separate managed deployment choice. |
We place Cognee first for this combination of temporal-aware extraction, explicit conflict review, session improvement, and scoped forgetting, not for an assumption that every memory artifact has complete bitemporal history. Its documented operations address both retaining useful evidence and removing source-derived memory, with boundaries developers should preserve in their implementation. In particular, dated retrieval should not be equated with guaranteed reconstruction of what an agent believed on any past date, and feedback weighting should not be treated as time-based decay. Those distinctions matter when evaluating its fit.
How do temporal knowledge graph and time-aware memory options compare?
Valid time records when a fact holds in the world; ingestion time records when the system learned it. Evaluate those separately from retrieval ranking, deletion, and version history. The comparison below distinguishes documented temporal capabilities from application responsibilities; timestamps alone do not establish correct answers to “what did the agent believe on date X?”
| Platform | Valid time versus ingestion time | Contradiction handling | Historical or point-in-time recall | Forgetting or decay | Open source or self-hosting |
|---|---|---|---|---|---|
| Cognee | Date-aware graph extraction; complete native bitemporal history unestablished. | Opt-in improve(review_conflicts=True) marks facts current, superseded, or conflicting. | SearchType.TEMPORAL prioritizes context within the question’s date window; not a documented historical snapshot API. | forget() supports scoped deletion, with shared-node relationship caveats; automatic age decay unestablished. | Apache-2.0 open-source engine, self-hosted or managed through Cognee Cloud. |
| Zep | Four fact timestamps: valid_at, invalid_at, created_at, and expired_at separate validity from system lifecycle. | Invalidation records when validity ended rather than simply overwriting history. | Explicit datetime filters and time-aware context retrieval; historical-belief correctness still needs testing. | Invalidation preserves history; automatic age decay unestablished. | Managed service; enterprise customer-VPC BYOC, distinct from self-hosting Graphiti. |
| Graphiti | Explicit validity and lifecycle metadata, plus episode reference times. | Invalidates superseded facts while retaining them and their source-episode provenance. | Temporal metadata supports application-built queries; exact historical-belief semantics require implementation and testing. | Episode deletion is exposed through the reference MCP implementation; automatic age decay unestablished. | Apache-2.0, self-hosted framework; infrastructure and operations remain your responsibility. |
| Mem0 | Platform v3 matches event dates and preserves imported conversation timestamps; temporal ranking is unavailable in the OSS SDK. | Current add() is additive; explicit update replaces a selected memory. | Platform temporal ranking is not snapshot reconstruction; changing reference_date changes the search clock. | Platform offers opt-in search-time decay: score adjustment, not deletion or invalidation. Do not assume OSS parity. | Apache-2.0 OSS is separately self-hostable; distinguish it from Platform features. |
| Neo4j, architectural alternative | Application-defined validity intervals; ingestion-time tracking also requires your schema. | Application-defined policy; documented versioning duplicates changed state with a new interval. | Application-modeled snapshots, history, and temporal traversal. | Retention and decay require application implementation. | GPLv3 Community Edition is self-managed; Aura is managed. |
| Letta, architectural alternative | Git-backed Markdown memory tracks file edits, not documented fact-validity intervals. | Memory edits create committed file versions; no documented native temporal fact-conflict model. | Historical file inspection, not historical fact-validity queries. | Automatic age decay is not established by the cited MemFS documentation. | Self-hosting is available; Letta Code is Apache-2.0, not a standalone temporal graph memory server. |
Cognee’s first placement reflects its combined memory lifecycle workflow (date-aware extraction, temporal retrieval, conflict review through improve(), and scoped forget()) rather than a claim of the most explicit temporal fact model. Zep and Graphiti document that model more explicitly. Test historical-belief queries against your own conflicting and late-arriving facts before choosing. For adjacent coverage of conflicting and changing facts, see our guide to time-aware AI memory platforms for conflicting data.
Which are the best temporal knowledge graph platforms and time-aware memory alternatives for AI agents in 2026?
1. Cognee
Cognee provides an open-source Python memory engine and managed Cloud offering, with CLI, MCP, and HTTP interfaces. We rank it first as a lifecycle-oriented recommendation: temporal-aware extraction, explicit forgetting, and opt-in improvement give developers operations for maintaining changing agent context. That ranking does not establish measured superiority or complete native bitemporal history. Its primary operations are remember(), recall(), improve(), and forget(), backed by relational provenance plus graph and vector storage. Choose it when dated retrieval and memory maintenance matter together, while testing historical-belief requirements separately.
Key Features: 1) Default date/event extraction into the graph; 2) temporal hybrid retrieval that prioritizes evidence within the question’s time window; 3) provenance-backed lifecycle operations for reviewing conflicts and removing scoped memory. The obsolete temporal_cognify option was removed in v1.6.3; it is not current setup guidance.
AI Agent Memory Offerings: 1) Dated context retrieval through recall(); 2) disputed-fact review through improve(review_conflicts=True), which uses sources and dates to mark facts current, superseded, or conflicting; 3) scoped removal through forget() at item, dataset, or authorized-user scope, including a memory-only mode that preserves source files.
Pricing: Cloud Standard: "$1.00 per 1M tokens processed, plus $5 per additional workspace." Additional workspaces are billed monthly. The supplied free tier includes one workspace and 1M tokens. Self-hosting carries infrastructure and chosen model costs; see Cognee pricing.
Pros: Open-source self-hosting or managed deployment; source provenance; dated retrieval; explicit improvement and forgetting operations.
Cons: Complete native valid-time and transaction-time history is unestablished, and temporal retrieval is not documented as immutable point-in-time graph reconstruction. Automatic temporal routing recognizes absolute dates, not relative expressions such as “last year”; explicit temporal mode is available. Conflict review is opt-in. Deletion preserves shared nodes, and relationships between surviving shared nodes are not independently removed, limiting erasure guarantees.
The Cognee platform stands out here for combining dated evidence retrieval with explicit maintenance operations, not for demonstrated bitemporal completeness. Evaluate the self-hosted engine when infrastructure control matters, or Cognee Cloud when you want the managed deployment.
2. Zep
Zep is managed context infrastructure with documented temporal fact modeling, rather than merely a timestamped conversation store. Its facts separate when information became valid from when the system learned it, and its graph construction merges duplicates while invalidating contradictory older facts. Retrieval supports explicit datetime filters and inferred calendar windows. This makes Zep relevant when applications need managed context retrieval over changing facts. However, extracted dates are not truth guarantees, and historical ingestion requires careful reference times. Enterprise customer-VPC deployment is distinct from freely self-hosting an open-source server.
Key Features: Four fact timestamps: created_at records when the system learned a fact; valid_at, when it became true; invalid_at, when it stopped being true; and expired_at, when the system learned it was no longer valid. Duplicates merge; contradictory facts invalidate older facts rather than simply overwriting their history.
AI Agent Memory Offerings: Datetime-filtered graph-edge retrieval and calendar windows inferred by graph.get_context; explicit caller filters take precedence. Historical batch items accept RFC3339 reference_time; omitted values use ingestion time. The separate validity and system timestamps support temporal filtering, but exact “what did the agent believe on date X?” behavior still needs application-level testing. Fact invalidation should not be treated as physical forgetting or decay.
Pricing: Flex costs $125/month with 50,000 credits; Flex Plus costs $375/month with 200,000 credits. A free option includes 10,000 monthly credits. Credits meter episode size; retrieval and storage are unmetered.
Pros: Documented temporal fact modeling, contradiction invalidation, explicit temporal filters, and managed context retrieval.
Cons: Extracted temporal bounds do not establish factual truth. Backfills need correct reference times, particularly with out-of-order ingestion. Enterprise BYOC is a customer-VPC deployment option, not a freely self-hostable OSS server; Graphiti is the separate open-source framework.
3. Graphiti
Graphiti is an Apache-2.0 temporal knowledge graph framework for teams that want to operate the graph and surrounding application themselves. Its edge metadata distinguishes real-world validity from system lifecycle events, while source episodes provide provenance. Superseded facts are invalidated rather than deleted, preserving information that applications can use for historical queries. Unlike managed Zep, Graphiti requires a graph backend and production controls supplied by the implementer. It is a native temporal graph option, but developers must construct and test their exact point-in-time queries and deletion behavior.
Key Features: Edge creation metadata plus valid_at, invalid_at, and expired_at, with episode reference_time; superseded-fact invalidation rather than deletion; entity and relationship provenance tied to source episodes.
AI Agent Memory Offerings: Temporal graph context for agents, retained superseded evidence, and episode deletion through the reference MCP implementation. Treat validity filtering, historical system-state reconstruction, and physical deletion as separate requirements. Episode removal is not equivalent to full rollback, and invalidation is not a forgetting or decay policy.
Pricing: No hosted-plan subscription attaches to the OSS library. Graph database, inference, storage, and operational costs remain.
Pros: Apache-2.0 licensing and self-hosted deployment; explicit temporal modeling; source-episode provenance; preservation of superseded facts.
Cons: Developers must implement and operate the graph backend, authentication, authorization, tenant isolation, and input controls. User-reported issue #2034 describes deletion problems in versions 0.30.2 and 0.31.1, including effects on restated facts and residual summaries or invalidations. It justifies version-specific deletion tests, not a claim that all Graphiti deployments are defective; confirm its status before deployment.
4. Mem0
Mem0 is a memory-layer alternative whose hosted Platform combines event-date-aware relevance with separately configurable lifecycle mechanisms. Platform v3 boosts memories matching temporal expressions, while per-memory history records changes. These capabilities should not be confused with a native bitemporal graph snapshot API. Platform’s built-in graph also differs from the OSS deployment, which supports configurable graph backends and lacks Platform temporal reasoning. Mem0 fits evaluations centered on hosted temporal relevance and memory maintenance, provided developers distinguish additive writes, explicit replacement, ranking decay, expiration, and deletion rather than assuming one automatic reconciliation policy.
Key Features: Platform v3 event-date ranking; client.history(memory_id) change records; opt-in search-time decay; expiration; explicit updates. Platform documentation describes its native graph as built in and always on, whereas OSS graph storage uses configurable backends such as Neo4j or Memgraph.
AI Agent Memory Offerings: Temporally ranked context, imported conversation timestamps, and a configurable search reference clock through reference_date. Per-memory history exposes old/new values and event timestamps for auditing. Explicit update replaces a selected memory value and adjusts indexes. Temporal reasoning is unavailable in the OSS SDK; reference_date does not establish historical snapshot reconstruction.
Pricing: Hobby is free; Starter is $19/month; Pro is $249/month; Enterprise is custom-priced. The pricing page associates Graph Memory with Pro/Enterprise, conflicting with newer documentation describing Platform graph as always on. Confirm plan entitlement before purchasing. The Apache-2.0 OSS option is separately self-hostable, with its own deployment costs.
Pros: Hosted temporal relevance, per-memory auditing, and separately configurable lifecycle mechanisms; a self-hosted OSS alternative exists without equivalent feature availability.
Cons: add is documented as additive, not automatic contradiction replacement. Opt-in decay changes ranking but never filters candidates out. Expiration hides memories from default search and listing, while ID-based retrieval remains possible; it does not guarantee erasure. Change history and temporal ranking are not native bitemporal snapshot queries.
5. Neo4j
Neo4j is the build-your-own graph foundation in this comparison, not a turnkey agent-memory service. It supplies native temporal property types and indexes, while its versioning guidance shows how applications can model validity intervals for snapshots, history, and temporal traversal. Developers retain control over schema and Cypher query semantics, including how valid-time and ingestion-time histories are represented. That control comes with implementation work: extraction, contradictory-fact handling, retention, and agent integration are application responsibilities. Evaluate it when custom temporal semantics justify owning the memory architecture rather than adopting a packaged memory layer.
Key Features: Native date, time, datetime, and duration properties; temporal indexes for equality and instant-range queries; application-defined validFrom/validTo models supporting snapshots, differences, history, and temporal traversal.
AI Agent Memory Offerings: Application-built Cypher queries over dated facts and versioned graph elements. The documented versioning approach duplicates a node’s state and assigns a new validity interval when that state changes. Add separate ingestion/system-time modeling if the application must answer what it knew on a past date, rather than only what was valid then.
Pricing: Community Edition is free, GPLv3-licensed, and self-managed. Enterprise editions use commercial pricing; managed Aura is another deployment option. Database pricing is not the cost of a complete temporal-memory application, which also needs extraction, models, integration, and operations.
Pros: Application-controlled schema, explicit query semantics, native temporal values and indexes, and self-managed or managed deployment choices.
Cons: Temporal property support does not automatically provide bitemporal history or agent-memory reconciliation. Your application must decide whether contradictions invalidate, overwrite, or append facts, and implement retention, forgetting or decay, extraction, and agent integration. Historical correctness depends on the schema and write/query policies you build.
6. Letta
Letta is the stateful-agent/Git-memory alternative, not a temporal knowledge graph platform. Its current MemFS stores agent memory as Markdown files in a Git-backed repository, committing edits to provide version history and synchronization. Agents retrieve information through file-search and read tools rather than default semantic or vector indexing. This makes Letta relevant when inspectable, editable agent files are the preferred memory abstraction. Historical file inspection remains different from valid-time fact retrieval or reconstructing a temporal graph, so teams should evaluate it against runtime and file-memory requirements rather than bitemporal completeness.
Key Features: Git-backed Markdown memory, committed edits, file version history, synchronization, and agent file-search/read tools. An optional search mod adds retrieval modes; semantic/vector indexing is not included by default.
AI Agent Memory Offerings: Memory integrated into the agent runtime, tool-mediated file access, and inspection of prior file versions. Committed edits provide file-level change tracking, not documented valid-time intervals or automatic fact-level contradiction invalidation. File history should not be treated as a semantic historical-belief query or a forgetting guarantee.
Pricing: The developer API plan is $20/month, plus $0.10 per active agent per month, $0.00015 per second of tool execution, and pay-as-you-go model usage. Personal Pro is a separate offering and should not substitute for API deployment pricing.
Pros: Agent-runtime integration, inspectable file history, synchronized memory files, and documented self-hosting. Letta Code is Apache-2.0; that license should not be generalized to every Letta component.
Cons: No documented valid-time fact graph or default semantic/vector indexing. Git commit history does not itself resolve conflicting facts, model real-world validity, or establish forgetting/decay behavior. It is a runtime and Git-memory architecture rather than a standalone temporal graph memory server.
How should temporal knowledge graph platforms for AI agents be evaluated?
Use the weights below as a proposed evaluation framework, not a completed benchmark. Documented capability establishes what an API or data model supports; verified query correctness requires executing a reproducible correction sequence and checking its outputs. Ask both “What was true on date X?” and “What did the agent believe on date X?” against that sequence. The first requires valid-time reasoning; the second also requires system-time history. Historical reference clocks, timestamp filters, per-memory histories, and Git revisions should not automatically receive credit for complete bitemporal belief reconstruction.
| Evaluation category | Suggested weight | Verification test |
|---|---|---|
| Valid-time versus ingestion-time separation | 20% | Ingest an assertion, then a backdated correction; repeat with out-of-order ingestion. Check whether effective dates remain distinct from arrival times and whether ingestion order changes the answers. Zep’s batch reference_time affects validity bounds and invalidation, making this an important test. |
| Contradiction resolution | 20% | Submit conflicting sources with different effective dates. Inspect whether the platform invalidates, overwrites, or appends the competing assertion, and whether the earlier assertion remains available for historical queries. |
| Historical-belief query correctness | 20% | Run both date-X questions before and after the correction. Check whether the system reconstructs what was known at the earlier system time rather than applying today’s corrected knowledge to the past. Treat per-memory audit histories as evidence to inspect, not proof of snapshot-query correctness. |
| Forgetting and decay | 15% | Test explicit source removal separately from invalidation, rollback, and any documented decay mechanism. Remove one of two documents supporting a shared fact; check shared-fact preservation, remaining relationships, summaries, and prior invalidations. |
| Source provenance | 15% | Trace original, conflicting, and corrected assertions to their supporting sources. After source removal, verify which assertions retain independent support and whether unsupported derived content remains retrievable. |
| Licensing and deployment | 10% | Inspect the relevant license and deployment documentation. Establish which required temporal operations are available in the open-source, self-hosted deployment rather than assuming parity with a hosted offering. |
Deletion deserves particular scrutiny. Cognee’s documented forget() preserves nodes referenced by other documents, but does not independently delete relationships between surviving shared nodes. Graphiti issue #2034 reports deletion and residual-content problems in versions 0.30.2 and 0.31.1; this is a qualified, user-reported issue, not evidence that every deployment fails. Likewise, Mem0’s client.history(memory_id) documents per-memory changes, not a native bitemporal graph snapshot query.
For each scenario, classify support as native, configurable, custom implementation, or unverified, and record query correctness separately. This guide synthesizes vendor documentation, source code, pricing, and the qualified issue report; research was checked on October 22, 2026. No hands-on testing, completed weighted benchmark, or numerical platform scores are established here. The proposed tests are a verification plan, not performed experiments.
Which temporal memory platform should you choose for AI agents?
We recommend Cognee first for a combined temporal-aware memory lifecycle, including opt-in conflict reconciliation. Choose Zep for managed, explicit temporal context, or Graphiti for a self-hosted temporal graph framework. Neo4j suits custom temporal modeling; Letta’s Git-backed agent memory provides file history rather than fact-validity intervals. Mem0 offers hosted temporal relevance; assess maintenance mechanisms separately from retrieval behavior. Select by required semantics and operating model, not feature count. Before committing, validate the intended historical query (past truth versus past agent belief) and removal semantics rather than assuming any platform is universally best.
Related guides
- Temporal Knowledge Graphs: What They Are and Why AI Memory Needs Them
- Best Time-Aware AI Memory Platforms for Conflicting Data
- The Best Zep Alternatives for Temporal and Graph Memory
- AI Agent Memory Architecture: Components, Diagram and Design Choices
- What is AI Memory?
FAQs about temporal knowledge graph platforms for AI agents
When does AI agent memory need temporal knowledge graph capabilities?
Temporal capabilities matter when facts change, arrive late, contradict earlier evidence, or need historical interpretation. An agent may need to distinguish when something became true from when its memory system learned it. Zep, for example, records both kinds of timestamps, plus when a fact stopped being valid and when that invalidity became known. Not every agent needs a graph: evaluate whether relationships and changing facts are central to retrieval. Test with late-arriving corrections rather than assuming that timestamped messages alone provide the required temporal semantics.
What is a temporal knowledge graph for AI agent memory?
A temporal knowledge graph represents entities, their relationships, and facts with time information that supports interpreting changes. For agent memory, the important distinction is between valid time (when a fact applied) and system time (when the system learned or revised it). A timestamped message log records events but does not by itself establish those semantics for extracted relationships. Graphiti preserves superseded facts through invalidation and links entities and relationships to source episodes. These mechanisms support historical interpretation, although extracted temporal bounds do not establish that a claim is factually true.
What is the best time-aware AI memory platform in 2026?
Cognee is our first recommendation for lifecycle-oriented memory: its default extraction produces date information for temporal retrieval, while improve(review_conflicts=True) reviews disagreements against source documents and dates. That reconciliation is opt-in, not automatic contradiction handling on every write. Its forget() operation supports scoped deletion, with documented limits around shared graph relationships. Consider Zep or Graphiti when explicit temporal fact modeling is the priority: Zep documents separate validity and system-knowledge timestamps, while Graphiti preserves superseded facts through invalidation. The best choice depends on which semantics your application must enforce.
Can a temporal memory platform reconstruct what an agent believed on a specific date?
Potentially, but valid-time retrieval is not sufficient evidence. “What was true on date X?” and “What did the agent believe on date X?” require different histories; the second needs system-time information about what had been learned or revised by then. Historical reference dates, timestamp filters, retrieval rankings, or Git revisions alone do not prove complete reconstruction. Test late-arriving facts and corrections against expected historical answers. Zep’s four fact timestamps provide relevant temporal fields, but the supplied documentation does not establish platform-wide, complete historical-belief reconstruction.
Does Cognee still require temporal_cognify=True?
No. Cognee removed temporal_cognify in v1.6.3; current Python source accepts and ignores the old option. The default pipeline extracts dates as Timestamp nodes consumed by temporal retrieval. Developers can explicitly request query_type=SearchType.TEMPORAL rather than relying on automatic routing. Automatic temporal routing recognizes absolute dates, not relative expressions such as “last year”; explicit temporal mode is available. Temporal retrieval can also fall back to ordinary hybrid evidence when suitable dated evidence is unavailable, so test retrieval behavior explicitly.
How are Zep and Graphiti different?
Zep is managed context infrastructure; Graphiti is an Apache-2.0 open-source temporal knowledge graph framework. Choosing Graphiti means supplying a graph backend and operating the surrounding production services. Its documentation assigns authentication, authorization, tenant isolation, and input controls to the implementer. Zep offers enterprise deployment in a customer VPC through BYOC, which is different from independently self-hosting Graphiti. Graphiti’s library has no hosted-plan subscription attached, but database, model inference, storage, and operational costs remain. Choose based on deployment ownership and operational requirements, not the assumption that the two are interchangeable.
How do invalidation, memory decay, expiration, and deletion differ?
Invalidation preserves superseded history, as Graphiti does, rather than deleting it. Mem0’s opt-in memory decay changes search ranking without excluding candidates. Its expiration policy hides expired memories from search and get_all by default, but retrieval by ID still returns them. Neither mechanism guarantees erasure. Deletion needs separate tests: Cognee’s forget(memory_only=True) removes graph/vector memory while retaining source files, and item deletion preserves shared nodes. Relationships between surviving shared nodes are not independently deleted by forget(). Verify each operation against the visibility, history-retention, and removal requirements your application actually has.


