Was mein Agentenstapel eigentlich macht

Mein Wirkstoffstapel ist, wie ich Dogfood Neotoma verwende. Es ist auch mein persönliches Betriebssystem. Ein privates Monorepo, in dem KI-Agenten alles von der E-Mail-Triage über Bitcoin-Zahlungen bis hin zur Website-Bereitstellung erledigen, mit Neotoma als strukturiertem Speicher darunter.

Jede Funktion, die ich in Neotoma bereitstelle, wird hier zuerst validiert, hauptsächlich in Cursor und zweitens über Terminalagenten wie Claude Code, Codex und Cursor CLI. Jede Lücke, die ich im Agentengedächtnis finde, kommt hier zuerst zum Vorschein. Der Stack ist die Art und Weise, wie ich mein tägliches Leben und meine Arbeit leite. Die Reibung, auf die ich stoße, ist neben dem Feedback der Benutzer der Antrieb für die Neotoma-Roadmap.

Ich beabsichtige, den Stack als Open Source bereitzustellen. Aber das Repo hat monatelang persönliche Daten, in meinen Konten fest codierte Skripte und an mein Setup gebundene Konfigurationen angesammelt. Bevor es veröffentlicht werden kann, muss ich diese Daten vollständig in Neotoma übertragen und die Tools so umgestalten, dass sie generisch sind. Diese Arbeit ist noch nicht abgeschlossen.

In diesem Beitrag wird erklärt, was der Stack ist, wie ich ihn verwende und was er über die Aufgaben des strukturierten Agentenspeichers verrät.

Was ist der Stapel?

Der Stack ist ein Monorepo mit über einem Dutzend MCP Servern und CLIs, die jeweils KI-Agenten mit einem anderen Dienst verbinden: Gmail, Google Kalender, WhatsApp, a Bitcoin-Wallet, Instagram, Asana, HomeKit, DNSimple, Google Search Console, 1Password, ein Web Scraper und mehr. Bei einigen handelt es sich um MCP-Server, die von Agenten als Tools bezeichnet werden. Andere sind CLIs, die Agenten vom Terminal aus aufrufen. Beide bieten Agenten dasselbe: Zugang zu externen Diensten.

Auf den MCP-Servern liegen Regeln und Fähigkeiten. Regeln sind dauerhafte Verhaltensanweisungen, die im Repo und nicht in Neotoma gespeichert sind: Speichern Sie Kontakte immer in Neotoma, bevor Sie antworten, geben Sie niemals Geheimnisse bekannt, verwenden Sie in Titeln die Groß- und Kleinschreibung von Sätzen, führen Sie Tests nach Codeänderungen durch, bevorzugen Sie CLI gegenüber dem Dashboard für Protokolle und Konfigurationen, verknüpfen Sie die erste Erwähnung von Produktnamen. Fähigkeiten sind mehrstufige Arbeitsabläufe: meinen Posteingang durchsuchen, einen Blog-Beitrag verfassen, eine Website bereitstellen, Produkt-Feedback verarbeiten, eine Amazon-Bestellung aus einer E-Mail extrahieren, einen Auftragnehmer in Bitcoin bezahlen.

Und unter allem sitzt Neotoma als strukturierte Gedächtnisschicht. Jeder Agent liest daraus und schreibt darauf. Das ist es, was dazu führt, dass sich der Stapel mit der Zeit erhöht, anstatt dass er bei jeder Sitzung zurückgesetzt wird.

Wie ich damit arbeite

Ich wohne in Cursor. Mein Tag besteht aus einer Abfolge von Agentensitzungen. Ich öffne einen neuen Agenten, beschreibe, was ich tun möchte, und der Agent wird mithilfe der MCP-Server, Regeln und Fähigkeiten im Arbeitsbereich ausgeführt. Einige Sitzungen sind schnell: „Auf diese E-Mail antworten.“ Einige sind lang: „Durchsuchen Sie meinen Posteingang, verarbeiten Sie das neueste Tester-Feedback und verfassen Sie dann einen vergleichenden Beitrag über [Googles Speicheragenten] (/posts/always-on-memory-agents-and-the-truth-layer).“

Es handelt sich um ein Coworking mit Agenten. Ich sitze den ganzen Tag an meinem Schreibtisch und arbeite mit ihnen zusammen. Persönliche Aufgaben: Planung einer Reparatur, Bezahlung eines Auftragnehmers, Verwaltung von Kalenderereignissen. Beruflich: Beiträge schreiben, Feedback verarbeiten, Websites bereitstellen, Domains verwalten. Die Agenten kümmern sich um die Ausführung. Ich gebe Anweisungen, überprüfe die Ergebnisse und genehmige Maßnahmen, bei denen ein Mensch auf dem Laufenden bleiben muss.

Jede Agentensitzung verfügt über den vollständigen Arbeitsbereichskontext: jeden MCP-Server, jede Regel, jeden Skill. Der Agent kann mein Gmail lesen, meinen Kalender überprüfen, Neotoma nach vorherigem Kontext abfragen, neue Daten speichern, Bilder generieren, Code pushen und Bereitstellungen überprüfen. Meine Rolle besteht zunehmend darin, Absichten zu beschreiben und Ergebnisse zu überprüfen.

Wie Neotoma passt

Ohne strukturierten Speicher beginnt jede Agentensitzung bei Null. Der Agent weiß nicht, wer Ihre Ansprechpartner sind, welche Aufgaben Sie offen haben, was Sie gestern besprochen haben oder was Sie jemandem bereits bezahlt haben. Sie können Kontext in jede Eingabeaufforderung einfügen, dies funktioniert jedoch nicht über mehrere Sitzungen hinaus. Plattformspeicher speichert Ihre Stimmung, nicht Ihre Arbeit. RAG hilft beim Code, aber nicht bei den strukturierten Fakten, die Arbeitsabläufe steuern: wem Sie Geld schulden, welches Feedback Sie letzte Woche erhalten haben, welche Aufgaben noch offen sind.

Meine Neotoma-Instanz speichert über 1.000 Kontakte, 600 Aufgaben, 140 Konversationen, 120 Blogbeiträge und 170 Entitätstypen, die Agenten erstellt haben, als sie auf neue Arten von Informationen stießen: Transaktionen, Geschäftsregeln, Feedbacknotizen, Kalenderereignisse, Streitigkeiten, Rechnungen, Fähigkeiten, Bereitstellungsergebnisse. Wenn ein Agent eine neue Sitzung startet, ruft er ab, was er benötigt. Wenn es fertig ist, speichert es, was es gelernt hat.

Hier sind die 20 wichtigsten Entitätstypen in meiner heutigen Neotoma-Instanz, mit jeweils einem Beispiel:

Keines dieser Schemata wurde im Voraus entworfen. Agenten erstellen und erweitern Schemata nach Bedarf, wenn sie auf neue Arten von Informationen stoßen. Das System verfügt nun über insgesamt 170 Entitätstypen, die meisten davon mit nur einer Handvoll Datensätzen. Der lange Schwanz ist der Punkt, an dem das Agentengedächtnis interessant wird: eine einzelne Streiteinheit mit ihrer vollständigen Verhandlungshistorie, eine einzige Verpflichtung, mit jemandem Kontakt aufzunehmen, wenn sich die Strategie ändert, eine einzige Präferenz für die Abwicklung einer bestimmten Zahlung.

Der praktische Unterschied besteht darin, dass Agenten auf früheren Arbeiten aufbauen. Wenn ich einen Agenten bitte, jemandem eine E-Mail zu senden, durchsucht er Neotoma zuerst nach dem Kontakt. Wenn ich es auffordere, Feedback zu verarbeiten, ruft es vorhandene Feedback-Entitäten ab und verknüpft neue. Wenn ich es auffordere, einen Auftragnehmer in Bitcoin zu bezahlen, kennt es die geltende Regel (bezahlen Sie diese Person immer in BTC) und fügt den Transaktionslink in die Bestätigung ein, weil eine andere geltende Regel dies vorschreibt.

Ein- und Auslagern hautnah

Das Neotoma MCP stellt Tools bereit, die Agenten direkt aufrufen. So sieht echtes Ein- und Auslagern in der Praxis aus.

Wenn ein Agent eine Konversationsrunde mit extrahierten Entitäten aufrechterhalten muss, ruft er „store“ mit einer einzigen Nutzlast auf:

„json speichern({ „Entitäten“: [ { „entity_type“: „Konversation“, „title“: „E-Mail-Triage 9. März“ }, { „entity_type“: „agent_message“, „role“: „Benutzer“, „content“: „Meinen Posteingang durchsuchen“, „turn_key“: „conv-42:1“ }, { „entity_type“: „Kontakt“, „full_name“: „Alex Chen“, „email“: „alex@example.com“, „Quelle“: „Tester-Feedback-Anruf“ }, { „entity_type“: „Aufgabe“, „title“: „Verfolgen Sie das Feedback von Alex“, „Status“: „ausstehend“, „Priorität“: „mittel“ } ], „Beziehungen“: [ { „relationship_type“: „PART_OF“, „source_index“: 1, „target_index“: 0 }, { „relationship_type“: „REFERS_TO“, „source_index“: 1, „target_index“: 2 }, { „relationship_type“: „REFERS_TO“, „source_index“: 1, „target_index“: 3 } ], „idempotency_key“: „conv-42-turn-1-triage“ }) „

Ein Anruf speichert die Konversation, die Nachricht, einen neuen Kontakt und eine Aufgabe, die alle durch typisierte Beziehungen verknüpft sind. Der Agent benötigte vorher keine Schemadefinition für „Kontakt“ oder „Aufgabe“. Neotoma akzeptiert beliebige Felder und leitet daraus die Struktur ab.

Wenn ein Agent einen Kontext benötigt, bevor er antwortet, fragt er nach der Kennung ab:

„json abrufen_entity_by_identifier({ „Bezeichner“: „Alex Chen“ }) „

Dadurch wird der Kontaktdatensatz mit E-Mail, früheren Gesprächen und der Herkunft jedes Felds zurückgegeben. Wenn der Agent einen breiteren Kontext benötigt, fragt er nach Typ ab:

„json abrufen_entitäten({ „entity_type“: „feedback_note“, „Suche“: „Entwicklerversion“, „Grenze“: 10 }) „

Dadurch werden die zehn relevantesten Feedbacknotizen zur Entwicklerversion zurückgegeben, jeweils mit vollständigem Snapshot und Beobachtungsverlauf.

Bei Dauerregeln ruft der Agent diese einmalig zu Beginn eines Workflows ab:

„json abrufen_entitäten({ „entity_type“: „standing_rule“ }) „

Meine Instanz gibt Regeln wie „Carlos immer in Bitcoin bezahlen“ und „Gestaltete Nachrichten in Markdown-Blöcken bereitstellen“ zurück. Der Agent wendet diese automatisch für den Rest der Sitzung an.

Wenn Workflows Dateien (Quittungen, Screenshots, Dokumente) berühren, speichert der Agent sie zusammen mit Entitäten im selben Aufruf unter Verwendung von „file_path“:

„json speichern({ „Entitäten“: [ { „entity_type“: „transaktion“, „Verkäufer“: „Amazon“, „Betrag“: 47,99, „Währung“: „EUR“ } ], „file_path“: „/path/to/receipt.pdf“, „idempotency_key“: „amazon-order-march-9“ }) „

Der [unstrukturierte Speicherpfad] von Neotoma (https://github.com/markmhendrickson/neotoma) verwaltet die Datei von dort aus. Die Rohbytes sind inhaltsadressiert (SHA-256), sodass dieselbe Datei nie zweimal gespeichert wird. Der Agent übergibt die Datei unverändert über „file_path“ (lokale Umgebungen wie Cursor) oder „file_content“ (base64, für webbasierte Umgebungen); Es interpretiert oder extrahiert Daten nicht vor dem Speichern. Standardmäßig führt Neotoma automatisch eine KI-Interpretation der gespeicherten Datei durch, extrahiert strukturierte Entitäten und verknüpft sie über eine EMBEDS-Beziehung wieder mit der Quelle. Das erneute Speichern derselben Datei mit „interpret: true“ löst eine Neuinterpretation aus, ohne dass ein Duplikat erstellt wird. Die Quittung wird zu abfragbaren strukturierten Daten, wobei das Original-PDF zur Herkunftssicherung erhalten bleibt. Die Interpretation kann auch für die Stapelverarbeitung oder Kontingentverwaltung verzögert werden („interpret: false“) und dann später mit einer anderen Konfiguration ausgeführt werden.

Arbeitsabläufe in der Praxis

Einige Workflows zeigen das Muster.

E-Mail-Triage. Der Agent liest ungelesene E-Mails über Gmail MCP, überprüft Neotoma auf vorhandene Kontaktdatensätze und den vorherigen Kontext mit jedem Absender, entwirft Antworten unter Verwendung meiner Kommunikationsstilregeln, speichert neue Kontakte und Aufgaben und archiviert verarbeitete Nachrichten. Ein einzelner Triage-Durchlauf kann fünf neue Kontakte, drei Aufgaben und ein Dutzend Gesprächsrunden speichern.

Blog-Beitrag schreiben. Die Fertigkeit selbst lebt in Neotoma als strukturierte Einheit. Der Agent ruft es mit „retrieve_entity_snapshot“ ab. Anschließend werden vorhandene Beiträge zur Stilkalibrierung abgefragt, der Entwurf geschrieben, die Beitragsentität mit allen Metadaten gespeichert, Heldenbilder generiert, eine Freigabekopie für Twitter und LinkedIn erstellt, der Website-Cache aus dem Neotoma-Export neu generiert und bereitgestellt. Dieser Beitrag wurde so geschrieben.

Bitcoin-Zahlungen. Ich bezahle einen Auftragnehmer in Bitcoin über einen BTC-Wallet-MCP-Server. Neotoma speichert die Dauerregel, den Kontaktdatensatz und den Transaktionsverlauf. Der Agent ruft alle drei ab, führt die Zahlung aus, speichert die neue Transaktion im On-Chain-Link und bestätigt.

Feedback-Verarbeitung. Wenn Tester Feedback zur Neotoma-Entwicklerversion geben, extrahieren Agenten strukturierte Feedback-Entitäten, verknüpfen sie mit dem Kontaktdatensatz des Testers, klassifizieren das Feedback nach Bucket und bewerten es anhand der Einschränkungen der Release-Phase. Vorheriges Feedback kann nach Tester, Bucket oder Datum abgerufen werden.

Website-Bereitstellung. Der Bereitstellungs-Skill synchronisiert lokale Markdown-Änderungen mit Neotoma, exportiert den vollständigen Website-Datensatz, generiert den Cache neu, pusht das Website-Repo und überwacht GitHub-Aktionen, bis der Build erfolgreich ist. Wenn der Build fehlschlägt, liest der Agent die Protokolle, behebt das Problem und führt ihn erneut aus.

Auf dem Weg zu Agenten, die ohne mich agieren

Jeder Arbeitsablauf beginnt damit, dass ich einen Cursor-Agenten öffne und eine Anweisung eingebe. Ich bin bei jeder Aufgabe auf dem Laufenden. Das ist für die aktuelle Phase in Ordnung, aber es ist nicht der Endzustand.

Ich richte automatisierte Prozesse ein, damit Agenten Arbeitsabläufe ohne mein direktes Eingreifen abwickeln können. Die Einzelteile sind bereits vorhanden: Fähigkeiten definieren die vollständigen Arbeitsschritte, Neotoma speichert den Kontext und die Regeln, MCP-Server sorgen für die Reichweite. Was fehlt, ist die Orchestrierung, die Arbeitsabläufe termingerecht oder als Reaktion auf Ereignisse auslöst, und eine einfache Genehmigungsschnittstelle, damit ich Aktionen überprüfen und autorisieren kann, ohne an meinem Laptop sitzen zu müssen.

Die [geschichtete Architektur] von Neotoma (https://github.com/markmhendrickson/neotoma/blob/dev/docs/foundation/layered_architecture.md) ist genau dafür konzipiert. Es trennt drei Anliegen:

1. Wahrheitsschicht (Neotoma). Ereignisbasiert, reduzierungsgesteuert, deterministisch. Alle Agenten lesen daraus. Statusaktualisierungen erfolgen nur über Domänenereignisse, die von Reduzierern verarbeitet werden. Kein Agent mutiert die Wahrheit direkt.
2. Strategieebene. Liest den aktuellen Weltzustand aus Neotoma. Bewertet Prioritäten, Einschränkungen, Risiken, Verpflichtungen und Zeit. Gibt Entscheidungen und Befehle aus. Reine Erkenntnis: Staat rein, Entscheidungen raus. Keine Nebenwirkungen.
3. Ausführungsebene. Nimmt Befehle von der Strategieebene entgegen. Führt Nebenwirkungen über externe Adapter aus (E-Mail-APIs, Zahlungsdienste, Kalender, Messaging). Gibt Domänenereignisse aus, die beschreiben, was passiert ist. Diese Ereignisse fließen über Reduzierer zurück, um den Status zu aktualisieren. Reiner Effekt: Befehle rein, Ereignisse raus.

Die Schleife ist geschlossen:

„ Eingehende Signale (E-Mail, WhatsApp, Kalender, Finanzdaten) -> Normalisierung -> Neotoma-Status (Ereignisprotokoll + Reduzierungen) -> Strategie-Tick (Prioritäten bewerten, Entscheidungen treffen) -> Ausführungsagenten (Nebeneffekte ausführen, Ereignisse ausgeben) -> Reduzierstücke -> Aktualisierter Stand -> Nächstes Häkchen „

Heute bin ich die Strategieebene. Ich schaue mir den Zustand an, entscheide, was zu tun ist, und weise einen Agenten an, die Aktion auszuführen. Die Architektur macht diese Rolle durch Software ersetzbar. Eine Strategie-Engine liest Neotoma, bewertet anhand bestehender Regeln und Prioritäten, was Aufmerksamkeit erfordert, und gibt Befehle an Ausführungsagenten. Diese Agenten rufen MCP-Server an, speichern die Ergebnisse und der Zyklus wiederholt sich.

Die entscheidende Invariante besteht darin, dass keine Ebene direkt in den zugrunde liegenden Datenspeicher von Neotoma schreibt. Aktualisierungen fließen nur über Domänenereignisse und -reduzierer. Das macht das System überprüfbar und reversibel. Wenn ein autonomer Agent eine schlechte Entscheidung trifft, kann ich das Ereignis zurückverfolgen, das sie verursacht hat, die Statusaktualisierung rückgängig machen und die Regel korrigieren, die dazu geführt hat.

Ziel ist es, meine tägliche Zeit am Computer zu reduzieren. Nicht beseitigen. Wechseln Sie von der praktischen Ausführung zur Überprüfung und Genehmigung. Ich möchte mit einer Zusammenfassung dessen aufwachen, was meine Agenten über Nacht erledigt haben: E-Mails sortiert, Beiträge verfasst, Bereitstellungen überprüft, Zahlungen in der Warteschlange. Ich möchte eine Bitcoin-Zahlung von meiner Apple Watch genehmigen. Ich möchte beim Gehen eine verfasste E-Mail auf meinem Telefon lesen und zum Senden antippen. Die Agenten kümmern sich um die 80 %, die wiederholbar sind. Ich kümmere mich um die 20 %, die einer Beurteilung bedürfen.

Hier wird die Hardware-Frage interessant. Heutige Telefone und Uhren sind nicht für dieses Interaktionsmuster ausgelegt. Sie benötigen ein Gerät, das für kurze Überprüfungs- und Genehmigungsgesten optimiert ist, nicht zum Tippen oder Surfen.

Von den Geräten, die es heute gibt, scheint die Apple Watch dem richtigen Formfaktor am nächsten zu kommen: immer am Handgelenk, immer im Blickfeld, mit der Möglichkeit, Interaktionen durch einfaches Tippen zu genehmigen. Aber die Softwareschicht ist noch nicht da. Es gibt keine Möglichkeit, Agentenzusammenfassungen und Genehmigungsanfragen nativ an die Überwachung weiterzuleiten.

Das könnte für mich irgendwann ein Bereich sein, in dem ich experimentieren und eine leichte Begleit-App entwickeln kann, die Neotomas Zustand mit einer Schnittstelle auf Handgelenkshöhe verbindet. Unabhängig davon, ob die richtige Oberfläche am Ende eine Uhren-App, ein dediziertes KI-Gerät oder etwas ist, das noch nicht existiert, ist das Interaktionsmodell klar: Agenten erledigen die Arbeit, das strukturierte Gedächtnis speichert den Zustand und der Mensch gibt die Richtung im Tempo der Absicht und nicht im Tempo der Ausführung vor.

Open-Sourcing des Stacks

Der Stapel ist heute privat, weil er mein Leben enthält: Kontakte, Finanzen, Gesundheitsdaten, persönliche Kommunikation, allgemeine Regeln darüber, wie ich meinen Haushalt führe. Bevor ich es als Open Source veröffentlichen kann, muss ich das alles entwirren.

Der Weg ist unkompliziert. Persönliche Daten werden vollständig in Neotoma übertragen, das für den Großteil davon bereits die Quelle der Wahrheit darstellt. Skripte, die auf meine spezifischen Konten und Pfade verweisen, werden so umgestaltet, dass sie aus der Konfiguration gelesen werden können. MCP-Server-Wrapper werden generisch. Fähigkeiten verlieren ihre fest verankerten Annahmen.

Was bleibt, ist ein wiederverwendbarer Agenten-Stack: eine Monorepo-Vorlage mit MCP-Server-Gerüst, ein Regel- und Kompetenz-Framework, Neotoma-Integration für strukturierten Speicher und Beispiel-Workflows, die jeder anpassen kann. Die Architektur ist der interessante Teil. Meine persönlichen Daten sind es nicht.

Ich habe hierfür keinen Zeitplan. Das Refactoring erfolgt parallel zur täglichen Nutzung. Jedes Mal, wenn ich ein Skript berühre, mache ich es allgemeiner. Jedes Mal, wenn ich Daten in Neotoma verschiebe, entferne ich sie aus dem Repo. Der Stack wird mit jeder Sitzung portabler.

Was das über Neotoma beweist

Ich habe diesen Stack gebaut, bevor es Neotoma gab. Die frühe Version verwendete Flatfiles und Parquet-Tabellen. Es funktionierte, bis es nicht mehr funktionierte.

Die Fehlermodi waren spezifisch: Ein Agent speicherte einen Kontakt in einer Sitzung als „Sarah Kim“ und in einer anderen als „S. Kim“ und erstellte Duplikate ohne Möglichkeit, sie zusammenzuführen. Es gab keine Herkunft, daher konnte ich nicht sagen, welcher Agent ein Feld wann geschrieben hat.

Die Abfragen waren auf exakte Übereinstimmungen in einzelnen Spalten beschränkt. Daher wurde gefragt: „Welches Feedback habe ich letzte Woche erhalten?“ bedeutete, jede Datei manuell zu scannen. Gelegentlich wurden Datensätze fehlerhaft überschrieben oder vollständig gelöscht, ohne dass ein Ereignisprotokoll wiederhergestellt werden konnte. Und nichts war typübergreifend verknüpft. Da ich wusste, dass eine Aufgabe im Zusammenhang mit einem Kontakt im Zusammenhang mit einer Transaktion erforderlich war, musste ich dieses Diagramm im Kopf behalten.

Neotoma ersetzte diese Schicht. Es gab Agenten ein strukturiertes, abfragbares, beziehungsbewusstes Gedächtnis, das in jedem Workflow funktioniert. Der Stack verfügt jetzt in Neotoma über 170 Entitätstypen, nicht weil ich im Voraus 170 Schemata entworfen habe, sondern weil Agenten Entitätstypen erstellen, wenn sie auf neue Arten von Informationen stoßen. Eine Feedback-Notiz unterscheidet sich von einer Transaktion und einer Dauerregel, und das System verarbeitet sie alle.

Das ist das Hundefutter, das Neotoma ehrlich hält. Wenn das Abrufen langsam ist, spüre ich es in jeder Agentensitzung. Wenn die Entitätsauflösung fehlschlägt, erhalte ich doppelte Kontakte. Wenn der Speicher unzuverlässig ist, werden Arbeitsabläufe unterbrochen. Jeder Fehler und jede Lücke taucht in meiner täglichen Arbeit auf, bevor sie bei irgendjemand anderem auftaucht.

Das Gedächtnisproblem ist universell. Jeder Entwickler, der Agenten-Workflows erstellt, stößt auf dieselbe Hürde: Agenten, die sich nicht erinnern können, keine Abfragen durchführen können und nicht auf früheren Arbeiten aufbauen können. Abruf allein reicht nicht aus; Struktur und Herkunft machen das Gedächtnis vertrauenswürdig. Dieser Stapel ist ein Beweis dafür, dass strukturiertes Gedächtnis die Möglichkeiten von Agenten verändert. Mit Neotoma mache ich das allen zugänglich.

Die Entwicklerversion ist zum Testen geöffnet. Wenn Sie Agenten-Workflows erstellen und darunter einen strukturierten Speicher benötigen, sollten Sie hier beginnen.