Supermemory-tutorial: Voeg permanente geheugen toe aan AI-agents

Wat is Supermemory?

Supermemory laat zich het best omschrijven als een AI-geheugen-API voor agents. Wanneer je Supermemory strings over je gebruiker aanreikt, geeft het later een compact beeld terug van wie die gebruiker is en wat die onlangs heeft gedaan. Embedding, indexing en retrieval draaien allemaal binnen Supermemory, zodat je agentcode klein blijft.

De LongMemEval-benchmark test hoe goed een geheugensysteem vragen beantwoordt over een lange gespreksgeschiedenis. Supermemory herinnert zich 81,6% van de juiste feiten. Zep, het op één na beste systeem, scoort 71,2%: een kloof van 10 punten die neerkomt op ongeveer 1 extra goed antwoord per 10 gebruikersvragen. De open-source repository heeft 22k+ GitHub-sterren, nog een signaal van echt gebruik.

Memory vs RAG

De meeste lezers die naar een agentgeheugentool grijpen, hebben eerder RAG gebruikt. Het helpt om Supermemory ernaast te plaatsen. RAG en memory lossen verschillende problemen op en leven vaak in dezelfde agent.

Een RAG-systeem wijst naar een documenten-corpus dat de ontwikkelaar één keer voorbereidt. Producthandleidingen, supportartikelen, interne docs. Het corpus wordt bij deploy-time geladen, bij runtime bevraagd en verandert zelden. De agent gebruikt het om vragen te beantwoorden waar het product zelf het antwoord op weet.

Een geheugensysteem richt zich op de gebruiker. Supermemory schrijft gebruikersspecifieke feiten weg terwijl de agent met die gebruiker praat, en de store groeit met elk gesprek. De agent gebruikt het om vragen te beantwoorden die alleen de gebruiker kan beantwoorden, zoals voorkeuren, geschiedenis en recente activiteit.

In een echt product draaien de twee naast elkaar. RAG over een bedrijfskennisbank beantwoordt “wat is ons restitutiebeleid?”. Supermemory over de gebruiker beantwoordt: “Wat was mijn bench press vorige week?” Dezelfde agent, twee datastores, twee taken.

Gebruikersprofielen: statische en dynamische feiten

Het kernidee van Supermemory is het gebruikersprofiel. Elke log wordt gesorteerd in twee emmers: statische feiten die zelden veranderen, en dynamische feiten over actuele activiteit. Terugkerende patronen promoveren naar statisch. Recente activiteit blijft in dynamisch.

Wanneer de agent het profiel leest, geeft één call beide emmers plus de bijpassende memory-chunks terug.

De splitsing is belangrijk omdat statische en dynamische feiten verschillende vragen over dezelfde gebruiker beantwoorden:

Lees rij één. De statische kant zegt hoe de gebruiker traint: thuis, met de apparatuur die ze hebben. Dat verandert niet van week tot week. De dynamische kant zegt waar ze nu aan werken: bovenlichaam, deze cyclus.

Een workoutsuggester heeft beide nodig. De statische kant sluit alleen-gym-oefeningen uit, de dynamische kant kiest de sessie van vandaag.

Achter dat profiel doet Supermemory vier taken die je anders zelf zou bouwen. Het slaat ruwe herinneringen op, embedt elke chunk, draait similarity search bij het lezen en extraheert profielfeiten uit gelogde content. Geen van die vier verschijnt in je code.

Elke memory wordt getagd met een string die de ontwikkelaar kiest. Elke read geeft dezelfde string terug om te beperken wat eruit komt. De trainer hardcodeert één tag, omdat één gebruiker genoeg is om te laten zien wat het profiel doet. Echte apps berekenen de tag uit de geauthenticeerde gebruiker, zoals hun JWT.

Je Supermemory-omgeving instellen

De trainer heeft twee API-sleutels nodig (Supermemory en OpenAI) en een Python-project met drie dependencies. Een snelle round-trip-script bewijst dat beide sleutels werken voordat er agentcode in de buurt komt.

Je API-sleutels ophalen

De Supermemory API-sleutel staat op console.supermemory.ai, NIET op app.supermemory.ai. De app-subdomein is het consumentenproduct voor geheugen (om notities op te slaan, je ruimte te browsen). Het heeft geen API-key-pagina. Sla het over en ga direct naar de console.

Op console.supermemory.ai:

1. Log in.

2. Klik op API Keys in de zijbalk.

3. Klik op Create API Key.

4. Geef een naam (de trainerdemo gebruikt datacamp-tutorial).

5. Kopieer de resulterende sleutel. Die begint met sm_.

Je hebt ook een OpenAI-sleutel nodig voor de LLM-calls van de agent. Haal er een op platform.openai.com/api-keys als je die nog niet hebt.

Maak een .env-bestand in de projectroot met beide sleutels. Commit dit niet.

SUPERMEMORY_API_KEY=sm_your_key_here
OPENAI_API_KEY=sk-your_key_here

De gratis laag van Supermemory dekt deze tutorial zonder betaalgegevens in te voeren. Exacte limieten staan op de prijspagina.

Dependencies installeren

De tutorial gebruikt uv voor projectsetup en -uitvoering. Als je uv niet hebt, installeer het eenmalig met de one-liner van astral.sh/uv.

Initialiseer het project:

uv init supermemory-trainer
cd supermemory-trainer

Verwijder de automatisch gegenereerde README.md die uv init toevoegt. De automatisch gegenereerde hello.py wordt in de volgende stap overschreven, dus laat die staan.

Voeg drie dependencies toe:

• supermemory==3.37.0 is de memoryclient, vastgepind op de versie die voor deze tutorial is geverifieerd.

• openai-agents is de OpenAI Agents SDK. De packagenaam is met koppelteken, het importpad is agents.

• python-dotenv leest het .env-bestand dat je net hebt gemaakt.

uv add supermemory==3.37.0 openai-agents python-dotenv

Het resulterende pyproject.toml:

[project]
name = "supermemory-trainer"
version = "0.1.0"
description = "Personal exercise trainer agent built with Supermemory and the OpenAI Agents SDK."
requires-python = ">>=3.10"
dependencies = [
	"openai-agents>=0.10.2",
	"python-dotenv>=1.2.1",
	"supermemory==3.37.0",
]

Je setup verifiëren

Voordat je agentcode schrijft, kijk je hoe Supermemory één keer zijn werk doet op een enkele zin. Het onderstaande script stuurt één feit naar Supermemory, wacht op de pipeline en leest dan het profiel terug. Als dit schoon draait, werken de sleutels en is de SDK bereikbaar. De output geeft je ook een eerste blik op wat Supermemory met ruwe tekst doet.

Open hello.py in de projectroot en vervang de automatisch gegenereerde body door de imports en een write-call:

import time
 
from dotenv import load_dotenv
from supermemory import Supermemory
 
load_dotenv()
 
client = Supermemory()
USER_ID = "demo_warmup"
 
response = client.add(
	content="The user is learning Supermemory by building a personal trainer agent.",
	container_tag=USER_ID,
)
print(f"client.add() -> id={response.id} status={response.status}")

load_dotenv() leest de API-sleutel uit .env in de omgeving voordat Supermemory() wordt geconstrueerd. De client pikt SUPERMEMORY_API_KEY automatisch op. De waarde container_tag="demo_warmup" beperkt dit ene feit tot een wegwerpgebruiker.

Voeg nu onderaan hetzelfde bestand de wacht- en read-stap toe:

print("Waiting 20 seconds for processing...")
time.sleep(20)
 
prof = client.profile(container_tag=USER_ID, q="learning")
print(f"profile.static  ({len(prof.profile.static)}): {prof.profile.static}")
print(f"profile.dynamic ({len(prof.profile.dynamic)}): {prof.profile.dynamic}")
print(f"search_results.results ({len(prof.search_results.results)}):")
for r in prof.search_results.results[:3]:
	print(f"  - {r['memory']} (similarity={r['similarity']:.3f})")

De wachttijd van 20 seconden geeft Supermemory’s embed-and-extract-pipeline de tijd om de nieuwe memory te verwerken. Zonder die wachttijd geeft de read niets terug en lijkt het script kapot terwijl dat niet zo is.

Draai het bestand:

uv run python hello.py

Verwachte output:

client.add() -> id=zNLsJBrY1PZupAeZ3Qn6EL status=queued
Waiting 20 seconds for processing...
profile.static  (0): []
profile.dynamic (1): ['Building a personal trainer agent to learn Supermemory.']
search_results.results (1):
  - Building a personal trainer agent to learn Supermemory. (similarity=0.650)

Drie details zijn belangrijk in deze output. client.add() retourneert meteen met status="queued", omdat Supermemory documenten asynchroon verwerkt. De 20 seconden wachten dekken de embed-and-extract-pipeline af. Tegen de tijd dat de read draait, is de ruwe zin één doorzoekbare memory-chunk.

De interessante regel is profile.dynamic. De input was de zin “The user is learning Supermemory by building a personal trainer agent.” De output is het dynamische feit 'Building a personal trainer agent to learn Supermemory.'. Supermemory herschreef een zin in de derde persoon naar een feit in de eerste persoon over de gebruiker. Dat is de profiel-extractor die zijn werk doet.

profile.static is een lege lijst. Statische feiten consolideren langzaam, nadat een handvol gerelateerde logs zich opstapelt, dus een enkele warm-upwrite levert er geen op. De suggestietool van de trainer anticipeert hierop en behandelt static als een bonus, niet als een garantie.

Een Supermemory-agent bouwen: persoonlijke oefentrainer in Python

De trainer wikkelt client.add() en client.profile() in twee agenttools, zodat reads en writes automatisch gebeuren terwijl de gebruiker chat. Workouthistorie past goed bij geheugen. Apparatuur, blessures en recente lifts staan niet in de trainingsdata van de LLM en stapelen zich sessie na sessie op.

Projectstructuur en de agent

De trainer is klein genoeg dat het hele project in twee Python-bestanden past plus de pyproject.toml die je al hebt:

supermemory-trainer/
├── .env            	# your real keys (gitignored)
├── .env.example    	# placeholders, committed
├── .gitignore
├── .python-version
├── main.py         	# agent definition, system prompt, REPL loop
├── pyproject.toml
└── tools.py        	# log_workout and suggest_next_session

tools.py bevat de twee geheugen-ondersteunde tools die je hierna schrijft. log_workout schrijft een workout naar Supermemory via client.add(). suggest_next_session leest het gebruikersprofiel via client.profile(). main.py importeert beide en verbindt de agent.

Het meeste van main.py is boilerplate van de OpenAI Agents SDK. Eén zin in de system prompt doet het Supermemory-werk: elk feit over de gebruiker moet via tool-calls terugkomen. De agent krijgt te horen dat hij zelf geen geheugen heeft. Die ene regel is wat de trainer geheugen-ondersteund maakt.

Open main.py en begin met de imports en de system prompt:

import asyncio
 
from agents import Agent, Runner, SQLiteSession
 
from tools import log_workout, suggest_next_session
 
SYSTEM_PROMPT = """You are a personal exercise trainer who logs the user's
workouts and recommends what to do next.
 
You have no memory of the user's history on your own. Every fact about the
user lives in Supermemory and reaches you only through tool calls.
 
Two rules, no exceptions:
 
1. Whenever the user reports completing a workout, call log_workout immediately, before responding. Extract the exercise, sets, reps, weight, and any notes from what they said. If a value is missing, ask one short follow-up question instead of guessing. After logging, confirm in one short sentence and stop. Do NOT recommend the next session unless the user asks for one.
 
2. When the user explicitly asks what to do next (or asks for a recommendation, suggestion, or plan), call suggest_next_session first. Never recommend from your own training data. The tool returns the user's
 recent activity, stable preferences, and matching past sessions. Reference those facts directly in your reply.
 
Keep replies concise (2-4 sentences). Be specific: name the exercise, sets, reps, and weight. Honor any injuries or equipment constraints the tool surfaces.
"""

Beide regels in de system prompt leiden het model via Supermemory.

Regel 1 dwingt een log_workout-write af wanneer de gebruiker een workout meldt, zodat elke workout de geheugenstore bereikt. Regel 2 dwingt een suggest_next_session-read af vóór elke aanbeveling, zodat elke aanbeveling is gegrond in wat Supermemory weet.

Sla die regels over en de agent antwoordt vanuit zijn trainingsdata, wat het punt van een geheugenlaag onderuit haalt.

Definieer nu de agent en de chatloop in hetzelfde bestand:

def build_agent() -> Agent:
	return Agent(
    	name="Trainer",
    	instructions=SYSTEM_PROMPT,
    	tools=[log_workout, suggest_next_session],
    	model="gpt-5",
	)
 
 
async def chat() -> None:
	agent = build_agent()
	session = SQLiteSession(session_id="trainer-cli")
 
	print("Trainer ready. Type a message, or 'exit' to quit.\n")
	while True:
    	try:
        	message = input("You: ").strip()
    	except (EOFError, KeyboardInterrupt):
        	print()
        	break
    	if not message:
        	continue
    	if message.lower() in {"exit", "quit"}:
        	break
 
    	result = await Runner.run(agent, message, session=session)
    	print(f"\nTrainer: {result.final_output}\n")
 
 
if __name__ == "__main__":
	asyncio.run(chat())

Twee regels in dat blok zijn het noemen waard. tools=[log_workout, suggest_next_session] registreert de twee geheugen-ondersteunde tools. De @function_tool-decorator op elk (in tools.py) vertelt de SDK dat ze aanroepbaar zijn. Zonder de decorator heeft de agent runtime geen tools, ook al slaagt de constructiecall.

SQLiteSession(session_id="trainer-cli") houdt kortetermijngeschiedenis tussen beurten binnen het draaiende Python-proces. Supermemory bewaart langetermijngebruikersfeiten over processen heen. Het killen van het Python-proces laat de SQLite-sessie vervallen, maar de Supermemory-data blijft.

Belangrijk: Draai main.py als script, niet in een Jupyter-cel, omdat Jupyter’s eventloop conflicteert met asyncio.run(). De synchrone Supermemory()-client werkt binnen asynchrone toolfuncties omdat de Agents SDK tools in een threadpool draait. Voor meer over de SDK zelf, zie de OpenAI Agents SDK-tutorial.

De workout-loggingtool schrijven

log_workout is de write-kant van het geheugen van de agent. De functie neemt gestructureerde argumenten van de agent: oefeningsnaam, sets, reps, gewicht en optionele notities. Het maakt daar één korte Engelse zin van en geeft die via client.add() door aan Supermemory. De embed-and-extract-pipeline draait daarna binnen Supermemory en heeft niets nodig van de trainer.

Open tools.py en begin met de imports en één gedeelde client:

from agents import function_tool
from dotenv import load_dotenv
from supermemory import Supermemory
 
load_dotenv()
 
USER_ID = "demo_user"
 
client = Supermemory()

load_dotenv() draait bij import, zodat SUPERMEMORY_API_KEY in de omgeving staat voordat Supermemory() wordt geconstrueerd. Construeer de client vóór het laden van de env en je krijgt een niet-geauthenticeerde client. De eerste call geeft dan een verwarrende 401. Beide toolfuncties in dit bestand delen die ene client en de ene USER_ID-constante.

Voeg de loggingtool hieronder toe:

@function_tool
def log_workout(
	exercise: str,
	sets: int,
	reps: int,
	weight: float,
	notes: str = "",
) -> str:
	"""Log a completed workout to the user's memory.
 
	Args:
    	exercise: Name of the exercise.
    	sets: Number of sets performed.
    	reps: Number of reps per set.
    	weight: Weight in pounds. Pass 0 for bodyweight or cardio.
    	notes: Optional notes about the session.
	"""
	print(f"[log_workout] {exercise=} {sets=} {reps=} {weight=} {notes=}")
 
	content = f"Performed {exercise}: {sets} sets of {reps} reps at {weight} lbs."
	if notes:
    	content += f" Notes: {notes}"
 
	response = client.add(content=content, container_tag=USER_ID)
	print(f"[log_workout] -> id={response.id} status={response.status}")
	return f"Logged {exercise} ({sets}x{reps} @ {weight} lb)."

De @function_tool-docstring is wat de LLM ziet wanneer die beslist of de tool moet worden aangeroepen. Het Args:-blok mapt naar beschrijvingen per parameter. Beide maken deel uit van het contract van de agent met de functie.

De tool stuurt een gewone zin naar client.add(), geen JSON. De profiel-extractor van Supermemory leest natuurlijke taal en leidt daar feiten uit af. JSON werkt technisch gezien, maar de extractiekwaliteit daalt omdat het model geen narratief heeft om samen te vatten. “Performed bench press: 4 sets of 5 reps at 185.0 lbs” geeft de extractor een heldere zin om mee te werken.

De twee print()-calls schrijven elke toolaanroep naar de terminal: eerst de geparste args, daarna de response.

[log_workout] exercise='bench press' sets=4 reps=5 weight=185.0 notes=''
[log_workout] -> id=xY7AK3qLzBPx5Vd2HnRf1M status=queued

De waarde status="queued" komt overeen met wat het warm-upscript eerder teruggaf. De ruwe log is opgeslagen, maar client.profile() geeft het pas als zoekresultaat terug wanneer de pipeline klaar is. Je voegt later een verificatiestap toe die daarop wacht.

De workoutsuggestietool schrijven

suggest_next_session is de read-kant, en hier betaalt de statisch-en-dynamisch-splitsing zich uit. Eén client.profile(container_tag=USER_ID, q=focus)-call geeft drie weergaven van de gebruiker terug in één round-trip.

Stabiele voorkeuren komen terug als profile.static, actuele activiteit als profile.dynamic en de dichtstbijzijnde overeenkomende herinneringen uit het verleden als search_results.results. De taak van de tool is die drie weergaven te flattenen tot één blok context dat de agent kan citeren.

Na een paar workouts produceert de tool output zoals dit:

Recent activity:
- Trains at home instead of a gym
- Performed deadlift: 3 sets of 5 reps at 225.0 lbs
- Performed 5k run in 26 minutes
- Reports no knee pain during bench press
- Performed bench press: 4 sets of 5 reps at 185.0 lbs
Closest matching past entries:
- Trains at home instead of a gym
- Performed deadlift: 3 sets of 5 reps at 225.0 lbs
- Performed bench press: 4 sets of 5 reps at 185.0 lbs
- Performed 5k run in 26 minutes
- Reports no knee pain during bench press

De agent leest dat blok en schrijft een aanbeveling die is gegrond in de echte geschiedenis van de gebruiker. Zonder het profiel van Supermemory zou je dezelfde context zelf bouwen. Dat betekent een aparte semantische zoekopdracht, je eigen profeillayer en het samenvoegen van de resultaten. De enkele client.profile()-call vervangt alle drie.

Voeg dit toe aan tools.py onder log_workout:

@function_tool
def suggest_next_session(focus: str) -> str:
	"""Fetch the user's training history and preferences for a given focus.
 
	Returns a context string the agent can use to recommend the next session.
	The agent is responsible for the actual recommendation. This tool only
	surfaces what Supermemory knows about the user.
 
	Args:
    	focus: What the user wants to train next (e.g. "upper body", "legs",
        	"cardio", "today"). Drives semantic search against past logs.
	"""
	print(f"[suggest_next_session] focus={focus!r}")
	profile = client.profile(container_tag=USER_ID, q=focus)
 
	static_facts = profile.profile.static
	dynamic_facts = profile.profile.dynamic
	matches = profile.search_results.results
 
	print(
    	f"[suggest_next_session] static={len(static_facts)} "
    	f"dynamic={len(dynamic_facts)} matches={len(matches)}"
	)
 
	sections = []
	if static_facts:
    	sections.append("Stable preferences and constraints:")
    	sections.extend(f"- {fact}" for fact in static_facts)
	if dynamic_facts:
    	sections.append("Recent activity:")
    	sections.extend(f"- {fact}" for fact in dynamic_facts)
	if matches:
    	sections.append("Closest matching past entries:")
    	for r in matches[:5]:
        	sections.append(f"- {r['memory']}")
 
	if not sections:
    	return (
        	"No prior training history found for this user. "
        	"Ask the user about their goals, equipment, and recent training."
    	)
	return "\n".join(sections)

client.profile(container_tag=USER_ID, q=focus) retourneert een ProfileResponse-object. Na 5 korte logs zien de drie velden die de tool leest er zo uit:

profile.profile.static        	# [] (list[str])
profile.profile.dynamic       	# ["Performed bench press: 4 sets of 5 reps at 185.0 lbs", ...]
profile.search_results.results	# [{"memory": "...", "similarity": 0.631, ...}, ...] (list[dict])

Elk zoekresultaat is een Python-dict, geen Pydantic-object. Gebruik r["memory"] voor de tekst en r["similarity"] voor de score. De volledige dict heeft de volgende keys:

• id

• memory

• rootMemoryId

• metadata

• updatedAt

• version

• similarity

• filepath

• documents

De snippet r.memory or r.chunk van Supermemory’s OpenAI Agents SDK-integratiepagina geeft een AttributeError bij supermemory==3.37.0. Gebruik bracket-toegang.

static is hier leeg, daarom vertakt de tool op if static_facts:. De branches dynamic en search_results doen het echte werk voor de eerste dozijn logs.

Supermemory hanteert ook een standaard similariteitsdrempel. Een feit dat je één keer noemde, komt mogelijk niet bij elke query terug. De 5 logs hierboven kwamen allemaal terug voor q="today", maar een specifiekere querystring kan er minder teruggeven. De if matches:-guard vangt dat op zonder te falen.

Sessie 1 draaien: workouts loggen

Start sessie 1 en log een paar workouts om Supermemory te vullen met iets dat later kan worden teruggelezen. Draai het script:

uv run python main.py

Log bench press, daarna een 5 km-run, dan deadlift, plus één voorkeur: “Ik train alleen thuis, geen gym.” De agent vuurt log_workout één keer per workout, en de print()-regels van de tool maken elke call zichtbaar in de terminal.

Voorbeeldoutput. De exacte formulering van jouw agent zal verschillen omdat het model niet-deterministisch is.

De drie regels status=queued zijn het moment dat Supermemory het overneemt. Elk ervan komt overeen met een document dat door de embed-and-extract-pipeline op Supermemory’s kant gaat. Voor korte tekstlogs zoals deze wordt het document binnen ~12 seconden doorzoekbaar via client.profile().

Niets in de code van de trainer wacht daarop. De agent gaat door en Supermemory voltooit het werk op de achtergrond.

Elke log vuurt precies één log_workout-call af en de agent stopt. Geen proactieve aanbevelingen, geen extra tool-calls, geen follow-upsuggesties. De eerste system prompt-regel regelt dat. Zonder die regel zou de agent na elke log een volgende sessie voorstellen, wat het aantal tool-calls verdubbelt.

Typ exit om sessie 1 te sluiten. Het Python-proces eindigt en de SQLiteSession verdwijnt ermee. De workoutlogs en de voorkeur lives nu in Supermemory onder container_tag="demo_user", los van het script dat ze schreef.

Recall verifiëren en sessie 2 draaien

Bevestig vóór sessie 2 dat de feiten uit sessie 1 bevraagbaar zijn. Open een verse Python-REPL of sla dit op als een kort script:

from dotenv import load_dotenv
from supermemory import Supermemory
 
load_dotenv()
client = Supermemory()
 
prof = client.profile(container_tag="demo_user", q="training")
print(f"static  ({len(prof.profile.static)}): {prof.profile.static}")
print(f"dynamic ({len(prof.profile.dynamic)}):")
for fact in prof.profile.dynamic:
	print(f"  - {fact}")
print(f"matches ({len(prof.search_results.results)}):")
for r in prof.search_results.results[:5]:
	print(f"  - {r['memory']} (similarity={r['similarity']:.3f})")

Echte output vastgelegd tussen de twee sessies:

static  (0): []
dynamic (5):
  - Trains at home instead of a gym
  - Performed deadlift: 3 sets of 5 reps at 225.0 lbs
  - Performed 5k run in 26 minutes
  - Reports no knee pain during bench press
  - Performed bench press: 4 sets of 5 reps at 185.0 lbs
matches (5):
  - Trains at home instead of a gym (similarity=0.682)
  - Performed deadlift: 3 sets of 5 reps at 225.0 lbs (similarity=0.643)
  - Performed bench press: 4 sets of 5 reps at 185.0 lbs (similarity=0.631)
  - Performed 5k run in 26 minutes (similarity=0.585)
  - Reports no knee pain during bench press (similarity=0.585)

Kijk naar wat de extractor van Supermemory produceerde. De gebruiker zei één keer: “Ik train alleen thuis, geen gym.” De extractor maakte daar het dynamische feit "Trains at home instead of a gym" van.

De bench-presslog bevatte een notitie over geen kniepijn. De extractor splitste die enkele log in twee dynamische feiten: één voor de workout, één voor de afwezigheid van pijn.

Vier logs werden vijf genormaliseerde dynamische feiten plus vijf overeenkomende memory-chunks met similariteitsscores tussen 0,585 en 0,682. Geen van dat splitten, normaliseren of matchen draaide in de code van de trainer. Als dynamic bij jou leeg is, wacht nog 10 seconden en draai het snippet opnieuw. De verwerkingsqueue piekt af en toe.

Start nu sessie 2 in een gloednieuw proces:

uv run python main.py

Dit is een verse Python-interpreter. Geen gedeeld geheugen met sessie 1. Geen warme cache. Alles wat de agent zich herinnert, komt uit Supermemory.

Stuur één bericht: “Wat moet ik vandaag doen voor mijn workout?”

Voorbeeldoutput. Dezelfde memorystore, vers Python-proces.

De agent roept suggest_next_session("today") aan. De tool print static=0 dynamic=5 matches=5. De vastgelegde run antwoordde met een onderlichaamsessie thuis (squats, lunges, step-ups).

De aanbeveling sloot aan op de vorige logs omdat het profiel van Supermemory de agent vertelde wat die waren. Bench, deadlift en een 5 km waren bovenlichaam of cardio, en de gebruiker trainde alleen thuis. Beide feiten kwamen terug uit dezelfde client.profile()-call. Jouw run formuleert het anders omdat het model niet-deterministisch is, maar het recallpad is hetzelfde.

Volgende stappen voor je Supermemory-agent

De demo is één gebruiker, twee tools en een CLI. Een echte versie van de trainer breidt uit in drie Supermemory-vormige richtingen voordat de agentloop wordt aangeraakt.

Scope geheugen per echte gebruiker. De constante USER_ID = "demo_user" werkt voor één persoon. Productie-apps berekenen de tag uit de ID van de geauthenticeerde gebruiker, zoals container_tag="user_sarah" of container_tag=customer_id. Geheugen tussen gebruikers blijft gescheiden omdat elke read de tag teruggeeft. Eén wijziging in tools.py, geen andere code hoeft te bewegen.

Voeg meer geheugen-ondersteunde tools toe. Deload-weken, PR-tracking en wekelijkse mobility-prompts. Elk is weer een @function_tool-functie die client.add() aanroept voor writes en client.profile() voor reads tegen dezelfde container_tag. De vorm van de tool blijft hetzelfde. Alleen wat de agent vastlegt en vraagt verandert.

Ga om met Supermemory-fouten. Omwikkel client.add() en client.profile() in try/except supermemory.APIError zodat tijdelijke storingen van Supermemory de agent niet laten crashen. Stel per-request time-outs in als je agent in een beperkte omgeving draait.

De agentloop-kant van het werk staat los van Supermemory en kan later veranderen. Zet de CLI voor Telegram, Discord of Slack, zodat de gebruiker een workout appt en de bot Runner.run() aanroept. Of wissel het framework. Supermemory heeft een LangChain-integratie als je stack al op LangChain-agents zit, en de geheugen-code verandert niet.

De statisch-en-dynamisch-splitsing past ook in andere domeinen.

• Klantenserviceagent: statisch = bekende issues en accountvoorkeuren, dynamisch = open tickets en recente contacten.
• Codeagent: statisch = favoriete talen en frameworks, dynamisch = huidige taak en recent aangeraakte bestanden.

De splitsing houdt stand wanneer de gebruiker de bron van de waarheid is.

Conclusie

Je hebt zojuist een Python-trainer gebouwd met twee tools en persistent geheugen over processen heen. client.add() schrijft workouts weg. client.profile() leest de gebruiker terug als statische feiten, dynamische feiten en semantische matches in één call, allemaal gescopeerd door container_tag. Supermemory doet het chunking, embedden, zoeken en profiel-extractie die de demo niet hoefde te schrijven.

Combineer het met RAG, en dezelfde agent beantwoordt vragen over de gebruiker en het product. Uitleg LLM-agents behandelt bredere agentpatronen, en de Associate AI Engineer for Developers-track gaat dieper in op geheugen-ondersteunde agents.