Acontext: Agenten-Gedächtnis als lesbare Skill-Dateien
Agent Skills as a Memory Layer
Auf einen Blick
- Was ist das?
- Acontext speichert das, was ein Agent aus einem Lauf gelernt hat, nicht in einer undurchsichtigen Vektordatenbank, sondern in Markdown-Dateien, die ein Skill-Agent nach einem festen Schema fortschreibt. Das ist nachprüfbar, aber es bindet das Gedächtnis an das Skill-Format.
- Für wen ist es gedacht?
- Wer einen Agenten betreibt, dessen Wissen Nutzer einsehen und korrigieren sollen, findet in Acontext einen Ansatz, der genau das erzwingt. Wer semantische Suche über große, unstrukturierte Korpora braucht, ist hier falsch, weil die Rückgewinnung über Tool-Aufrufe und Reasoning läuft.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 63 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Acontext adressiert
Die meisten Gedächtnisschichten für Agenten speichern Wissen als Vektoren. Was dort liegt, lässt sich schlecht lesen, schlecht debuggen und von Nutzern kaum korrigieren. Acontext dreht das um: Laut README ist das Ziel, jede Information, die ein Agent braucht, als einfache Datei darzustellen. Die Grundthese lautet, dass ein Memory genauso als Agent-Skill-Datei formulierbar ist, wenn Skills bereits Wissen repräsentieren. Adressat sind Entwickler, die einen Agenten über mehrere Läufe hinweg verbessern wollen, ohne dass ein undurchsichtiges Memory das Kontextfenster verschmutzt. Das Versprechen ist konkret: Der Agent soll aus Fehlern lernen und wiederholen, was funktioniert hat.
Der Ablauf: von der Sitzung zur Skill-Datei
Das README zeigt den Speicherpfad als Kette: Sitzungsnachrichten fließen in eine Aufgabe, die als erledigt oder fehlgeschlagen markiert wird, daraus entsteht eine Destillation, dann greift ein Skill Agent, und am Ende werden Skills aktualisiert. Die Sitzungsnachrichten sind der Rohinput, optional mit Tool-Aufrufen und Artefakten. Aufgaben werden automatisch aus dem Nachrichtenstrom extrahiert oder aus einer expliziten Ergebnis-Meldung abgeleitet. Der Auslöser für das Lernen ist das Ende einer Aufgabe, nicht ein Zeitintervall. In der Destillation liest ein LLM den Verlauf und die Ausführungsspur und leitet ab, was funktioniert hat, was fehlschlug und welche Präferenzen der Nutzer zeigt. Der Skill Agent entscheidet anschließend, ob ein vorhandener Skill fortgeschrieben oder ein neuer angelegt wird, und schreibt nach dem Schema, das in SKILL.md definiert ist. Die Struktur geben also nicht die Modelle vor, sondern die Nutzer.
Rückgewinnung ohne Vektorsuche
Beim nächsten Lauf bekommt der Agent Skill Content Tools, im Material genannt sind get_skill und get_skill_file. Er entscheidet selbst, was er braucht, ruft das Tool auf und erhält den Inhalt. Das README nennt das progressive disclosure, der Agent bleibt in the loop. Der Kontrast zu semantischer Suche ist deutlich: Es gibt kein top-k über Embeddings, sondern einen Werkzeugaufruf, der auf Reasoning beruht. Das ist ein bewusster Verzicht. Ein Agent, der nicht zuverlässig Tools aufruft, findet auf diesem Weg gar nichts, während eine Vektorsuche zumindest irgendetwas zurückliefert. Die Selbsthosting-Anleitung weist ausdrücklich darauf hin, dass das verwendete LLM Tool-Aufrufe beherrschen muss und standardmäßig gpt-4.1 nutzt.
Installation und Selbsthosting
Der Cloud-Weg beginnt mit einem Konto auf acontext.io, kostenlosen Credits und einem API-Key mit dem Präfix sk-ac. Für einen Proof-of-Concept gibt es die CLI, installiert über curl -fsSL https://install.acontext.io | sh. Danach legt man ein Verzeichnis an, wechselt hinein und startet acontext server up. Voraussetzung sind Docker und ein OpenAI API Key. Der Befehl erzeugt oder verwendet .env und config.yaml und legt einen db-Ordner zur Persistenz an. Danach sind die API unter http://localhost:8029/api/v1 und ein Dashboard unter http://localhost:3000/ erreichbar. Die SDKs liegen als pip-Paket acontext und als npm-Paket @acontext/acontext vor. Die jüngsten Releases im Material betreffen ui, sdk-ts und package-claude-code, jeweils mit eigenen Versionsnummern.
Grenzen und wann das Werkzeug nicht passt
Die Datei-Philosophie hat einen Preis. Es gibt keine Suche, die den Agenten von der Entscheidung entlastet, was relevant ist. Wer einen wachsenden Korpus aus Dokumenten, Tickets oder Chats durchsuchbar machen will, bekommt hier keinen Ersatz für eine Retrieval-Pipeline. Ein zweiter Punkt betrifft die Qualität der Destillation: Das Material beschreibt sie als LLM-Pass, der aus einem Gespräch ableitet, was funktioniert hat. Wie gut das gelingt, hängt am Modell und an der Klarheit des Verlaufs, und das README nennt keine Genauigkeit. Auch die Struktur ist Arbeit. Wer kein SKILL.md mit Schema, Benennung und Dateilayout vorgibt, überlässt die Organisation dem Skill Agent. Das Material sagt nichts über Nebenläufigkeit, also darüber, wie sich zwei gleichzeitige Läufe auf dieselbe Datei auswirken. Auch zu Rollback oder Versionierung der Skill-Dateien findet sich kein Hinweis, obwohl Git im README als Werkzeug genannt wird.
Was Acontext von Vektor-Memory unterscheidet
Der naheliegende Vergleich ist eine Vektor-Memory-Schicht, wie sie viele Agent-Frameworks mitbringen: Nachrichten werden eingebettet, in einen Index geschrieben und bei Bedarf über Ähnlichkeit abgerufen. Der Unterschied liegt nicht im Speichermedium, sondern im Abrufpfad. Acontext ersetzt den Ähnlichkeitsabruf durch Tool-Aufrufe und ersetzt den Index durch ein Dateisystem. Das macht das Gedächtnis prüfbar: Man kann die Markdown-Dateien lesen, mit grep durchsuchen und in ein Repository legen. Es macht das Gedächtnis aber auch vom Verhalten des Agenten abhängig. Das README fasst das in dem Satz, Skill sei Memory und Memory sei Skill. Wer diesen Tausch bewusst will, gewinnt Nachvollziehbarkeit; wer ihn nicht will, verliert einen Abrufmechanismus, der ohne Zutun des Modells funktioniert.
Betrieb, Updates und Lizenz
Das Repository steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien als solche gekennzeichnet werden. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Bedingungen vor einem Fork oder einer Weitergabe zu prüfen sind. Für den Betrieb relevant ist die Aufteilung in getrennte Versionslinien: ui, sdk-ts und package-claude-code werden einzeln veröffentlicht, sodass ein Upgrade der UI nicht zwingend eines des SDK bedeutet. Bei Selbsthosting sind .env und config.yaml die Stellschrauben, dazu ein db-Ordner, den man sichern muss. Das Material nennt keine Migrationshinweise zwischen Versionen und keine Angaben zum Datenformat dieser Datenbank, was ein Upgrade zu einem Vorgang macht, den man vorher in einer Kopie des db-Ordners testen sollte.
Redaktionelles Fazit
Wer einen Agenten betreibt, dessen Wissen Nutzer einsehen und korrigieren sollen, findet in Acontext einen Ansatz, der genau das erzwingt. Wer semantische Suche über große, unstrukturierte Korpora braucht, ist hier falsch, weil die Rückgewinnung über Tool-Aufrufe und Reasoning läuft. Vor dem Einsatz zu klären: ob das eigene Modell zuverlässig Tools aufruft, wie die Dateien bei parallelen Läufen kollidieren und was die Lizenz Apache-2.0 für den gehosteten Dienst bedeutet.
Community-Notizen