Skip to main content
A minimal comparison of two agent-memory patterns: one agent that remembers the active session and one agent that only reads from the persistent knowledge graph. Before you start:
  • Complete Quickstart or have Cognee installed and configured
  • Ensure you have LLM Providers configured
  • Be familiar with the remember() workflow
  • Keep caching enabled — it is on by default, and the session options used below require it:
with_session_memory, save_session_traces, and persist_session_trace_after all read and write the session cache. With CACHING=false, the decorator raises a validation error as soon as it is applied — not when the function is called. The with_memory (graph retrieval) path works without caching.

Shared Setup

Both agents use the same LLMGateway helper. The updated example starts clean with forget(everything=True), stores one baseline fact with remember(), and then compares session memory against graph memory. LLMGateway.acreate_structured_output() automatically picks up whatever memory the decorator retrieved and prepends it to the text input. In this flow, save_session_traces=True records each of the support agent’s turns into the session cache, and persist_session_trace_after=3 is what bridges those traces into the knowledge graph.

Compare the Agents

This agent relies on session memory instead of graph retrieval. It can remember the recent conversation, and after enough turns its saved traces are persisted into the knowledge graph.

From Session Traces to the Permanent Graph

The two agents above read from different places, so it helps to know which store each parameter touches: save_session_traces=True alone keeps traces in the session cache, where only with_session_memory can see them. Adding persist_session_trace_after=N is what bridges them into the permanent graph: after every Nth trace step in the session, Cognee runs a memify pass that writes the trace summaries into dataset_name under the agent_trace_feedbacks node set. That is why faq_bot — which reads only the graph — answers correctly only after support_agent has taken three turns.
Trace persistence is best-effort: failures are logged and never propagate out of your agent function. See the decorator parameters for the options that control what gets persisted and where.

Full Example

The decorator does not create memory by itself. The example works because baseline graph memory is stored first with remember(), and the session-aware support agent persists traces only after those conversation turns happen.

Agent Memory Decorator

Concept overview and parameter reference

Low-Level LLM

LLMGateway for direct model calls

Remember

Store memory before using the decorator

Sessions

Learn how trace-backed session context behaves