Alle Notizen
29. Mai 202611 Min. Lesedauerai-agentsagent-memorytoken-costragmittelstandarchitecture

Memory Tiers, nicht größere Modelle, senken deine Agent-Tokenrechnung

Memory Tiers, nicht größere Modelle, senken deine Agent-Tokenrechnung

Ein KI-Agent hat kein eigenes Gedächtnis. Jedes Mal, wenn dein Chatbot antwortet, hat das Modell dahinter die gesamte Konversation vergessen und liest sie von vorn. Alles, woran sich ein Agent „erinnert", ist etwas, das ein Engineer entschieden hat, wieder in den Prompt zu stopfen, und für diese Entscheidung bezahlst du am Monatsende.

Ich sehe die meisten Teams nach dem größeren oder billigeren Modell greifen, sobald die Rechnung weh tut. In meiner Lesart ist das der falsche Hebel. Der dominante Kostentreiber ist, welchen Memory Tier du um das Modell legst: In-Prompt-Working Memory, Episodic Memory der letzten Turns, per Vektor abgerufenes Semantic Memory oder kaltes Archival Memory. Wähl den falschen Tier und du zahlst rund das Zwanzigfache an Tokens für dieselbe Antwortqualität, laut dem Recap der Azure Cosmos DB Conf 2026. Das Modell ist daneben ein Rundungsfehler.

Kernpunkte

  • Token-Kosten sind ein Memory-Architektur-Problem im Modellauswahl-Kostüm; die Tier-Wahl dominiert, die Modellwahl trimmt.
  • Vier Tiers haben sich 2026 stabilisiert: Working, Episodic, Semantic, Archival; mappe deinen Use Case auf einen, bevor du Modelle benchmarkst.
  • Sliding-Window-Memory gewinnt unter dreißig Turns; Entity-Graph-Memory gewinnt, wenn jeder Fakt überleben muss; hierarchisches Memory überbrückt das Mittelband.
  • Lange Context Windows haben Tiering nicht abgeschafft; gemessener Context Rot hält Semantic Retrieval günstiger als eine Million Tokens hineinzustopfen.
  • Für eine Mittelstandsfirma mit fünfzig Sitzen ist das günstigste Tier-Upgrade ein Cache-Header plus eine Session-TTL, keine Vector-DB-Migration.

In diesem Artikel

Warum Memory, nicht Modell, deine Tokenrechnung setzt

Das Modell ist zustandslos. Du zahlst für Memory. Jeder API-Call schickt einen frischen Text-Blob ans Modell und bekommt einen frischen zurück. Es gibt keinen versteckten Cache von „was wir gestern sagten" in den Modellgewichten. Wirkt es so, als erinnere sich dein Agent an einen Kundennamen, hat ein Engineer entschieden, dass dieser Name in diesen Prompt gehört, und deine Rechnungszeile spiegelt diese Entscheidung wider.

Dieses Detail ist beim Prototypen unsichtbar. Du fütterst den Agent mit zehn oder fünfzehn Test-Turns, alles antwortet korrekt, das Dashboard sagt, du gibst Cents pro Session aus. Die Falle ist, dass Kostenkurve und Recall-Kurve unter dreißig Turns beide brav aussehen und scharf auseinanderlaufen, sobald echte Nutzer montags Fakten droppen und freitags danach fragen. Die Azure-Cosmos-DB-Conf-Demo hat genau diesen Spalt gemessen, und das Team merkte es nur, weil sie über die übliche Proof-of-Concept-Turn-Zahl hinaus gegangen sind.

Die andere Falle, die ich am häufigsten in Kunden-Kickoffs sehe, ist die Annahme, ein Frontier-Modell mit einem Eine-Million-Tokens-Fenster löse das Problem, indem es die Konversation aufsaugt. Tut es nicht. Die Chroma-Context-Rot-Studie hat monotone Recall-Degradation über alle achtzehn getesteten Frontier-Modelle hinweg gezeigt, mit steigender Input-Länge. Langer Kontext kauft dir Headroom, kein Gedächtnis. Headroom, den du bei jedem Call pro Token neu auffüllst.

Hier ist mein Gedanke: Token-Kosten sind eine Architekturentscheidung, getarnt als Beschaffungsentscheidung. Du kannst die Beschaffung behalten, dein Lieblingsmodell behalten und die Rechnung trotzdem um eine Größenordnung senken, wenn du den richtigen Tier vor den richtigen Use Case stellst.

Die vier Tiers und was jeder wirklich kostet

Vier Tiers haben sich 2026 marktweit stabilisiert, und sie intern gleich zu benennen ist der erste Schritt, der sich auszahlt. Das Vokabular ist nicht meins. Es ist dieselbe Form, die Letta als Core, Recall und Archival exponiert, dieselbe, die LangGraph Short-Term plus Long-Term Store nennt, und dieselbe, die Mem0 und Zep als Managed Services ausliefern.

  • Working Memory. Der aktuelle Prompt. Tokens, für die du bei jedem Call zahlst, ohne Ausnahme. Begrenzt durch das Context Window des Modells.
  • Episodic Memory. Jüngste Turns, wörtlich gehalten oder leicht komprimiert. Billig zu lesen, verlustbehaftet zu komprimieren, ausreichend für kurze Chats.
  • Semantic Memory. Konsolidierte Fakten als Entitäten mit Embeddings und Key-Value-Paaren, per Vektor oder Hybridsuche abgerufen. Höhere Fixkosten, beinahe perfekter Recall auf den abgelegten Fakten.
  • Archival Memory. Kaltspeicher mit On-Demand-Zügen. Im Ruhezustand fast kostenlos. Langsam abrufbar, aber das richtige Zuhause für Compliance-Logs und Tickets des letzten Quartals.

Prompt Caching ist der fünfte Tier und der billigste, den du diese Woche ergänzen kannst. Laut der Anthropic-Doku zu Prompt Caching kostet ein Cache-Write das 1,25-fache des Basis-Inputs für ein Fünf-Minuten-Fenster und ein Cache-Read das 0,1-fache. Ein Cache-Hit in einem Fünf-Minuten-Cache zahlt den Write. Für diesen ROI musst du selten argumentieren.

Das Signal ist nicht, welcher Tier am besten klingt. Es ist, welcher Tier zu deiner Turn-Zahl, deiner Faktendichte und deiner Toleranz für die falsche Antwort passt. Montagsschritt: Schreib ein Tier-Label in einer Zeile neben jeden Agenten-Use-Case in deiner Roadmap. Kannst du ihn nicht labeln, kannst du ihn nicht bepreisen.

💡 Behandle Memory Tier wie Datenbanknormalisierung. Leg jeden Fakt in genau einen Tier, der zu seinem Zugriffsmuster passt, und hör auf zu streiten, welches Modell für den Bot „am klügsten" ist.

Die Azure-Cosmos-DB-Conf-Demo nachspielen

Die konkretesten Zahlen, die ich dieses Quartal gesehen habe, stammen aus dem Nachspielen des Microsoft-Developer-Channel-Walkthroughs der Azure-Cosmos-DB-Conf-2026-Session zu Memory-Mustern. Ich habe die Publisher-Zuordnung über YouTube-oEmbed für die zugrundeliegende Aufnahme verifiziert, bevor ich Zahlen daraus zitiere. Die Session hat drei Memory-Strategien auf demselben Datensatz aus sechzig Seed-Nachrichten mit zehn Recall-Fragen gebencht, fünf leichte und fünf nuancierte.

Die berichteten Zahlen waren 92 Tokens pro Call bei 0 Prozent Recall ohne Memory, rund 1.100 Tokens pro Call bei 60 Prozent Gesamt-Recall mit Sliding Window, und rund 1.660 Tokens pro Call bei 100 Prozent Recall mit Entity Graph, wobei hierarchisches Memory mit 80 Prozent dazwischen landete. Die relevante Spanne steckt nicht in der Schlagzeile. Der interessante Einbruch liegt im nuancierten Subset: Sliding Window fiel auf 20 Prozent bei fünf Fragen, deren Antworten mehr als dreißig Turns zurück lagen. Hierarchisches Memory erholte sich auf 60 Prozent. Entity Graph hielt 100 Prozent.

Eine Pseudocode-Skizze der drei Muster in einem Prozess, mit Session-ID als Partition Key und Embeddings zusammen mit dem operativen Datensatz:

def respond(turn_text: str, session_id: str, mode: str) -> str:
    base_prompt = system_prompt()

    if mode == "sliding_window":
        recent = store.last_n_turns(session_id, n=30)
        summary = store.summary_before(session_id, cutoff=30)
        context = summary + recent

    elif mode == "hierarchical":
        hot = store.last_n_turns(session_id, n=10)
        warm = store.weekly_digest(session_id)
        cold = store.archived_facts(session_id, k=5)
        context = cold + warm + hot

    elif mode == "entity_graph":
        entities = store.vector_search(
            query=turn_text,
            partition_key=session_id,
            k=8,
        )
        facts = store.facts_for(entities)
        edges = store.relationships(entities)
        context = render_graph(facts, edges)

    return llm.complete(base_prompt + context + turn_text)

Die harte Kostendifferenz ist fünfzig Prozent mehr Tokens für Entity Graph gegenüber Sliding Window, im Tausch gegen den Vierzig-Punkte-Recall-Sprung im nuancierten Subset. Der Vergleich, der zählt, ist nicht „1.660 gegen 1.100". Es ist „1.660 mit der richtigen Antwort gegen 1.100 mit der falschen plus ein Mensch, der hinterher aufräumt".

Montagsschritt: Pick den Agenten-Use-Case, in dem eine falsche Antwort am meisten kostet, instrumentiere genau, welche Turns die aktuelle Memory-Strategie verliert, und bepreise den Spalt. Die Zahl, die du produzierst, ist die einzige, mit der du einem CFO ein Tier-Upgrade verteidigen kannst.

Wo die These verliert

Die These verliert, wenn tatsächlich das Modell der Engpass ist. Beantwortet der Agent juristische Fragen und du fährst ein 2024er-Modell mit bekannter Reasoning-Decke auf Verträgen, rettet dich kein Memory Tier; die Ausfälle sitzen am Inference-Schritt, nicht am Retrieval. Tausch zuerst das Modell, dann komm zur Tier-Frage zurück.

Aus den kleinen Builds, die ich bepreist habe, verliert sie auch, wenn der Use Case so klein ist, dass die Infrastrukturkosten eines getierten Memorys die Token-Einsparung übersteigen. Eine Zwölf-Personen-Firma mit einem einzelnen internen FAQ-Bot bei fünfzig Anfragen pro Tag rechnet eine Vector DB und einen separaten operativen Store nicht ein. Für dieses Format ist Prompt Caching plus ein flacher Episodic-Buffer die richtige Antwort, und jedes weitere Tiering ist Over-Engineering.

Ein dritter Failure-Mode ist die Long-Context-Maximalisten-Position, zusammengefasst im breit zirkulierenden Essay „RAG ist tot, Long Context hat gewonnen" (in den Ressourcen verlinkt). Die ehrliche Version dieses Arguments lautet, dass moderne Long-Context-Modelle für Aufgaben mit einem einzelnen langen Dokument und einer Frage darüber oft naives RAG schlagen. Die unehrliche Version verallgemeinert das auf Multi-Turn-Agents mit Tausenden von Konversationen. Die Chroma-Context-Rot-Evidenz ist, wozu ich hier immer wieder zurückkehre, und genau dieses Argument macht auch mein Schwesterpost zu strukturiertem Retrieval für Enterprise-Agents aus dem Retrieval-Qualitäts-Winkel. Behandle ihn als Vetter dieses Posts: gleicher Feind, andere Kostenlinse.

Schließlich sollten Single-Vendor-Recall-Zahlen als Marketing behandelt werden, bis sie reproduziert sind. Der LOCOMO-Benchmark-Streit ist der kanonische Fall: Zep behauptete ursprünglich 84 Prozent, Mem0 korrigierte auf 58,44 Prozent, und Zep konterte mit 75,14 Prozent auf demselben Benchmark, laut Mem0 State of AI Agent Memory 2026 Report (in den Ressourcen verlinkt). Meine These hält trotzdem. Der Tier dominiert weiter die Kosten. Aber wessen Tier auf welchem Benchmark am besten abschneidet, ist eine Frage, die du mit deinen eigenen Evals beantworten solltest, nicht mit dem Slide-Deck eines anderen.

Ein Mittelstandsszenario, Montagmorgen

Stell dir Sabine vor, Ops-Lead in einer sechzig-Personen-Logistikfirma in Westfalen. Die Firma betreibt einen Kundenservice-Chatbot, der Versandstatusfragen beantwortet, aus einer Auftragsdatenbank liest und etwa viertausend Sessions pro Monat bearbeitet. Aktueller Stack ist ein Claude-Haiku-Call direkt an die Chat-UI verdrahtet, mit voller Konversationshistorie, die bei jedem Turn in den Prompt geschoben wird. Die monatlichen Token-Ausgaben haben gerade dreitausend Euro überschritten, und ihr CFO fragt warum.

Sabine braucht kein MemGPT. Sie braucht drei Tier-Änderungen, die sie in zwei Wochen ausliefern kann.

  • Schritt eins, Prompt Caching auf Systemprompt und Produktkatalog. Ein Fünf-Minuten-Cache-Write zum 1,25-fachen Input, Cache-Reads zum 0,1-fachen, und der Katalog wird nicht mehr bei jedem Turn neu bepreist. Montag: Den Cache-Control-Header an die erste Nachricht der Konversation anfügen, TTL auf fünf Minuten, und über den Usage-Block der Antwort bestätigen, dass Cache-Reads feuern.
  • Schritt zwei, ein Episodic Buffer mit Session-TTL. Die letzten dreißig Turns pro Session wörtlich in Postgres halten, alles Ältere zusammenfassen und Sessions älter als dreißig Tage droppen. Stack: Postgres plus pgvector, beides bereits in der bestehenden Anwendungsdatenbank. Montag: Die Migration schreiben, die eine chat_sessions-Tabelle partitioniert nach tenant_id und eine Child-Tabelle chat_turns mit TTL-Trigger anlegt.
  • Schritt drei, ein Semantic Tier nur für die Long-Tail-FAQ. Die FAQ-Dokumente einmal in dieselbe Postgres-Datenbank per pgvector embedden, pro Turn die Top-Drei abrufen und nur als zusätzlichen Kontext injizieren, wenn der Episodic Buffer nicht trifft. Montag: Ein hundert-Zeilen-Ingestion-Skript und ein Feature Flag, das den Tier gegen die Baseline A/B-testet.

Mein Arbeitsziel für Sabine ist fünfzig Prozent Reduktion der monatlichen Token-Ausgaben bei gleichem Recall-Boden, wöchentlich auf einem fixen Eval-Set aus dreißig echten Kundenfragen gemessen. Das ist eine Autorenprognose dimensioniert auf der oben zitierten Zwanzig-fach-Spanne, kein Vendor-Benchmark; ich erwarte die echte Zahl zwischen dreißig und siebzig, abhängig von der FAQ-Überlappung. Kein Modelltausch. Kein neuer Vendor. Die Rechnung sinkt, weil jeder Fakt endlich im Tier liegt, dessen Preis zu seinem Zugriffsmuster passt.

Der Grund, warum das bei sechzig Sitzen funktioniert und bei sechs nicht funktionieren würde, ist, dass Sabine bereits Postgres hat, bereits einen Entwickler im Haus, der eine Migration schreiben kann, und bereits für die Tokens zahlt, die der Cache-Header eliminieren wird. Das Tier-Upgrade ist billiger als die Posten, die es entfernt.

Wie du den Tier ohne Sechs-Monate-Spike wählst

Tier-Auswahl ist eine Eine-Seite-Entscheidung, kein Forschungsprojekt. Ich liefere diese Matrix an Kunden, und die Konversation dauert dreißig Minuten:

| Use-Case-Form | Default-Tier | Upgrade-Trigger | |---|---|---| | FAQ-Bot, unter dreißig Turns pro Session | Sliding Window + Prompt Caching | Recall unter 90 % auf nuanciertem Eval | | Planungsassistent, dreißig bis hundert Turns | Hierarchisch | Compliance-Bedarf für wörtlichen Recall | | CRM- oder Finanz-Agent, jeder Fakt zählt | Entity Graph oder Semantic Store | Hybrid, nur wenn Sliding Window den Smalltalk abdeckt | | Compliance-Log-Rückblick | Archival mit On-Demand-Pull | Lesehäufigkeit über einmal pro Session pro Record |

Drei Regeln gehen mit der Matrix. Erstens, instrumentiere den Recall-Spalt, bevor du das Upgrade vorschlägst; pick fünf nuancierte Fragen, die in deinen echten Daten hinter Turn dreißig leben, und melde die Miss-Rate. Zweitens, bench nie mit weniger als sechzig Seed-Nachrichten, weil unter dreißig jeder Tier perfekt aussieht. Drittens, behalte Sliding Window als Default für neunzig Prozent des Routine-Traffics, auch nachdem du Entity Graph adoptiert hast, und route nur Premium-Anfragen in den teuren Tier; das Hybridmuster ist, was die Kostenmathematik tragfähig macht.

Montagsschritt: Nimm deine drei produktionsstärksten Agents, lass sie durch die Matrix fallen und schreib daneben jeweils die Tier-Mismatch-Position. Der Agent, der gerade nur Working Memory für einen Fakt nutzt, der hinter Turn dreißig lebt, kostet dich still am meisten, und ihn reparierst du diese Woche.

Offene Fragen

Ich beobachte weiter drei Stränge dazu. Erstens, die Toolkits, die Microsoft im Juni 2026 rund um Agent-Memory und Agentic Retrieval vorgestellt hat, senken die Kosten, einen Entity Graph in kleinem Maßstab zu betreiben; ob sie die Break-Even-Größe auf zwanzig Sitze drücken oder auf dem F500-Boden bleiben, erwarte ich nach ein paar echten Builds zu aktualisieren. Zweitens, gerade der Prompt-Caching-Tier bewegt sich schnell bei Workspace-Isolation und TTL-Semantik, sodass die Cache-als-Tier-Mathematik dieses Jahr zweimal kippen kann. Drittens, die strittigen LOCOMO-Zahlen zwischen Vendors stören mich weiter; ich will unabhängige Reproduktion mit geteilten Seeds sehen, bevor ich irgendeiner Vendor-Recall-Zahl für eine Architekturentscheidung traue.

Wenn die nächsten zwölf Monate etwas Stabiles zu Agent-Memory beweisen, dann, dass das Tiering-Vokabular bleibt. Die Kostenzahlen werden sich bewegen; das Prinzip, dass der Tier das Modell dominiert, nicht.

Notizen abgleichen. Sitzt du auf einem Agent, dessen Tokenrechnung weiter driftet, und dein Reflex ist zu fragen, welches Modell du tauschen sollst, würde ich dagegenhalten und fragen, welchen Tier du eigentlich bezahlst. Ich fahre diese Übung alle paar Wochen mit Mittelstandsteams, üblicherweise in einer Ein-Stunden-Arbeitssitzung, die mit einer einzelnen Seite Tier-Labels endet. Willst du Notizen zur aktuellen Kostenkurve abgleichen oder das Framing zurückspielen, ist die Kontaktseite die richtige Tür. Mich interessieren besonders Fälle, in denen die Tier-Matrix oben bei dir gebrochen ist, weil diese Fälle die Doktrin nach vorn bringen.

Ressourcen