// erkundung · mcp-knowledge · in Arbeit
Wo sollte das Gedächtnis eines Agenten liegen, damit man ihm vertrauen kann?
Was ich gerade baue: ein Wissenskern für KI-Agenten — Dokumente, Gedächtnis und strukturierte Records, worker-zu-worker über ein Service-Binding erreichbar statt über eine öffentliche API. Die Architektur trägt; den Rest arbeite ich noch aus.
Das Problem
Agenten brauchen einen dauerhaften Ort zum Lesen und Schreiben — Notizen, Dokumente, Listen, Records. Aber einem Agenten eine Datenbank zu geben heißt, einen Datenspeicher zu exponieren, und das ins Internet zu exponieren heißt: eine weitere öffentliche Fläche, mehr Keys, die leaken können, und keine für Menschen sinnvolle Struktur.
Die naheliegende Antwort — und warum sie zu kurz greift
Dem Agenten eine gehostete Datenbank oder eine öffentliche API hinter einem API-Key geben. Man gewinnt Reichweite — und Key-Wildwuchs, eine neue Angriffsfläche und einen Blob-Speicher ohne Form, über die ein Mensch nachdenken oder die er freigeben könnte.
Der Ansatz
Ein eigener Knowledge-Worker, nur worker-zu-worker über ein Service-Binding erreichbar — nie im öffentlichen Internet. Er hält Dokumente, Gedächtnis und einen generischen Records-Wrapper (Listen, Todos, Freiform) mit itemgenauem Zugriff per ID. Zusammen mit mcp-approval kann jede Schreib- oder Löschaktion von einem Menschen gegatet werden.
Entscheidungen & Abwägungen
- Service-Binding statt öffentlicher API. Der Core ist vom Internet aus nicht erreichbar — Defense in Depth, kein Key, der leaken kann.
- Generische Records statt starrer Schemas. Ein Listen-/Todo-/Freiform-Wrapper mit JSON-Bodies, adressierbar pro Item — flexibel, ohne für jede neue Form eine Migration zu brauchen.
- Hybridsuche ohne zweiten Index. Volltext- und semantische Suche laufen nebeneinander über denselben Speicher. Die Embeddings liegen neben den Daten statt in einer separaten Vektordatenbank — eine Quelle der Wahrheit, ein Backup.
Gebaut mit
Cloudflare Workers · D1 · R2 · Workers AI · service bindings · MCP (Model Context Protocol) · TypeScript
Status & Fahrplan
Wo es steht: in Arbeit. Architektur, Records-Wrapper und Hybridsuche sind gebaut und getestet; es steht bereits über Service-Binding hinter anderen Tools.
Als Nächstes: eine dokumentierte öffentliche Fläche für das Records-Modell — erst, wenn sie den gleichen Produktionsstandard wie mcp-approval erfüllt.