ontology

• Sie möchten, dass ein Agent strukturierte Informationen sitzungsübergreifend speichert (z. B. „Merke, dass Alice Projekt X gehört").
• Sie müssen verwandte Objekte verknüpfen und diese Verknüpfungen später traversieren (z. B. „Zeige alle Aufgaben für Projekt Z", „Was hängt von X ab?").
• Mehrere Skills müssen Zustand teilen, ohne rohen Text weiterzugeben – ein Skill schreibt ein Commitment, ein anderer liest es als Task.
• Sie planen mehrstufige Arbeit und möchten jeden Schritt als validierte Graphtransformation mit Rollback bei Constraint-Verletzung modellieren.

• Du nur kurzlebigen, einmaligen Kontext benötigst und keine Persistenz zwischen Agent-Läufen benötigst.
• Deine Daten rein unstrukturiert sind (Freitext) und keine bedeutsamen Entitätsbeziehungen modelliert werden müssen.
• Du eine produktionsreife Graph-Datenbank mit hoher Nebenläufigkeit benötigst — für große oder komplexe Graphen empfiehlt die SKILL.md selbst, zu SQLite zu migrieren.

Wird mit einem umfassenden Satz vordefinierter Typen geliefert, die Akteure (Person, Organization), Arbeit (Project, Task, Goal), Zeit und Ort (Event, Location), Informationen (Document, Message, Note) sowie Ressourcen (Account, Device, Credential) abdecken. Jeder Typ verfügt über typisierte Eigenschaften und optionale Felder, sodass Sie die reale Welt modellieren können, ohne Schemata von Grund auf neu erfinden zu müssen.

Jede Mutation wird vor der Übernahme gegen die in memory/ontology/schema.yaml definierten Regeln validiert. Zu den Einschränkungen gehören Pflichtfelder, Enum-Werte, verbotene Eigenschaften (z. B. das Blockieren von Rohgeheimnissen bei Credential), Typ- und Kardinalitätsregeln für Relationen, Azyklizitätsprüfungen sowie temporale Plausibilitätsprüfungen wie end >= start bei Event.

Der Graph wird als append-only-Datei memory/ontology/graph.jsonl gespeichert – jede Erstell-, Aktualisierungs- und Verknüpfungsoperation wird als neue Zeile hinzugefügt, wodurch die vollständige Historie erhalten bleibt. Bei komplexen Graphen empfiehlt die SKILL.md-Datei eine Migration zu SQLite, wobei dieselbe Schnittstelle beibehalten wird.

Ein scripts/ontology.py-CLI stellt Befehle für alle Kernoperationen bereit: create, query, get, related, relate, validate und schema-append. Dadurch ist es aus jedem Shell-Schritt oder Agenten-Aufruf heraus skriptfähig, ohne benutzerdefinierten Graph-Code schreiben zu müssen.

Skills können in ihrer eigenen SKILL.md einen ontology-Vertrag deklarieren, der angibt, welche Typen sie reads (liest) und writes (schreibt) sowie Vor- und Nachbedingungen definiert. Dadurch werden Datenabhängigkeiten zwischen Skills explizit und nachvollziehbar, und die ontology wird zu einem typisierten Message-Bus zwischen den einzelnen Fähigkeiten.

Mehrstufige Pläne können als geordnete Abfolgen von Graphoperationen modelliert werden (CREATE → RELATE → CREATE …). Jeder Schritt wird vor der Ausführung validiert, und der gesamte Plan kann bei einer Einschränkungsverletzung zurückgerollt werden, wodurch Agenten eine strukturierte, inspizierbare Planungsebene erhalten.

Ein Agent erstellt beim ersten Erwähnen Person- und Project-Entitäten und verknüpft sie anschließend mit has_owner- oder has_member-Relationen. Bei späteren Gesprächsrunden durchsucht die Abfrage „Was weiß ich über Alice?" den Graphen, um alle zugehörigen Projekte, Aufgaben und Ereignisse anzuzeigen – ohne dabei auf den Gesprächsverlauf angewiesen zu sein.

Eine E-Mail-Lese-Skill extrahiert eine Zusage aus einer Nachricht und schreibt eine Commitment-Entität in die ontology. Eine separate Aufgabenverwaltungs-Skill fragt regelmäßig ausstehende Commitment-Objekte ab und erstellt automatisch verknüpfte Task-Entitäten – ohne direkte Kopplung zwischen den beiden Skills.

Ein Planungsagent modelliert ein Projekt als eine Menge von Task-Entitäten mit blocks-Relationen. Die Zyklusfreiheitsbedingung verhindert, dass zirkuläre Abhängigkeiten übernommen werden, und eine related-Abfrage zeigt sofort an, was abgeschlossen sein muss, bevor eine bestimmte Aufgabe beginnen kann.

Bevor ein komplexer Workflow ausgeführt wird (z. B. „Teammeeting planen und Folgeaufgaben zuweisen"), wandelt der Agent jeden Schritt in eine validierte Graph-Operation um. Wenn ein Schritt gegen eine Einschränkung verstößt, wird die gesamte Sequenz zurückgerollt, wodurch ein sicherer und überprüfbarer Ausführungspfad über das Action-Typ-Protokoll bereitgestellt wird.