Agentic Memory Realized – Von zustandslosen Modellen zu kognitiver Kontinuität

Die meisten KI-Agenten im Unternehmenseinsatz leiden unter demselben strukturellen Problem: Sie vergessen. Nach jeder Sitzung ist der Kontext weg, die Beziehung zurückgesetzt, die Entscheidungshistorie gelöscht. Für einfache Assistenten ist das tolerierbar. Für Agenten, die komplexe, mehrstufige Aufgaben über Zeit hinweg übernehmen sollen, ist es ein Architekturversagen.

Dieses Whitepaper untersucht, warum Memory zur zentralen Design-Herausforderung für langläufige KI-Agenten geworden ist – und wie Unternehmen die richtigen Architekturentscheidungen treffen können. Es analysiert die wichtigsten Memory-Ansätze, erklärt die jeweiligen Kompromisse und zeigt anhand eines vergleichenden Experiments, welche Architekturen welche Arten von Wert bewahren: von faktischem Abruf über Zielkontinuität bis hin zu Verhaltensmustern über Zeit.

Die wichtigsten Erkenntnisse:

• Memory ist eine architektonische Anforderung, keine optionale Funktion. Sobald KI-Agenten über einzelne Interaktionen hinaus operieren, wird Memory Teil des Kernsystemdesigns – nicht ein Add-on.
• Context Replay ist kein echtes Langzeitgedächtnis. Frühe Ansätze simulieren Kontinuität durch Wiederverwenden vergangener Konversationen. Sie liefern jedoch keine zuverlässige, dauerhafte Erinnerung über längere Aufgaben und Sitzungen hinweg.
• Verschiedene Architekturen bewahren verschiedene Arten von Wert. Manche Designs sind besser bei der Speicherung expliziter Fakten, andere bei der Beibehaltung von Zielen oder Verhaltensmustern. Die richtige Wahl hängt davon ab, was der Agent erinnern muss.

• Kognitive Kontinuität ist wichtiger als simpler Abruf. Effektives Memory muss einem Agenten helfen, vergangene Informationen so zu nutzen, dass konsistentes Denken und Handeln über Zeit möglich wird.

   

  Autoren: 
  Mingyang Ma — Head of Agentic AI Solutions Development, appliedAI Initiative GmbH 
  Harsh Gurawaliya — Junior AI Engineering LLM, appliedAI Initiative GmbH 
  Dr Malte Nalenz — Generative AI Engineer, appliedAI Initiative GmbH 
  
  Laden Sie jetzt das vollständige Whitepaper herunter und erfahren Sie, wie Sie Agentensysteme bauen, die nicht bei null beginnen – sondern mit jedem Einsatz besser werden.

Stellen Sie sich vor, Sie nutzen über Ihren gesamten Arbeitstag hinweg einen KI-Assistenten. Er hilft Ihnen, Dokumente zusammenzufassen, Code zu prüfen und technische Probleme zu durchdenken. In einem Gespräch erläutern Sie Ihre Projektarchitektur, beschreiben ein Deployment-Problem und bitten um Vorschläge. Der Assistent antwortet hilfreich und scheint die Situation zu verstehen.

Am nächsten Tag kehren Sie zurück und stellen eine Anschlussfrage. Der Assistent antwortet, als hätte das frühere Gespräch nie stattgefunden.

Das war nicht einfach ein Produktfehler oder eine vorübergehende Einschränkung. Es spiegelte eine tieferliegende architektonische Realität wider: Frühe KI-Systeme waren nicht darauf ausgelegt, Memory über Interaktionen hinweg zu bewahren. Sie konnten die in einer Anfrage bereitgestellten Informationen verarbeiten, waren aber nicht dafür gebaut, diese Informationen über die Zeit hinweg weiterzutragen.

Diese Einschränkung zu verstehen, ist der Ausgangspunkt dafür, zu verstehen, warum Memory zu einem so wichtigen Problem in modernen KI-Systemen wurde.

Zustandslose Sprachmodelle

Die erste Generation von Anwendungen auf Basis großer Sprachmodelle arbeitete als zustandslose Inferenzsysteme. Ein Prompt wurde übergeben, das Modell generierte einen Output, und die Transaktion war beendet. Bei der nächsten Anfrage verarbeitete das Modell einen neuen Prompt, ohne jegliches inhärente Bewusstsein dafür, was zuvor geschehen war.

Auf konzeptioneller Ebene ließ sich die Interaktion auf ein einfaches Muster reduzieren:

response = LLM(prompt)

Das Modell konnte ausschließlich über die Informationen schlussfolgern, die zum Inferenzzeitpunkt innerhalb dieses Prompts verfügbar waren. Alles, was im Input ausgelassen wurde, war für die Welt des Modells faktisch nicht vorhanden.

Das folgt unmittelbar daraus, wie Transformer-basierte Systeme konzipiert wurden.¹ Sie sind hochwirksam darin, eine im aktuellen Aufruf präsentierte Sequenz zu verarbeiten, bewahren aber nicht von Natur aus einen persistenten Zustand zwischen separaten Aufrufen.

Praktisch betrachtet: Das Modell kann über den Text schlussfolgern, den es jetzt erhält, trägt das Wissen aber nicht automatisch in künftige Interaktionen weiter.

Diese Unterscheidung ist deshalb von Bedeutung, weil sie Sprachgewandtheit von Memory trennt. Ein Modell kann innerhalb eines einzelnen Austauschs konsistent, informiert und kontextbewusst klingen – und dennoch keinerlei belastbare Möglichkeit besitzen, Informationen über die Zeit hinweg zu behalten.

Das Context Window als temporäres Arbeitsgedächtnis

Um frühe KI-Systeme über ein Gespräch hinweg kohärenter wirken zu lassen, begannen Entwickler, frühere Nachrichten erneut in jeden neuen Prompt einzuspeisen. Benötigte der Assistent Informationen aus vorangegangenen Austauschen, schickte die Anwendung dieses Material zusammen mit der aktuellen Anfrage erneut mit.

Dieser Ansatz beruht auf dem Context Window: der Textmenge, die ein Modell in einem einzelnen Inferenzaufruf verarbeiten kann. Mit wachsenden Context Windows wurden Systeme in der Lage, längere Gespräche, größere Dokumente und komplexere Anweisungen innerhalb einer Anfrage zu bewältigen. In der Praxis war diese Ausweitung dramatisch: Frühe, weit verbreitete Systeme arbeiteten mit nur wenigen tausend Tokens Kontext, spätere Modelle dehnten diese Kapazität auf mehr als hunderttausend aus, und einige Systeme stießen schließlich über die Grenze von einer Million Tokens hinaus. Diese Steigerungen machten Modelle für ausgedehnte Gespräche und die Verarbeitung großer Dokumentmengen nützlicher, schufen aber kein belastbares Memory über die Zeit hinweg.

Die Ausweitung des Context Windows änderte nichts an der grundlegenden Einschränkung. Sie verbesserte die kurzfristige Wiedergabe innerhalb einer Interaktion, schuf aber kein persistentes Memory über die Zeit.

Ein Context Window versteht man daher am besten als temporäres Arbeitsgedächtnis und nicht als Langzeitgedächtnis. Bei jeder neuen Anfrage muss das System entscheiden, welche früheren Informationen es einbezieht, was es zusammenfasst und was es weglässt. Das Modell bewahrt die Vergangenheit nicht von sich aus; es kann nur über jenen rekonstruierten Kontext schlussfolgern, der ihm im aktuellen Aufruf mitgegeben wird. Diese Analogie wurde in MemGPT explizit gemacht, wo das begrenzte Context Window von Sprachmodellen mit der begrenzten Kapazität des menschlichen Arbeitsgedächtnisses verglichen wurde.

Diese Unterscheidung ist wichtig. Frühe Systeme konnten über eine Session hinweg kohärent erscheinen, doch diese Kohärenz beruhte vor allem auf Prompt-Rekonstruktion und Logik auf Anwendungsebene – nicht auf einer persistenten Memory-Architektur, die für langfristiges Verhalten ausgelegt war.

Die strukturellen Grenzen kontextbasierten Memorys

Als Entwickler diese Systeme in reale Workflows überführten, wurden die Grenzen der Kontextrekonstruktion zunehmend sichtbar.

Erstens: Kontext läuft über. Wenn Gespräche, Dokumente oder Tool-Traces das verfügbare Window überschreiten, müssen frühere Informationen entfernt, zusammengefasst oder abgeschnitten werden. Das Ergebnis ist selektives Vergessen. Wichtige Projektdetails, frühere Entscheidungen oder vorangegangene Rahmenbedingungen können schlicht deshalb verschwinden, weil sie nicht mehr hineinpassen.

Zweitens: Kontext ist nicht persistent. Der Session-Verlauf existiert nur so lange, wie eine Anwendung ihn speichert und erneut übermittelt. Sobald der Nutzer das Gespräch verlässt, das Gerät wechselt oder einen neuen Thread beginnt, muss Kontinuität extern wiederhergestellt werden. Ohne Speicherung außerhalb des Modells verfügt das System über kein belastbares Memory früherer Interaktionen.

Drittens: Lange Prompts garantieren keine verlässliche Wiedergabe. Selbst wenn mehr Text in das Window passt, behandeln Modelle nicht alle Teile des Prompts gleich. Diese Einschränkung wurde in „Lost in the Middle: How Language Models Use Long Contexts" herausgestellt, wo festgestellt wurde, dass die Modellleistung häufig abfällt, wenn relevante Informationen in der Mitte eines langen Kontexts erscheinen statt nahe am Anfang oder Ende. Anders gesagt: Mehr Raum erzeugt nicht automatisch bessere Kontinuität. Er kann schlicht einen größeren Bereich schaffen, in dem wichtige Fakten schwerer abzurufen sind.

Es ist zudem erwähnenswert, dass alternative Architekturen dieses Problem nicht automatisch lösen. Systeme wie Mamba und verwandte State-Space-Modelle bieten Sequenzverarbeitung in linearer Zeit und unterhalten eine Form von rekurrentem Zustand, liefern aber von sich aus dennoch kein sessionübergreifendes Memory. Ihr interner Zustand wird zwischen separaten Aufrufen zurückgesetzt – genau wie der Key-Value-Cache eines Transformers. Persistenz erfordert weiterhin etwas außerhalb des Modells selbst.

Zusammengenommen offenbarten diese Einschränkungen eine wichtige Wahrheit: Kontext allein ist ein instabiles Fundament für Memory.

Warum dies zu einer wesentlichen Einschränkung für KI-Agenten wurde

Für eng umrissene, einmalige Aufgaben sind zustandslose Systeme oft ausreichend. Ein Modell, das eine einzelne Frage beantwortet, ein Dokument zusammenfasst oder einen Absatz entwirft, muss sich womöglich an nichts über die unmittelbare Anfrage hinaus erinnern.

Das ändert sich, sobald KI-Systeme als Agenten statt als isolierte Antwortgeber operieren. Von einem Agenten wird erwartet, dass er über mehrere Schritte hinweg arbeitet, Ziele aufrechterhält, Werkzeuge nutzt, sich an Zwischenergebnisse anpasst und über die Zeit hinweg zu laufenden Aufgaben zurückkehrt. In diesem Kontext ist Memory keine Annehmlichkeit mehr. Es wird zur Notwendigkeit. Ein Software-Engineering-Agent sollte sich an frühere Debugging-Versuche und Systembeschränkungen erinnern. Ein Research-Agent sollte Arbeitshypothesen, Bewertungen der Quellenqualität und offene Fragen behalten. Ein Produktivitätsagent sollte Nutzerpräferenzen, wiederkehrende Prioritäten und unerledigte Aufgaben bewahren. Ohne Memory beginnt jede Interaktion zu nah an null. Das System mag wortgewandt bleiben, doch es kann kein Verständnis akkumulieren.

An diesem Punkt wurden die Einschränkungen früher Architekturen operativ bedeutsam. Was in einem Chatbot akzeptabel wirkte, wurde in agentischen Systemen zu einem ernsten Engpass.

Frühe Versuche zur Kompensation

Die erste Welle von Lösungen behandelte Memory als Behelfslösung auf Anwendungsebene. Entwickler hängten den Chat-Verlauf an, fügten Zusammenfassungen früherer Austausche ein und nutzten leichtgewichtige Frameworks, um Kontinuität über kurze Sessions hinweg zu bewahren. Diese Techniken waren nützlich und in vielen Fällen notwendig. Doch sie blieben Erweiterungen rund um einen zustandslosen Kern.

Mit zunehmender Autonomie der Systeme und über längere Zeithorizonte gespannten Workflows traten die Grenzen dieser Methoden deutlicher hervor. Gesprächsverlauf, Zusammenfassung und Prompt-Kompression konnten nützlichen Kontext bewahren und bleiben in vielen Systemen ein wichtiger Teil des Gesamtdesigns. Für sich genommen tun sich diese Techniken jedoch oft schwer damit, jenes belastbare, strukturierte und selektiv abrufbare Memory bereitzustellen, das anspruchsvollere, langläufige Agenten erfordern.

Diese Erkenntnis markierte einen wichtigen Denkwandel. Memory ließ sich nicht länger als Prompt-Engineering-Kniff begreifen. Es musste als zentrales Systemproblem behandelt werden: Was sollte gespeichert werden, wie sollte es abgerufen werden, wann sollte es aktualisiert werden, und wie sollte es künftiges Verhalten prägen.

Dieser Wandel bereitete die Bühne für die nächste Phase im Design von KI-Systemen: den Übergang von temporärer Kontextrekonstruktion zu expliziten Memory-Architekturen.

Frühe Sprachmodell-Anwendungen simulierten Memory, statt es zu besitzen. War Kontinuität erforderlich, fügten Entwickler vorangegangene Gesprächszüge in den nächsten Prompt ein. Das verbesserte die kurzfristige Kohärenz, schuf aber kein persistentes Memory: War der Prompt erst einmal verschwunden, besaß das System keine belastbare Repräsentation der Vergangenheit.

Als sich KI-Systeme von konversationellen Schnittstellen zu autonomeren Agenten weiterentwickelten, wurde diese Einschränkung deutlich schwerer zu ignorieren. Von Agenten wurde erwartet, dass sie Ziele über mehrere Schritte hinweg verfolgen, Werkzeuge nutzen, auf Zwischenergebnisse reagieren und zu unerledigter Arbeit zurückkehren. In diesem Kontext reichte das Wiedereinspielen von Gesprächsfragmenten nicht mehr aus. Ein Agent musste Informationen behalten, sie bei Relevanz abrufen und in spätere Schlussfolgerungen integrieren. Die Entwicklung von Agent-Memory von etwa 2020 bis 2026 lässt sich daher als Übergang von der Prompt-Rekonstruktion hin zu expliziteren, in das Design des Agenten selbst integrierten Memory-Architekturen verstehen. Diese Meilensteine sind keine strenge Taxonomie, doch sie verdeutlichen den umfassenderen Wandel von der temporären Kontextverarbeitung hin zu einem bewussten Memory-Design.

Kontinuität auf Prompt-Ebene

Die früheste praktikable Technik zur Aufrechterhaltung von Kontext war das Conversation Replay. Anwendungen speicherten frühere Nachrichten und hängten sie an neue Prompts an, sodass das Modell die jüngste Interaktionshistorie „sehen" konnte. Frameworks ergänzten Buffering, Sliding Windows und Zusammenfassung, um dies handhabbar zu machen.

Für einfache Assistenten war das oft gut genug. Es ließ das Modell antworten, als erinnerte es sich an das soeben Besprochene. Doch das Memory blieb fragil: Die scheinbare Erinnerungsfähigkeit des Systems hing vollständig vom Context Window ab und davon, wie die Anwendung jeden Prompt zusammensetzte. Wichtige Details konnten abgeschnitten, wegzusammengefasst oder ausgelassen werden.

Conversation Replay bewahrte daher Gesprächsfragmente, schuf aber kein persistentes Memory.

Der Aufstieg autonomer Agenten

Diese Grenzen wurden deutlich klarer, als Entwickler begannen, autonome Agenten zu bauen. Anders als Chat-Assistenten sollten diese Systeme Ziele zerlegen, über mehrere Schritte hinweg planen, Werkzeuge nutzen und sich an Zwischenergebnisse anpassen. ReAct ist ein gutes frühes Beispiel: Es verschränkte Reasoning-Traces mit Aktionen und zeigte starke Ergebnisse auf ALFWorld und WebShop, womit es deutlich machte, dass mehrstufige Leistung davon abhängt, nachzuverfolgen, was bereits beobachtet und versucht wurde.

Derselbe Druck zeigte sich bei praktischen Softwareaufgaben. SWE-bench bewertet Agenten anhand realer GitHub-Issues über vollständige Repositories hinweg, und SWE-agent wurde gebaut, um Code innerhalb dieser Umgebungen autonom zu durchsuchen, zu navigieren, zu bearbeiten und zu testen. In solchen Settings hört Kontinuität auf, eine UX-Annehmlichkeit zu sein, und wird zur operativen Anforderung: Der Agent muss nachverfolgen, was er inspiziert, verändert und versucht hat.

Frühe Agentensysteme legten auch offen, wie instabil das Verhalten über lange Zeithorizonte ohne gutes Memory sein konnte. Projekte wie Auto-GPT machten Zielschleifen und Aufgabenzerlegung populär, doch sie zeigten zugleich, wie leicht Agenten dieselben Ideen erneut aufgreifen, frühere Ergebnisse aus den Augen verlieren oder von fragilem Prompt-Zustand abhängen konnten.

Aus diesem Grund wurde Memory mehr als ein Komfort-Feature. In „Generative Agents" wird Verhalten nicht nur durch gespeicherte Beobachtungen geprägt, sondern auch durch Retrieval und übergeordnete Reflexion im Zeitverlauf. Die übergreifende Lehre lautete: Sobald von Agenten erwartet wird, über ausgedehnte Zeithorizonte zu operieren, brauchen sie einen Weg, Erfahrung zu akkumulieren und wiederzuverwenden, statt die Gegenwart wiederholt von Grund auf zu rekonstruieren.

Retrieval-Augmented Memory

Ein belastbarerer Schritt entstand, als Entwickler begannen, externe Speichersysteme an Sprachmodell-Anwendungen anzudocken. Statt sich nur auf die Prompt-Historie zu verlassen, konnten Systeme Informationen unabhängig speichern und relevante Elemente in späteren Interaktionen abrufen.

Dieses Design-Pattern ist eng mit Retrieval-Augmented Generation, kurz RAG, verwandt. Lewis et al. führten RAG als Framework ein, das ein Sprachmodell mit einem Retriever kombiniert, der auf einen externen Wissensindex zugreift, sodass die Generierung von abgerufenen Informationen gespeist werden kann, statt sich allein auf parametrisches Memory zu stützen.

In Agentensystemen reichte diese Idee über das reine Dokumenten-Retrieval hinaus. Memory-Stores konnten Nutzerpräferenzen, Aufgabeninformationen, Projektkontext oder vergangene Ereignisse vorhalten. Traf eine neue Anfrage ein, konnte das System den Memory-Store nach relevanten Elementen durchsuchen und die Ergebnisse in den Arbeitskontext des Modells einspeisen.

Das verbesserte die Kontinuität über Sessions hinweg erheblich. Wichtiger noch: Es markierte einen Wandel hin zur Behandlung von Memory als eigenständiger Systemkomponente, statt sich primär auf das Wiedereinspielen oder Komprimieren früherer Gespräche zu verlassen. Zugleich brachte retrieval-basiertes Memory seine eigene Einschränkung mit sich: Gespeicherte Informationen blieben nur dann nützlich, wenn der Retrieval-Mechanismus sie im richtigen Moment hervorbrachte. Relevanter Kontext konnte gespeichert, aber ungenutzt bleiben.

Von gespeicherten Fakten zu gespeicherten Erfahrungen

Es folgte ein zweiter konzeptioneller Wandel. Forscher und Systemdesigner begannen zu untersuchen, ob Agenten nicht nur isolierte Fakten, sondern auch Erfahrungen speichern sollten.

Das veränderte die Rolle von Memory. Statt nur einzelne Informationsfragmente zu bewahren, konnte Memory Ereignisse, Beobachtungen, frühere Entscheidungen und Interaktionsmuster über die Zeit hinweg repräsentieren. Ein Debugging-Assistent muss womöglich abrufen, welche Fixes bereits versucht wurden und warum sie fehlschlugen; ein Research-Assistent muss sich möglicherweise an frühere Hypothesen erinnern und daran, wie spätere Evidenz sie verändert hat.

„Generative Agents" machte diese Idee besonders sichtbar, indem es Beobachtung, Retrieval, Reflexion und Planung kombinierte, sodass späteres Verhalten von akkumulierter vorheriger Erfahrung abhing und nicht allein von isoliert gespeicherten Fakten. Fakten unterstützen die Wiedergabe. Erfahrungen unterstützen das Verhalten.

Persistentes Memory wurde damit mehr als eine Datenbankoptimierung. Es wurde zum Mechanismus, um Kontinuität in Reasoning und Handeln aufrechtzuerhalten.

Memory als hierarchisches System

Mit der Reifung von Memory-Systemen kam eine weitere wichtige Design-Erkenntnis auf: Nicht jedes Memory sollte auf dieselbe Weise behandelt werden.

Das Context Window des Modells wurde als eine Form von Arbeitsgedächtnis verstanden – nützlich für unmittelbares Reasoning, aber begrenzt in Kapazität und Dauer. Externer Speicher diente als längerfristige Memory-Schicht, die Informationen über Sessions hinweg und über längere Zeithorizonte bewahrte. Manche Architekturen fügten Zusammenfassungen oder spezialisierte Stores hinzu, um die Lücke zwischen beiden zu überbrücken.

MemGPT machte diesen Wandel besonders explizit, indem es begrenzten Kontext als Systemproblem behandelte und ein gemanagtes Verschieben über Memory-Ebenen hinweg vorschlug, statt anzunehmen, alles Relevante müsse zugleich im aktiven Prompt verbleiben.

Sobald Memory so begriffen wird, wird das Design-Problem anspruchsvoller. Die Frage lautet nicht mehr bloß, was zu speichern ist, sondern: Was gehört in den aktiven Kontext, was sollte im persistenten Speicher verbleiben, was sollte zu übergeordnetem Wissen abstrahiert werden, und was sollte vergessen werden.

Graph Memory und der Schritt hin zur Infrastruktur

Bis zur Mitte des Jahrzehnts war Memory nicht mehr bloß ein Hilfs-Feature, das Chat-Anwendungen hinzugefügt wurde. Es wurde zu einer Infrastrukturschicht für intelligente Systeme. Agent-Frameworks integrierten zunehmend persistenten Zustand, strukturierte Workflows und Mechanismen zur Aufrechterhaltung von Kontinuität über längere Prozesse und über mehrere kollaborierende Agenten hinweg.

Ein wichtiger Teil dieses Wandels war das Aufkommen graphbasierter Memory-Systeme. Statt Memory nur als isolierte Textfragmente oder Embeddings zu speichern, begannen diese Systeme, Entitäten, Ereignisse und deren Beziehungen in stärker strukturierter Form zu repräsentieren. Zep, aufgebaut auf der Graphiti-Engine, ist ein nützliches Beispiel: Es führte einen zeitlich bewussten Knowledge-Graph-Ansatz ein, der nicht nur nachverfolgen kann, was gespeichert wurde, sondern auch, wann etwas geschah und wie es sich über die Zeit veränderte. Das hilft, Schwächen zu adressieren, mit denen reine Retrieval-Systeme oft konfrontiert sind, darunter temporales Reasoning, Entity Resolution und sich verändernde Fakten über langläufige Interaktionen hinweg.

Diese Veränderung spiegelte eine umfassendere Erkenntnis im gesamten Feld wider: Fortgeschrittene Agenten können sich nicht allein auf Prompt-Tricks verlassen. Sie benötigen Memory-Architekturen, die Persistenz, Retrieval, Abstraktion und Anpassung über die Zeit hinweg unterstützen. Der Weg von RAG über ReAct-artige Agent-Loops und reflexionsbasierte Agenten hin zu mehrstufigen Memory-Systemen und stärker strukturiertem, graphbasiertem Memory macht diese Entwicklung sichtbar.

Was als Behelfslösung für zustandslose Modelle begann, wurde zu einer grundlegenden Komponente im Design von KI-Systemen.

Von Kontinuität zu Architektur

Die Entwicklung von Agent-Memory spiegelt einen Übergang von temporärer Kontinuität zu belastbarem Systemdesign wider. Frühe Systeme simulierten Memory, indem sie den Gesprächsverlauf wiedereinspielten. Fortgeschrittenere Systeme externalisierten Memory, riefen es selektiv ab und behandelten es zunehmend als strukturierte Komponente der Agentenarchitektur selbst.

Memory war nicht mehr bloß ein Komfort-Feature. Es wurde essenziell dafür, wie Agenten operieren. Die nächste Herausforderung bestand jedoch nicht einfach darin, mehr Informationen zu speichern. Sie bestand darin, Informationen so zu organisieren und abzurufen, dass Bedeutung statt Rauschen bewahrt wurde.

Das ist das Design-Problem, das im nächsten Kapitel behandelt wird.