Scope note. Het Cryptohopper MCP is stateless ontworpen — elke tool call is onafhankelijk, en de server bewaart niets tussen requests. Geheugen leeft aan de client-kant of in opslag die jij beheert. Deze gids gaat over die laag.
Vereisten
Een MCP client met een werkende Cryptohopper MCP connectie. Zie setup overzicht.
Een plek om data op te slaan. Dit kan een lokaal bestand zijn, een SQLite database, een cloud-opgeslagen JSON blob, of een tool als Notion. Geen infrastructuur vereist om te beginnen.
Wat telt als "geheugen"
Drie lagen, elk nuttig om verschillende redenen:
Laag | Voorbeeld | Typische locatie |
Sessiegeheugen | Binnen één gesprek herinnert het model zich wat je eerder zei | Het contextvenster van het model (ingebouwd) |
Cross-run geheugen | De agent-run van vandaag onthoudt wat de run van vorige week heeft waargenomen | Bestand, database, Notion, etc. |
Gebruikersprofiel | De agent kent je watchlist, voorkeursbeurs, risicoperceptie | Zelfde als cross-run; geladen bij het starten van de sessie |
Sessiegeheugen is gratis en automatisch. Cross-run en gebruikersprofiel geheugen vereisen dat je opslag opzet.
Setup — gebruikersprofiel
Schrijf een kort markdown-bestand dat jezelf beschrijft als crypto-gebruiker. Houd het onder een pagina:
Over de gebruiker
Handelt voornamelijk op Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Houdt spot aan; draait grid bots op SOL en AVAX via Cryptohopper.
Geeft meer om drawdown-risico dan om het missen van upside.
Handelt niet in perpetuals.
Standaarden
Beurs: Binance
Quote: USDT
TA timeframe: 4h (200 bars)
Risicotolerantie: gematigd
Prompting voorkeuren
Geef de voorkeur aan concrete cijfers boven bijvoeglijke naamwoorden.
Markeer speculatie als speculatie.
Als een ticker dubbelzinnig is, vraag dan in plaats van te gokken.Laad het aan het begin van elk agentgesprek. Twee benaderingen:
Handmatig plakken: het eerste in elke sessie, plak het bestand.
Client-geïntegreerd: gebruik de persistente-geheugenfunctie van je client (Claude desktop Projects, Cursor rules, Zed context) om automatisch te injecteren.
Houd het bestand klein. Alles boven ~300 regels wordt ruis die het model overslaat. Het punt zijn de beperkingen, niet een autobiografie.
Versiedo het. Wanneer je je watchlist of voorkeuren verandert, commit de wijziging naar git (of Notion geschiedenis). Het gedrag van je agent verandert met het profiel; je wilt zien waarom.
Setup — cross-run geheugen (simpel)
Het eenvoudigste cross-run geheugen is een enkel markdown-bestand dat de agent aan het begin leest en aan het einde mee aanvult:
Maak memory.md met een skelet:
Agent geheugen Recente waarnemingen (Voeg hier de items toe na elke run.) Openstaande punten om te bewaken (Dingen die de agent voor toekomstige aandacht heeft gemarkeerd.) Beslissingen uit het verleden (Opmerkelijke beslissingen en hun redenering.)
Injecteer aan het begin van elke agent-run de bestandsinhoud:
[AGENT GEHEUGEN] {inhoud van memory.md} [TAAK] Taak van vandaag: voer de dagelijkse digest uit.Voeg aan het einde van elke run nieuwe waarnemingen toe. Vraag de agent om ze expliciet te produceren:
Na voltooiing van de taak, schrijf 2-4 regels die samenvatten wat opmerkelijk is en de moeite waard is om voor de volgende keer te onthouden. Gebruik dit formaat: [YYYY-MM-DD] {waarneming} Voorbeelden: [27-05-2026] SOL volume verhoogd gedurende 3 dagen achter elkaar; houdt een bereik van ongeveer 83-87 aan. [27-05-2026] Watchlist: LINK gemarkeerd als stil, maar de moeite waard om over 7 dagen te controleren. Ik zal deze handmatig toevoegen aan memory.md.Controleer en snoei periodiek. Ongeveer eens per week, trim
memory.md— verwijder verouderde items, consolideer patronen. Een onbeheerd geheugenbestand groeit onbeperkt en wordt ruis.
Setup — cross-run geheugen (gestructureerd)
Voor agents die profiteren van opvraagbare geschiedenis, werkt een kleine SQLite database goed. Schema-suggestie:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- bijvoorbeeld "dagelijkse-digest"
category TEXT, -- bijvoorbeeld "volume-spike", "trend-change"
token TEXT, -- bijvoorbeeld "SOL"
content TEXT NOT NULL, -- de waarnemingstekst
metadata JSON -- eventuele gestructureerde velden
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Dit laat je vragen stellen zoals: "welke waarnemingen hebben we gedaan over SOL in de laatste 14 dagen?" — en het antwoord voeren als context voor de run van vandaag aan de agent.
De agent schrijft naar deze tabel via een kleine Python helper:
python
def log_observation(agent_name: str, category: str,
token: str, content: str) -> None:
conn.execute(
"INSERT INTO observations (run_at, agent_name, category, token, content) "
"VALUES (?, ?, ?, ?, ?)",
(datetime.utcnow().isoformat(), agent_name, category, token, content),
)
conn.commit()
Gebruik dit spaarzaam. Gestructureerd geheugen is pas de moeite waard als je het daadwerkelijk gaat bevragen; voor een simpele digest is het markdown-bestand meestal voldoende.
Wat te onthouden, wat niet
Goede geheugenkandidaten:
"SOL heeft 5 dagen zijwaarts gehandeld in een band van 83–87" — bereikcontext die een enkele dagkaars niet zal tonen op de run van morgen.
"We hebben LINK gisteren gemarkeerd voor een volume-anomalie; volg vandaag op."
"Gebruiker vroeg naar grid bots voor AVAX op 20-05-2026; parameters waren X, Y, Z."
Geen goede geheugenkandidaten:
Ruwe marktdata. Het verandert — haal het opnieuw op uit de MCP in plaats van te vertrouwen op een verouderde cache.
Volledige gespreksverslagen. Signaal-ruisverhouding is te laag.
Automatische samenvattingen van elke run. Zonder curatie worden deze grotendeels nutteloos.
Een goede test: "als ik dit geheugenitem verwijder, gedraagt de agent zich dan volgende week slechter?" Zo niet, verwijder het.
Probleemoplossing
De agent citeert geheugen dat wordt tegengesproken door actuele gegevens.
Dit is het fundamentele risico van gecachte context. De agent "herinnert" zich dat SOL omhoog ging, maar het is sindsdien omgekeerd. Oplossing: instrueer de agent om geheugenclaims altijd te verifiëren aan de hand van actuele MCP-gegevens voordat deze als feit worden gebruikt. "Controleer voordat je vertrouwt op een geheugenitem de actuele gegevens en markeer indien het geheugen verouderd is."
Geheugenbestanden groeien onhandelbaar groot.
Je voegt toe zonder te snoeien. Stel een harde regel in: bekijk één keer per week de items van de afgelopen week en verwijder / voeg samen. Of roteer geheugenbestanden maandelijks (memory-2026-04.md, memory-2026-05.md).
De agent negeert het geheugenblok.
De prompt eist niet dat de agent het gebruikt. Wees expliciet: "bekijk het geheugenblok hierboven voordat je antwoordt. Verwijs naar specifieke items waar relevant. Als een item verse gegevens tegenspreekt, markeer dat dan expliciet."
Geheugen introduceert zelfverzekerde maar foute antwoorden.
De agent behandelt geheugen als autoritair. Frame geheugen als hints, geen waarheid: "geheugen bevat eerdere waarnemingen; behandel als context, niet als feit. Verifieer altijd aan de hand van actuele gegevens."
Je wilt dat de agent geheugen bijwerkt zonder jouw tussenkomst.
Mogelijk maar riskant — ongecontroleerd append-only geheugen voegt slechte items toe even snel als goede. Als je het automatiseert, koppel het altijd aan een wekelijkse review-stap. Laat geheugen nooit een maand groeien zonder gelezen te worden.
Multi-agent geheugen raakt verward.
Als meerdere agents één geheugenbestand delen, gebruik dan het veld agent_name om items te namespace. Elke agent leest alleen zijn eigen items, of leest het volledige bestand maar weet welke agent welke regel heeft geschreven.
Het gebruikersprofielbestand raakt verouderd. Voorkeuren veranderen. Als je merkt dat de agent standaard instelt op een timeframe of beurs die je niet meer gebruikt, update het profiel — werk het niet om met per-prompt overrides.