# AGENTS Source: https://docs.wazoo.dev/AGENTS # AGENTS.md ## What this repo is This is the official documentation hub for the Wazoo project ecosystem, built with Mintlify. Content is written in MDX with YAML frontmatter. Site configuration lives in `docs.json`. ## Commands | Command | Purpose | | --------------------------- | ----------------------- | | `npm run dev` | Start local preview | | `npm run check` | Validate docs build | | `npm run format` | Format all MD/MDX/JSON | | `npm run precommit` | Format check + validate | | `npx mintlify broken-links` | Check internal links | Run `npm run precommit` before finalizing any commit. ## Style guidelines These are the non-negotiable rules. See `/contribute/style` for the full guide. ### Voice * Second-person active voice ("you") * Zero marketing adjectives ("powerful", "seamless", "robust") * No filler phrases ("it's important to note", "in order to") * No editorializing ("obviously", "simply", "just", "easily") * No excessive conjunctions ("moreover", "furthermore", "additionally") * No generic introductions or concluding summaries ### Headings and formatting * Sentence case for headings ("Getting started", not "Getting Started") * Sentence case for code block titles * No bold or italics in body text * No decorative emoji * All code blocks must have explicit language tags * All images must have descriptive alt text ### Code examples * Use realistic values (avoid "foo" or "bar") * Relational facts should use canonical examples like `user:person` and `wazoo:organization` * Verify code works before including it ### Files and navigation * Use kebab-case for new files (`getting-started.mdx`) * Internal links use root-relative paths without file extensions (`/projects/worlds`) * New pages must be added to `docs.json` navigation * Every MDX file must have `title` and `description` in YAML frontmatter ### Terminology * **Worlds API / Platform**: product and interface names * **world / worlds** (lowercase): specific knowledge graph instances * **engine / context engine**: functional descriptions * **verified facts**: technical descriptions of graph state * **memory**: conceptual analogy, permitted for developer intuition # Get health Source: https://docs.wazoo.dev/api-reference/health/get-health https://api.wazoo.dev/openapi.json get /health # Create platform token Source: https://docs.wazoo.dev/api-reference/platformtokens/create-platform-token https://api.wazoo.dev/openapi.json post /v1/auth/api-tokens # List platform tokens Source: https://docs.wazoo.dev/api-reference/platformtokens/list-platform-tokens https://api.wazoo.dev/openapi.json get /v1/auth/api-tokens # Validate platform token Source: https://docs.wazoo.dev/api-reference/platformtokens/validate-platform-token https://api.wazoo.dev/openapi.json get /v1/auth/api-tokens/validate # Get authenticated user Source: https://docs.wazoo.dev/api-reference/users/get-authenticated-user https://api.wazoo.dev/openapi.json get /v1/users/me # Create world Source: https://docs.wazoo.dev/api-reference/worlds/create-world https://api.wazoo.dev/openapi.json post /v1/worlds # Delete world Source: https://docs.wazoo.dev/api-reference/worlds/delete-world https://api.wazoo.dev/openapi.json delete /v1/worlds/{worldId} # Get world Source: https://docs.wazoo.dev/api-reference/worlds/get-world https://api.wazoo.dev/openapi.json get /v1/worlds/{worldId} # List worlds Source: https://docs.wazoo.dev/api-reference/worlds/list-worlds https://api.wazoo.dev/openapi.json get /v1/worlds # Undelete world Source: https://docs.wazoo.dev/api-reference/worlds/undelete-world https://api.wazoo.dev/openapi.json post /v1/worlds/{worldId}/undelete # Update world Source: https://docs.wazoo.dev/api-reference/worlds/update-world https://api.wazoo.dev/openapi.json patch /v1/worlds/{worldId} # Create world token Source: https://docs.wazoo.dev/api-reference/worldtokens/create-world-token https://api.wazoo.dev/openapi.json post /v1/worlds/{worldId}/auth/tokens # List world tokens Source: https://docs.wazoo.dev/api-reference/worldtokens/list-world-tokens https://api.wazoo.dev/openapi.json get /v1/worlds/{worldId}/auth/tokens # CocoIndex Source: https://docs.wazoo.dev/comparisons/cocoindex Worlds vs CocoIndex: RDF fact ledger vs incremental vector sidecar indexing. ## At a glance | | Worlds | [CocoIndex](https://github.com/cocoindex-io/cocoindex) | | :--------------- | :---------------------------------------------------- | :----------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Incremental ETL indexer & vector memory sidecar | | Data model | RDF triples in an append-only graph ledger | Relational vector chunks (pgvector / PGlite) | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Vector similarity & chunk retrieval | | Incremental flow | Immutable append-only quads & patches | Memoized pipeline functions (`@coco.fn(memo=True)`) | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Python runtime + Postgres (Docker or PGlite) | ## Overlap and shared capabilities Both Worlds and [CocoIndex](https://github.com/cocoindex-io/cocoindex) address the need for structured, indexable context over Markdown documents. Both systems parse section headings, chunk content for search, and maintain fast retrieval pipelines so AI agents spend fewer tokens retrieving relevant context. The difference is in which layer of the stack they manage: * CocoIndex is an incremental ETL sidecar pipeline. It continuously watches source files and updates derived pgvector or WASM PGlite vector indexes. * Worlds is an authoritative RDF fact engine. It manages canonical triple assertions, SHACL shapes, SPARQL graph filters, and immutable provenance. Rather than competing, the two systems serve complementary steps in the context pipeline: CocoIndex handles background incremental indexing, while Worlds provides the authoritative SPARQL-driven [knowledge ledger](/worlds/index). ## When Worlds fits * You need deterministic graph querying (SPARQL) to verify multi-hop relationships across enterprise domain facts. * You require immutable provenance and audit trails for every assertion. * You want open-standard RDF schemas that operate natively across edge adapters (LibSQL) and cloud databases. ## When CocoIndex fits * You want an incremental background pipeline that updates vector embeddings as Markdown files change. * You need zero-Docker local vector sidecars via WASM PGlite. * You are transforming raw document corpora into derived chunk indexes for LLM RAG pipelines. ## Coexistence and integration CocoIndex and Wazoo tooling work together out of the box. You can use CocoIndex directly alongside the [Wiki toolchain](/projects/wiki), as demonstrated in the official [`wiki-cocoindex-template`](https://github.com/wazootech/wiki-templates/tree/main/cocoindex), where Wiki CLI manages markdown source checking and CocoIndex builds derived sidecar vector indexes. As projects and team memory scale, we recommend integrating [Worlds](/projects/worlds) as the central context engine, letting CocoIndex handle background incremental vector indexing while Worlds serves authoritative, SPARQL-driven graph retrieval. # DIY memory infra Source: https://docs.wazoo.dev/comparisons/diy-memory-infra Worlds vs assembling your own memory stack: Postgres plus vector indexes, triple stores, and custom pipelines. ## At a glance | | Worlds | DIY memory stack | | :---------------- | :--------------------------------------- | :------------------------------------------------------ | | Graph model | RDF triples | Custom schema or relational tables | | Retrieval | Hybrid search + pattern queries (SPARQL) | Custom vector + SQL index queries | | Provenance | Fact-level ledger | Custom versioning & logging tables | | Ingestion | Import API | Custom ETL pipeline & queues | | Pieces to operate | One engine | Postgres, pgvector, queue worker, ETL script, audit log | ## The maintenance cost of a DIY memory stack A DIY memory stack starts with familiar pieces: [PostgreSQL](https://www.postgresql.org), [pgvector](https://github.com/pgvector/pgvector), an ingestion queue, an embedding service, and a schema you design. Each piece is standard. The cost lives in keeping them coherent. The work that actually adds up: * Vector embeddings, full-text indexes, and relational tables all have to stay consistent under concurrent writes. When they drift, agents search against stale context. * Hybrid retrieval means fusing vector similarity with graph relationships yourself. That means writing and tuning a fusion algorithm, usually something like Reciprocal Rank Fusion. * Agents need exact provenance for every fact. A multi-tenant, fact-level audit log on top of a relational schema is substantial plumbing. * A schema that starts simple grows into a multi-service pipeline, and someone has to operate it. Worlds handles these cases directly. Facts are RDF quads in an append-only ledger with provenance built in, and retrieval combines vector similarity, keyword search, and pattern matching (SPARQL) in a single engine. ## When Worlds fits * Facts, relationships, and provenance are core requirements. * You want hybrid retrieval and graph queries working before you have a team to build them. * You need a smaller operational surface than a five-service stack. ## When Worlds does not fit * You already have a database estate with a schema you are happy with. * You need retrieval logic that a general engine cannot express. * You want to own every layer and have the operational budget for it. ## Coexistence The `@worlds/postgres` and `worlds-libsql` [adapters](/contribute/self-host) let a world run inside the database you already operate. Your data stays where it is, and Worlds becomes the context engine that makes it queryable by agents. # DIY triplestore Source: https://docs.wazoo.dev/comparisons/diy-triplestore Worlds vs running your own RDF store: the cost of operations. ## At a glance | | Worlds | DIY triplestore | | :--------- | :----------------- | :----------------------- | | Data model | RDF triples | RDF triples | | Query | SPARQL | SPARQL | | Ingestion | Import API | Your pipeline | | Hosting | Managed data plane | You operate it | | Security | Scoped tokens | Your IAM | | Search | Hybrid built in | Vector index is your job | ## The philosophical difference A triplestore such as [Jena Fuseki](https://jena.apache.org/documentation/fuseki2/) or [GraphDB](https://graphdb.ontotext.com/) gives you RDF and SPARQL, the same standards Worlds builds on. If you run one yourself, you get the graph and every operational problem that comes with it: provisioning, backups, security, scaling, rate limits, and observability. Worlds is a managed context engine. The data plane serves import, export, hybrid search, and SPARQL behind scoped tokens, and embedded adapters give you the same graph locally for development and edge deployment. ## When Worlds fits * You want the RDF model without running graph infrastructure. * Agents need [hybrid search](/worlds/search), not just SPARQL, out of the box. * You want a hosted multi-tenant data plane with token scoping. ## When Worlds does not fit * You need deep control over a specific triplestore's internals or extensions. * You are already running graph infrastructure with mature backup and security practices. * Your graph is large enough that a dedicated cluster is justified. ## Coexistence Worlds uses standard RDF serialization. You can export a world to N-Triples and load it into your own triplestore, and you can import data out of an existing store into a world. The formats interoperate even when the hosting does not. # Document Databases Source: https://docs.wazoo.dev/comparisons/document-databases Worlds vs Document Databases: RDF fact ledger vs JSON document stores. ## At a glance | | Worlds | Document Databases ([MongoDB](https://www.mongodb.com/docs/), [CouchDB](https://docs.couchdb.org/), [DynamoDB](https://docs.aws.amazon.com/dynamodb/)) | | :------------ | :---------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Hierarchical JSON document storage & retrieval | | Data model | RDF triples/quads in an append-only graph ledger | Semi-structured JSON/BSON documents | | Relationships | Explicit first-class graph edges with SPARQL queries | Embedded subdocuments or manual document references | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Field queries, aggregation pipelines, & key lookups | | Provenance | Immutable quad provenance & assertion ledger | Document revision histories or custom fields | ## Overlap and shared capabilities Both Worlds and document databases offer schema flexibility, allowing data structures to evolve without strict table migrations. Both support storing semi-structured metadata alongside content. The difference: * Document databases nest data hierarchically within document boundaries. Cross-document relationships require manual references or expensive lookup joins. * Worlds connects atomic facts into a unified RDF graph. Subject-predicate-object triples allow agents to query relationships across entity boundaries effortlessly. ## When Worlds fits * You need interconnected knowledge retrieval across multiple domain entities. * You require SPARQL graph queries and quad provenance tracking for verifiable agent responses. * You want hybrid search across RDF graphs, full-text indexes, and vector embeddings. ## When Document Databases fit * Your application data is naturally hierarchical and self-contained (e.g. user profiles, blog posts). * You require rapid single-key JSON document retrieval. * You are building general document storage workflows. # GBrain Source: https://docs.wazoo.dev/comparisons/gbrain Worlds vs GBrain: RDF fact ledger vs personal AI memory store. ## At a glance | | Worlds | [GBrain](https://github.com/garrytan/gbrain) | | :------------ | :---------------------------------------------------- | :---------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Personal AI memory & context repository | | Data model | RDF triples in an append-only graph ledger | Key-value / document memory notes & embeddings | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Semantic vector search & key lookup | | Target domain | Multi-agent context, enterprise domain graphs | Personal context, developer notes, & user preferences | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Self-hosted / local runtime | ## Overlap and shared capabilities Both Worlds and [GBrain](https://github.com/garrytan/gbrain) provide persistent memory for AI workflows, preventing LLMs from losing context across sessions. Both systems enable developers and agents to store facts, preferences, and notes outside the prompt window. The difference is structural: * GBrain is designed as a streamlined personal memory vault, optimized for storing personal notes, quick context, and key-value memory blocks. * Worlds is a W3C open-standard RDF context engine. It provides quad-level provenance, SHACL constraint validation, and deterministic SPARQL graph queries alongside vector search. GBrain offers lightweight personal memory storage, while Worlds provides enterprise-grade, verifiable graph context for multi-agent systems. ## When Worlds fits * You need deterministic graph querying (SPARQL) to verify multi-hop relationships across domain facts. * You require immutable provenance and audit trails for every assertion. * You want open-standard RDF schemas that operate natively across edge adapters (LibSQL, Postgres) and cloud databases. ## When GBrain fits * You need a simple personal context vault for developer notes and user preferences. * You want quick key-value memory retrieval without setting up RDF schemas or SPARQL queries. * You are prototyping single-user agent memory workflows. # Google Dataplex Source: https://docs.wazoo.dev/comparisons/google-dataplex Worlds vs Google Dataplex: RDF fact ledger vs enterprise data fabric & governance. ## At a glance | | Worlds | [Google Dataplex](https://cloud.google.com/dataplex) | | :------------ | :---------------------------------------------------- | :-------------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Enterprise data fabric, governance, & metadata management | | Data model | RDF triples/quads in an append-only graph ledger | Distributed data lakes, BigQuery tables, & asset catalog | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Data catalog search, SQL queries, & policy controls | | Core strength | Deterministic multi-hop SPARQL graph verification | Cross-cloud data governance, quality, & lineage metadata | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Google Cloud Platform (GCP) | ## Overlap and shared capabilities Both Worlds and [Google Dataplex](https://cloud.google.com/dataplex) provide structure, lineage tracking, and governance over enterprise data assets so applications and AI models can consume reliable information. The difference is structural and operational: * Google Dataplex is an enterprise data fabric platform within GCP. It unifies metadata management, data quality checks, security policies, and cataloging across distributed BigQuery datasets and GCS data lakes. * Worlds is an RDF knowledge graph context engine. It manages persistent triple assertions, subject-predicate-object graphs, and SPARQL queries with immutable quad provenance for AI agents. Dataplex manages enterprise data lakes and governance policies across Google Cloud, while Worlds provides a queryable, verifiable RDF fact ledger for software agents. ## When Worlds fits * You need deterministic graph querying (SPARQL) to verify multi-hop relationships across domain facts. * You require immutable provenance and quad-level assertion tracking for AI agent context. * You want open-standard RDF schemas that operate natively across edge adapters (LibSQL, Postgres) and cloud infrastructure. ## When Google Dataplex fits * You manage enterprise data lakes and BigQuery warehouses requiring centralized governance, data quality monitoring, and access controls on GCP. * You need automated data discovery, classification, and business glossary cataloging across Google Cloud assets. * Your primary data infrastructure relies on GCP analytical storage rather than RDF graph stores. ## Coexistence and integration Google Dataplex and Worlds operate at different levels of the enterprise data architecture. Dataplex governs large-scale GCP data lakes and relational analytical tables, while Worlds acts as the context engine and RDF fact ledger for AI agent fleets. # Google OKF (Open Knowledge Format) Source: https://docs.wazoo.dev/comparisons/google-okf Worlds vs Google OKF: RDF fact ledger vs open knowledge representation format. ## At a glance | | Worlds | Google OKF (Open Knowledge Format) | | :------------ | :---------------------------------------------------- | :---------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Open specification & format for structured knowledge | | Data model | RDF triples/quads in an append-only graph ledger | Entity-attribute-value & schema-neutral graph payload | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Schema parsing, serialization, & exchange format | | Core strength | Deterministic multi-hop SPARQL graph verification | Standardized schema payload interchange & format | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Specification / interchange format | ## Overlap and shared capabilities Both Worlds and Google OKF (Open Knowledge Format) aim to break structured knowledge out of proprietary silos into open, interoperable formats that AI models and software systems can parse deterministically. The difference is structural and functional: * Google OKF is an open knowledge specification and data format designed to standardize structured entity payload interchange. * Worlds is a complete context engine and runtime platform. It stores assertions in W3C RDF quads, enforces SHACL constraints, and executes multi-hop SPARQL queries fused with vector similarity search. OKF defines a standardized payload layout for structured entity exchange, whereas Worlds is a context storage engine and SPARQL query platform. ## When Worlds fits * You need an active context engine and SPARQL query server to store, index, and query dynamic facts. * You require append-only quad ledgers with built-in provenance tracking and hybrid search. * You want edge-deployable database adapters (LibSQL, Turso, Postgres) for live agent fleets. ## When Google OKF fits * You need a schema-neutral serialization format for transmitting knowledge graph payloads between enterprise systems. * You are defining open knowledge exchange specifications across external APIs. * You are standardizing entity-attribute payload exports. ## Coexistence and integration Google OKF payload schemas can be parsed and mapped directly into Worlds as RDF quads. Worlds serves as the queryable execution context and SPARQL engine for knowledge structured in open formats like OKF. # Google Search & Knowledge Graph Source: https://docs.wazoo.dev/comparisons/google-search Worlds vs Google Search: self-hostable private agent context vs public web search. ## At a glance | | Worlds | [Google Search](https://developers.google.com/custom-search) & [Knowledge Graph](https://developers.google.com/knowledge-graph) | | :--------------- | :---------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------ | | Deployment | Self-hostable, edge-embeddable (LibSQL), or Cloud | Proprietary Google cloud infrastructure | | Scope | Private domain facts, agent memory, & codebase graphs | Public web pages & global web-scale entities | | Data model | W3C RDF 1.1 quads, JSON-LD, & Linked Markdown | Google Knowledge Graph (Schema.org / Wikidata) | | Primary consumer | Autonomous AI agents, LLM tool calls, & developers | Human web searchers, Gemini Assistant, & Google APIs | | Query surface | SPARQL graph queries, full-text, & vector fusion | Web search box, Knowledge Panels, & Custom Search API | | Provenance | Fact-level chronological ledger & exact source quads | Indexed web URL references | ## Overlap and shared capabilities Both [Google Search](https://developers.google.com/custom-search) and Worlds are built on the same premise: structured knowledge graphs answer queries better than keyword strings alone ("things, not strings"). * Google Knowledge Graph (launched in 2012) added entity search to the public web by mapping entities, attributes, and real-world relationships with Schema.org and RDF standards. * Worlds applies the same RDF graph model to agent memory, so agents can query connected entities with SPARQL instead of relying on flat vector embeddings. The two differ in privacy, self-hostability, and domain scope: * Google Search indexes the public web for general human information retrieval on proprietary cloud infrastructure. * Worlds is self-hostable and open-source. It manages private enterprise facts, local codebases, and agent context graphs on edge databases (LibSQL/SQLite), local servers, or private clouds. ## When Worlds fits * You need to self-host your context engine for data privacy, compliance, and air-gapped security. * You are building AI agents that query private enterprise domain facts, codebase structures, or local user state. * You require deterministic [graph queries](/worlds/query) (SPARQL) to verify multi-hop relationships between internal entities. * You want edge-embeddable context stores (`worlds-libsql`) running directly inside your local application runtime. ## When Google Search fits * You need real-time, global information retrieval across the public internet (current events, web pages, external documentation). * Your application requires broad web-scale entity resolution across world facts. ## Coexistence and integration Google Search and Worlds are complementary tools in an AI agent's toolkit: * Agents use web search tools (Google Search API, Serper, Tavily, Exa) to retrieve live, external information from the open web. * Agents query Worlds for self-hosted, private domain facts, internal project context, and verifiable memory. # Hermes Agent Memory Source: https://docs.wazoo.dev/comparisons/hermes Worlds vs Hermes Agent Memory by Nous Research: multi-tiered LLM memory vs developer-native RDF graph context. ## At a glance | | Worlds | [Hermes Agent](https://github.com/NousResearch/Hermes-Agent) (Nous Research) | | :----------- | :----------------------------------------------- | :--------------------------------------------------------------------------------------- | | Data model | RDF triples in an append-only fact ledger | Four-tier memory (Markdown files, SQLite FTS5, Procedural Skills) | | Memory tiers | Curated RDF knowledge graph | Prompt memory (`MEMORY.md`), Session archive (`state.db`), Procedural skills (`skills/`) | | Retrieval | Hybrid: vector, full-text, RDF filters | FTS5 full-text search (`session_search`) & system prompt injection | | Provenance | Fact-level, chronological, verifiable via SPARQL | Session/file-level tracking | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Local CLI framework / agent runtime | ## The philosophical difference The [Hermes Agent](https://github.com/NousResearch/Hermes-Agent) architecture (developed by Nous Research) organizes agent memory into a pragmatic four-layer stack: 1. Prompt Memory: a static snapshot of `MEMORY.md` and `USER.md` injected into system prompts. 2. Session Archive: historical interaction logs indexed via SQLite FTS5 (`state.db`) for episodic keyword recall. 3. Procedural Memory: extracted task procedures saved as executable markdown skills. 4. Pluggable Memory Providers: hooks to external memory stores (e.g. Mem0, Supermemory). Hermes optimizes for agent self-curation and episodic session history within a local agent CLI runtime. Worlds approaches context from an open-standard, graph-first stance. Rather than relying on flat markdown files or SQLite FTS search alone, Worlds enforces RDF triples where every fact has explicit relationships, temporal validity, and deterministic SPARQL queryability. Where Hermes is an agent runtime managing its own prompt files and SQLite session database, Worlds is a dedicated context engine that Hermes agents (or any other agent runtime) can query as a verifiable memory provider. ## When Worlds fits * You need deterministic [graph querying](/worlds/query) (SPARQL) to traverse relationships across complex domain facts. * You require fact-level chronological provenance and auditability across all asserted data. * You want an open, standards-based RDF memory layer shared across multiple agent runtimes (Claude Code, Letta, Hermes). * Your application demands strict compliance, safety, and deterministic filtering where keyword or similarity search alone is insufficient. ## When Worlds does not fit * You want an all-in-one local agent CLI framework that manages prompt context files (`MEMORY.md`) and session history out of the box. * You prefer simple FTS5 text search over episodic agent conversations without establishing a formal knowledge graph vocabulary. ## Coexistence Hermes agents support pluggable memory provider plugins. Hermes can use its internal `MEMORY.md` for local prompt conventions while connecting Worlds as an external memory provider tool to query authoritative RDF facts via SPARQL during complex multi-step reasoning. # Comparisons Source: https://docs.wazoo.dev/comparisons/index How Worlds compares to memory and retrieval alternatives. Worlds is a context engine for agents that need verifiable facts, not just similar text. These pages compare Worlds against the alternatives you are likely weighing: memory layers, agent runtimes, vector stores, and building it yourself. ## What Worlds provides * Graph storage: RDF triples in an append-only, chronological fact ledger. * Hybrid search: vector, full-text, and RDF filters fused by reciprocal rank fusion. * SPARQL queries: declarative, deterministic graph traversal. * Verifiable provenance: every fact carries a traceable path to its source. * Provider-agnostic: you connect your own LLMs and embedding providers. * Edge-ready adapters: LibSQL/Turso and Postgres backends. ## What Worlds does not do Worlds is deliberately narrow. It does not: * Host an LLM. You bring the model. Worlds stores and retrieves facts; the model decides what to ask. * Host an embedding service. Embeddings come from the embedding provider you configure. * Extract memory automatically. Memory in Worlds is curated. Facts enter a world deliberately, through import and patches, rather than being inferred from transcripts. * Run agents. Worlds is not an agent runtime. It is a context source that agents query through tool calls. * Replace your primary database. Worlds is a context engine, not a general operational store. Adapters persist to your existing substrate. * Equate vector similarity with relevance. Similarity != relevance. Vectors are only one retrieval signal in Worlds. The graph structure and SPARQL filters ensure agents retrieve exact, verifiable facts rather than loose semantic guesses. ## How the alternatives line up | Alternative | Core model | Retrieval | Provenance | Managed? | | :-------------------------------------------------------- | :------------------------------ | :----------------------------- | :------------------ | :-------------------- | | [CocoIndex](/comparisons/cocoindex) | Incremental vector sidecar | Vector similarity & ETL | Derived sidecar | Python / Postgres | | [DIY memory infra](/comparisons/diy-memory-infra) | Custom stack | Custom | Your job | You run it | | [DIY triplestore](/comparisons/diy-triplestore) | RDF graph | SPARQL | Your job | You run it | | [Document databases](/comparisons/document-databases) | Semi-structured JSON docs | Field queries & aggregations | Document-level | Managed or self-host | | [GBrain](/comparisons/gbrain) | Personal context vault | Vector similarity & key lookup | Note-level | Self-hosted | | [Google Dataplex](/comparisons/google-dataplex) | Enterprise data fabric | Data catalog & SQL queries | Lineage metadata | Google Cloud | | [Google OKF](/comparisons/google-okf) | Open Knowledge Format | Schema payload & serialization | Entity-level | Open specification | | [Google Search](/comparisons/google-search) | Knowledge Graph + Web Search | Web search & Knowledge Panels | Web URLs | Google Cloud | | [Hermes Agent Memory](/comparisons/hermes) | Multi-tier memory & skills | FTS5 search + system prompt | Session / file | Local CLI runtime | | [Key-value stores](/comparisons/key-value-stores) | High-speed key-value cache | Direct key lookup | None | Managed or self-host | | [LangMem](/comparisons/langmem) | LangGraph vector memory | Similarity search | None | SDK, self-managed | | [Letta](/comparisons/letta) | Stateful agent runtime | Files and vector index | File-level | Self-host | | [LLM Wiki](/comparisons/llm-wiki) | Agent-compiled markdown wiki | File traversal & wikilinks | Article-level | Vault files | | [Maindex](/comparisons/maindex) | Typed memory layer | MCP-based retrieval | Provenance-typed | Managed | | [Mem0](/comparisons/mem0) | Extracted agent memories | Similarity search | Item-level | Hosted or self-host | | [Memblock](/comparisons/memblock) | Block-based memory structures | Block lookup + vectors | Session-level | Managed | | [MemClaw](/comparisons/memclaw) | Shared fleet partition | Partition-aware retrieval | Governed access | Managed | | [MemMachine](/comparisons/memmachine) | Graph + SQL hybrid | Graph traversal + vectors | Graph-derived | Self-host or cloud | | [MemSearch](/comparisons/memsearch) | Standalone memory library | Similarity search | None | Library, self-managed | | [MemSpan](/comparisons/memspan) | Portable files | Dynamic file loading | None | Local files | | [MemSync](/comparisons/memsync) | Verified-embedding memory API | Similarity over embeddings | Inference-verified | Managed | | [Message queues](/comparisons/message-queues) | Sequential event streams | Log consumer offset streaming | Stream log-level | Managed or self-host | | [Palantir Foundry](/comparisons/palantir) | Enterprise Object Ontology | Proprietary Ontology APIs | Pipeline / Lineage | Enterprise SaaS | | [Polygres](/comparisons/polygres) | Custom Postgres schemas + graph | `pgGraph` + `pgContext` SQL | Relational lineage | Managed or extensions | | [Reducto](/comparisons/reducto) | Layout-aware document parser | JSON extraction & chunk search | Document bounding | Cloud API | | [Relational databases](/comparisons/relational-databases) | Normalised SQL tables | SQL queries & JOINs | Foreign key lineage | Managed or self-host | | [Supermemory](/comparisons/supermemory) | Extracted memories | Search, memory graph | Partial | Hosted or self-host | | [TextQL](/comparisons/textql) | Warehouse semantic layer | Natural language SQL & search | Data catalog | Managed Cloud | | [Traditional triplestores](/comparisons/triplestores) | Dedicated RDF graph engine | Standard SPARQL 1.1 | Quad-level | Self-host or cloud | | [TrustGraph](/comparisons/trustgraph) | RDF graph (auto-extracted) | GraphRAG + SPARQL | Extraction traces | Self-host | | [Twilio Memory Store](/comparisons/twilio-memory-store) | Structured memory buckets | Bucket lookup + vectors | Bucket-level | Managed | | [Vault-LD](/comparisons/vault-ld) | Markdown to/from RDF round-trip | YAML-LD + `@context` parser | Note-level | Open specification | | [Vector databases](/comparisons/vector-databases) | Embedding index | Nearest neighbors | None | Usually hosted | | [Zep](/comparisons/zep) | Extracted agent memories | Similarity search | Session-level | Hosted or self-host | Polygres adds graph-style retrieval over Postgres records rather than RDF triples. Turso is the substrate underneath Worlds' `worlds-libsql` adapter rather than a direct alternative. The remaining alternatives cluster by model. Similarity layers such as LangMem, MemSearch, and MemSync recall by embedding. Graph-shaped stores such as MemMachine combine a knowledge graph with SQL. Governed services such as Twilio Memory Store, MemClaw, and Maindex organize structure and access. MemSpan trades structure for portability. None of them exposes a queryable, append-only fact [ledger](/worlds/index) with deterministic SPARQL verification. ## When to choose Worlds Choose Worlds when conformance and interoperability are non-negotiable: agents that rely on W3C open standards (RDF, SPARQL), portable memory layers, and deterministic graph verification across any database or model provider. The append-only ledger and SPARQL query engine keep agent context interoperable and inspectable across database and model providers. Real-world problems Worlds solves: * **Your AI coding assistant forgets your codebase between sessions.** Chat logs truncate and vector recall drifts from the facts. Store facts about your APIs, conventions, and past decisions in a world so the next session resumes from verified graph state instead of a truncated conversation log. * **Your multi-step agent drifts from the facts mid-task.** Long task chains accumulate errors when each step reasons from fuzzy similarity. SPARQL pattern matching confirms that entities and relationships exist before the agent acts on them, keeping multi-hop reasoning grounded in facts. * **You cannot answer "where did this fact come from?"** In strict environments, every assertion needs a traceable source. The append-only ledger records quad-level provenance, so you can audit where each fact came from and when it entered the world. * **You are locked into one vector store or model provider.** Worlds is provider-agnostic: you bring your own LLMs and embedding providers, and adapters persist to LibSQL/Turso or Postgres, so context stays portable. ## Next steps * [Worlds overview](/projects/worlds) * [Search](/worlds/search) * [Query](/worlds/query) * [MemSDK](/projects/memsdk) # Key-Value Stores Source: https://docs.wazoo.dev/comparisons/key-value-stores Worlds vs Key-Value Stores: RDF fact ledger vs high-speed key-value caches. ## At a glance | | Worlds | Key-Value Stores ([Redis](https://redis.io/docs/), [Dragonfly](https://www.dragonflydb.io/docs/), [Memcached](https://memcached.org/)) | | :----------- | :---------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | In-memory key-value caching & data structures | | Data model | RDF triples/quads in an append-only graph ledger | Opaque byte arrays, strings, hashes, lists, sets | | Querying | SPARQL graph traversal, full-text, & vector fusion | Direct key lookup, range queries, & pub/sub commands | | Persistence | Permanent append-only ledger on edge/cloud backends | In-memory with optional asynchronous disk snapshots | | Purpose | Verifiable agent context engine | Low-latency caching, session storage, & rate limiting | ## Overlap and shared capabilities Both Worlds and key-value stores prioritize retrieval performance and simple developer interfaces. Key-value stores like Deno KV can even serve as a underlying storage substrate for Worlds adapters. The difference: * Key-value stores treat values as opaque blobs accessible primarily by key. They do not parse or index relationship graphs between stored items. * Worlds models data as explicit RDF quads, indexing subjects, predicates, and objects so agents can query connections between facts. ## When Worlds fits * You need graph relationship traversal (SPARQL) across stored facts. * You require verified context retrieval combining vector embeddings with graph filters. * You need permanent quad provenance and change ledgers for AI agent operations. ## When Key-Value Stores fit * You need ultra-low latency sub-millisecond caching for hot data. * You are managing ephemeral user sessions, rate limits, or pub/sub queues. * You only need direct key-to-value lookups without semantic relationships. # LangMem Source: https://docs.wazoo.dev/comparisons/langmem Worlds vs LangMem: framework-native memory for LangGraph agents against a shared fact graph. ## At a glance | | Worlds | [LangMem](https://langchain-ai.github.io/langmem/) | | :-------------- | :---------------------------- | :------------------------------------------------- | | Data model | RDF triples in a ledger | Vector embeddings | | How facts enter | Import, patches, agent writes | Agent tools write memory | | Retrieval | Hybrid search + SPARQL | Similarity search | | Provenance | Fact-level ledger | None | | Deployment | Hosted beta or embedded | SDK inside LangGraph | ## The philosophical difference [LangMem](https://langchain-ai.github.io/langmem/) is the memory SDK for the LangGraph ecosystem. It stores embeddings in a vector index and hands the agent tools to write, search, and update its own memory at runtime. Memory is self-managed: the model decides what is worth keeping. Worlds is storage-side. Facts enter through import and patches, relationships are explicit, and the ledger preserves the history of every change. Agents can write new facts through the update API, and each write lands in the append-only ledger as a verifiable patch ([update](/worlds/update)). The difference is custody. LangMem trusts the model to curate its memory; Worlds curates at the data layer. ## When Worlds fits * Facts must survive outside a single framework or agent lifetime. * Answers need to be verifiable rather than similar. * You want the same knowledge queryable from more than one framework. ## When Worlds does not fit * You want memory that lives inside your LangGraph application with no separate graph backend to configure. * You want the model to decide what memory is worth keeping, with no ledger and no data-layer custody. * Embeddings-only recall meets your requirements. ## Coexistence Use LangMem for the agent's working memory inside a LangGraph application, and Worlds for the durable facts the agent is allowed to act on. The [LangGraph integration](/integrations/langgraph) shows how a LangGraph agent calls Worlds for verified context. # Letta Source: https://docs.wazoo.dev/comparisons/letta Worlds vs Letta: a context engine against a stateful agent runtime. ## At a glance | | Worlds | [Letta](https://www.letta.com) | | :--------- | :---------------------- | :----------------------------- | | Category | Context engine | Agent runtime | | Data model | RDF graph | Agent memory files and state | | Retrieval | Hybrid search + SPARQL | Vector index over memory files | | Provenance | Fact-level ledger | File-level versioning | | Deployment | Hosted beta or embedded | Self-hosted server | ## The philosophical difference [Letta](https://www.letta.com) is a framework for building stateful agents. Agents persist memory across conversations, and memory is versioned like a filesystem. It answers the question "how do agents keep state?" Worlds answers a different question: "how do agents know what is true?" It is a context engine that stores and retrieves verified facts. It does not run agents, manage tools, or schedule work. The two are complementary rather than competing. An agent built with Letta can call Worlds when it needs a fact it can trust. ## When Worlds fits * You need a source of truth that any agent can query, regardless of the framework that runs it. * Facts must survive across agent restarts, model swaps, and application rewrites. * You want [SPARQL-verifiable](/worlds/query) answers, not retrieved text. ## When Worlds does not fit * You want a complete agent stack in one system: memory, tool execution, and conversation state. * You need long-running agent workflows with built-in persistence. ## Coexistence Use both. Letta manages agent state and conversation memory; Worlds provides the verifiable knowledge layer. The [MemSDK](/projects/memsdk) includes a Letta adapter, so the same client interface can talk to either backend. # LLM Wiki (Karpathy Pattern) Source: https://docs.wazoo.dev/comparisons/llm-wiki Worlds vs LLM Wiki: schema-validated RDF graphs vs agent-compiled markdown wikis. ## At a glance | | Worlds | LLM Wiki | | :-------------- | :------------------------------------------------ | :--------------------------------------------------------- | | Data model | RDF triples in an append-only ledger | Interlinked Markdown articles (`[[wikilinks]]`) | | Gardening model | Schema-checked assertions & SHACL validation | Continuous agent summarizing, linking, & synthesis | | Retrieval | Hybrid: SPARQL graph filters, vector, & full-text | File traversal (`ls`, `cat`, `grep`) & wikilink navigation | | Provenance | Quad-level, temporal, verifiable via SPARQL | Article-level source citations & git commits | | Primary surface | Context engine API & agent tool calls | Human & agent-readable Markdown vault | ## Overlap and shared capabilities The LLM Wiki pattern (popularized by [Andrej Karpathy](https://x.com/karpathy) and demonstrated in project Farzapedia) and Wazoo Worlds take the same position on agent memory: it should be compiled, structured, and interlinked rather than stored as flat, opaque vector databases. Both approaches organize knowledge into navigable graph nodes where links between concepts matter just as much as raw text search. Where they overlap and build on each other: * LLM Wiki defines the human-and-agent readable workspace, where agents continuously summarize, synthesize, and interlink Markdown articles (`[[wikilinks]]`). * Worlds provides the underlying schema-checked fact engine. It takes those compiled articles and frontmatter assertions, enforces SHACL shape validation, and lets agents execute SPARQL graph queries across the knowledge graph. ## When Worlds fits * You need strict schema validation (SHACL) to prevent metadata drift and hallucinated facts in your knowledge base. * You require deterministic [graph queries](/worlds/query) (SPARQL) across connected entities rather than manual link-following. * You want an append-only ledger that tracks when facts were asserted and by whom. ## When LLM Wiki fits * You want a human-in-the-loop personal knowledge base (Obsidian/Logseq format) where both humans and agents read and edit markdown articles. * You are starting with raw transcripts and want agents to summarize and interlink information organically. ## Coexistence and integration The LLM Wiki pattern is complementary to Wazoo context infrastructure. You can run an LLM Wiki directly using the [Wiki toolchain](/projects/wiki), as demonstrated in the official [`llm-wiki` starter template](https://github.com/wazootech/wiki-templates/tree/main/llm-wiki), where agents continuously garden Markdown articles while Wiki CLI validates RDF shapes. To scale agent knowledge across multi-agent fleets and production environments, we recommend pairing your LLM Wiki with [Worlds](/projects/worlds) as the underlying context engine, so agents maintain human-readable Markdown while querying Worlds via SPARQL for deterministic fact verification. # Maindex Source: https://docs.wazoo.dev/comparisons/maindex Worlds vs Maindex: an MCP memory layer against a verifiable fact graph. ## At a glance | | Worlds | [Maindex](https://github.com/maindex) | | :-------------- | :---------------------------- | :------------------------------------ | | Data model | RDF triples in a ledger | Typed memory structures | | How facts enter | Import, patches, agent writes | API writes | | Retrieval | Hybrid search + SPARQL | MCP-based retrieval | | Provenance | Fact-level ledger | Provenance-attributed | | Deployment | Hosted beta or embedded | Managed layer | ## The philosophical difference [Maindex](https://github.com/maindex) is a cross-platform memory layer exposed as an MCP server. It acts as a source of truth across applications and agents, with typed structures, provenance attributes, and scoped user-controlled access. Memory travels with the tools that use it. Worlds shares the source-of-truth ambition, but the structures are graphs rather than typed records. A fact in Worlds is a triple: two items connected by a property, stored against a timeline. Provenance in Maindex is an attribute on a record; in Worlds it is the path from a fact back to the source that asserted it. Scope control limits who reads; the ledger records what changed and when. ## When Worlds fits * Facts have relationships you need to traverse, not attributes to read. * You want deterministic [SPARQL answers](/worlds/query) over your knowledge. * You need to reconstruct history: when a fact changed and from what source. ## When Worlds does not fit * Your tooling is built around MCP and you want typed memory records attached to the tools themselves. * Typed records with provenance fields satisfy your requirements. * You have no relationships worth traversing. ## Coexistence Route memory between tools through Maindex's MCP layer while Worlds holds the authoritative graph. The [MCP integration](/integrations/agents-skills-mcp) shows how Worlds itself can be reached through MCP tools. # Worlds vs Mem0 Source: https://docs.wazoo.dev/comparisons/mem0 Worlds vs Mem0: curated graph facts against extracted agent memories. ## At a glance | | Worlds | [Mem0](https://mem0.ai) | | :-------------- | :--------------------- | :-------------------------------------- | | Data model | RDF triples | Extracted memory items | | How facts enter | Curated import | Automatic extraction from conversations | | Retrieval | Hybrid search + SPARQL | Similarity search | | Provenance | Fact-level ledger | Item-level | | Query language | SPARQL | SDK retrieval | ## The philosophical difference [Mem0](https://mem0.ai) captures memories from conversations and stores them as extracted items you retrieve by similarity. The memory layer decides what matters and returns the most similar entries when asked. Worlds inverts that. You decide which facts matter, assert them as RDF triples, and the engine keeps them in a chronological ledger. Retrieval is deterministic: the graph either contains the fact or it does not, and [SPARQL](/worlds/query) can prove which. Extracted memories are convenient for chat applications. They are weak when the agent's answer must be defensible, because the stored item is a model-generated summary rather than a fact tied to a source. ## When Worlds fits * Agents act on facts that can be checked against a source of record. * You need to resolve contradictions instead of returning conflicting memories. * You want a queryable knowledge structure, not a bag of extracted items. ## When Worlds does not fit * You want automatic memory from user conversations with zero curation. * Recall quality matters more than factual exactness. * Your team does not want to design a graph vocabulary. ## Coexistence Use Mem0 for conversational context and Worlds for the durable facts the agent is allowed to act on. Keep the two separate: the extracted summary stays on the chat side while the authoritative fact comes from the graph. # Memblock Source: https://docs.wazoo.dev/comparisons/memblock Worlds vs Memblock: deterministic RDF graph context vs block-based agent memory. ## At a glance | | Worlds | [Memblock](https://www.memblock.xyz/) | | :----------- | :----------------------------------------------- | :------------------------------------------------ | | Data model | RDF triples in an append-only ledger | Block-based memory structures & key-value records | | Memory model | Curated graph facts with explicit relations | Managed memory blocks for LLM agent state | | Retrieval | Hybrid: vector, full-text, RDF filters | Block lookup & similarity search | | Provenance | Fact-level, chronological, verifiable via SPARQL | Session/block-level tracking | | Deployment | Edge-ready adapters or hosted cloud | Managed API / SDK | ## The philosophical difference [Memblock](https://www.memblock.xyz/) provides block-structured memory management for LLM applications and agents. It organizes short-term and long-term agent state into modular memory blocks and helps agents retain conversation context and structured user variables across sessions. Worlds treats agent memory as a curated, verifiable knowledge graph. Rather than storing memory as semi-structured blocks or key-value snippets, Worlds enforces RDF triples where every fact has explicit subjects, predicates, objects, and provenance. Where Memblock optimizes for flexible agent scratchpads and block-level memory state, Worlds optimizes for strict fact precision, deterministic graph querying (SPARQL), and auditability. ## When Worlds fits * You need to query relationships between facts using declarative [graph queries](/worlds/query) (SPARQL). * Your memory demands strict fact verification and conflict resolution at the data layer. * You need chronological tracking and full provenance back to source assertions. * You are building edge-native or self-hosted applications that require zero cloud API dependencies. ## When Worlds does not fit * You want simple key-value or block-based state storage for agent conversations without defining graph schemas or RDF relationships. * You are looking for a quick managed memory API for agent session state without requiring graph filters or multi-hop relationship traversal. ## Coexistence Agents can use Memblock for dynamic session scratchpads and ephemeral user preferences, while querying Worlds as the authoritative, long-term semantic knowledge graph for verified facts and domain logic. # MemClaw Source: https://docs.wazoo.dev/comparisons/memclaw Worlds vs MemClaw: governed fleet memory against a shared verifiable fact graph. ## At a glance | | Worlds | [MemClaw](https://github.com/memclaw) | | :-------------- | :---------------------------- | :------------------------------------ | | Data model | RDF triples in a ledger | Shared memory partitions | | How facts enter | Import, patches, agent writes | Agent writes to a partition | | Retrieval | Hybrid search + SPARQL | Partition-aware retrieval | | Provenance | Fact-level ledger | Governed access | | Deployment | Hosted beta or embedded | Cloud-managed | ## The philosophical difference [MemClaw](https://github.com/memclaw) targets fleets. A cloud-managed partition lets many agents write to and read from the same memory, with governance controlling who gets access. The design question is coordination: how a group of agents working together shares one memory safely. Worlds is also shared: many agents query the same world. Isolation is per world, and data-plane tokens are scoped to a single world ([create a world](/projects/worlds)). Coordination happens at the data layer rather than the access layer. Facts are asserted deliberately and stored in a ledger, so two agents acting on the same world agree on the same state. MemClaw governs who may touch memory; Worlds governs what is true within it. ## When Worlds fits * Agents in a fleet must agree on facts, not just share notes. * Conflicting writes need resolution at the data layer, not in the prompt. * You want to [query relationships](/worlds/query) across everything the fleet knows. ## When Worlds does not fit * Your primary problem is fleet partition governance: deciding which agents in a large fleet may touch which shared partition. * You want a managed platform that assigns partitions and access policies across a fleet for you, beyond world-scoped tokens. * Shared memory without graph structure is enough. ## Coexistence Use MemClaw to govern which agents may access which memory partitions, and Worlds as the authoritative knowledge base those agents act on. Access control and factual authority address different failure modes. # MemMachine Source: https://docs.wazoo.dev/comparisons/memmachine Worlds vs MemMachine: a graph-and-SQL memory service against a curated fact ledger. ## At a glance | | Worlds | [MemMachine](https://github.com/memmachine) | | :-------------- | :---------------------------- | :------------------------------------------ | | Data model | RDF triples in a ledger | Graph for episodes, SQL for profiles | | How facts enter | Import, patches, agent writes | Logged conversations and profile writes | | Retrieval | Hybrid search + SPARQL | Graph traversal + vectors | | Provenance | Fact-level ledger | Graph-derived | | Deployment | Hosted beta or embedded | Self-hosted or cloud | ## The philosophical difference [MemMachine](https://github.com/memmachine) is an open-source memory service that splits its model in two. Episodic memory, the relational context of conversations, lives in a Neo4j graph, while profile data lives in SQL. Retrieval walks the graph to reconstruct who said what to whom. It emphasizes token efficiency and works across LLM providers, including AWS Bedrock. Worlds stores relational structure too, but as RDF triples in an append-only ledger. The difference is where structure comes from. MemMachine derives context from conversation logs after the fact; Worlds accepts only facts you assert deliberately. Every fact in Worlds carries a path to its source and a point on the ledger's timeline. The token-efficiency claim is worth weighing honestly. MemMachine reports using fewer tokens than comparable services. Worlds answers the same question with a different currency: exactness. A SPARQL query returns a deterministic result rather than a retrieved context window. ## When Worlds fits * Facts must be true against a source of record, not derived from conversation logs. * You want to [query relationships](/worlds/query) deterministically instead of walking a reconstructed graph. * You need to know when a fact changed and who asserted it. * You want provider-agnostic LLM and embedding choices, including AWS Bedrock ([provider-agnostic](/comparisons/index)). ## When Worlds does not fit * You want episodic memory reconstructed from conversation logs, with no fact curation. Worlds ingests unstructured text but does not extract graph facts automatically ([update](/worlds/update)). * You want a memory service native to AWS operations, such as IAM-based access and Bedrock-managed storage. * Context-window token cost is the binding constraint and you want the memory layer to minimize it. ## Coexistence Run MemMachine for the episodic layer, what an agent talked about and how it reacted, and Worlds for the durable facts the agent may act on. Both store graphs, but the Worlds ledger stays the authoritative source because its facts are curated and verifiable. # MemSearch Source: https://docs.wazoo.dev/comparisons/memsearch Worlds vs MemSearch: a standalone memory library for coding assistants against a shared fact graph. ## At a glance | | Worlds | [MemSearch](https://github.com/memsearch) | | :-------------- | :---------------------------- | :---------------------------------------- | | Data model | RDF triples in a ledger | Vector memory store | | How facts enter | Import, patches, agent writes | Session capture | | Retrieval | Hybrid search + SPARQL | Similarity search | | Provenance | Fact-level ledger | None | | Deployment | Hosted beta or embedded | Library, self-managed | ## The philosophical difference [MemSearch](https://github.com/memsearch) is a standalone, MIT-licensed memory library extracted from the OpenClaw autonomous agent. You drop it into a project and recall past sessions by similarity. Its plugin for Claude Code gives the coding assistant persistent, human-readable memory across development sessions. Worlds is a graph of curated facts. For coding assistants the difference is what counts as memory. MemSearch recalls what you did before; Worlds asserts facts about the codebase and organization that must be true, such as the service that owns a pipeline or the person on call. Recall is similarity; assertion is state. ## When Worlds fits * The fact must be checkable: which team owns this service must resolve exactly. * You want relationships between facts, not just session history. * State changes over time and you need to see the timeline. ## When Worlds does not fit * You want memory today with a single library and no backend, tokens, or graph vocabulary to set up. * Recalling past work by similarity is the whole job. * You do not want to choose any vocabulary. Worlds reuses standard RDF and schema.org vocabularies ([items](/worlds/index)), but you still pick the domain predicates. ## Coexistence Keep MemSearch inside the coding assistant for session recall, and point the assistant at Worlds for authoritative project facts. The [OpenClaw integration](/integrations/openclaw) and [Claude Code integration](/integrations/claude-code) both describe how an assistant reaches Worlds for verified context. # MemSpan Source: https://docs.wazoo.dev/comparisons/memspan Worlds vs MemSpan: portable memory files against a verifiable fact graph. ## At a glance | | Worlds | [MemSpan](https://github.com/memspan) | | :-------------- | :---------------------------- | :------------------------------------ | | Data model | RDF triples in a ledger | Portable files | | How facts enter | Import, patches, agent writes | Export from platforms | | Retrieval | Hybrid search + SPARQL | Dynamic file loading | | Provenance | Fact-level ledger | File-level | | Deployment | Hosted beta or embedded | Local files, zero infrastructure | ## The philosophical difference [MemSpan](https://github.com/memspan) treats memory as documents you own. It extracts identity and history from locked-in platforms such as ChatGPT, stores them as portable files, and loads them into local LLM interfaces like Claude Code. MemSpan runs entirely on local files, so there is no database or server to manage and no vendor locking you in. Worlds treats memory as facts in a graph. A file is readable, but it does not assert relationships or track when a fact changed. MemSpan optimizes for ownership and portability; Worlds optimizes for verifiability and structure. Loading a transcript into a model gives it context. Querying a world gives it facts it can defend. ## When Worlds fits * Facts must be checked against a source and queried deterministically. * Multiple agents or people need structured access to the same knowledge. * A fact connects to other facts and you want to [traverse those links](/worlds/query). ## When Worlds does not fit * You want memory you can open in a text editor with zero dependencies. * Your memory is personal history better served as documents. * You have no relationships to traverse and no need for a queryable timeline. ## Coexistence Use MemSpan to archive raw history from locked-in platforms, then assert the durable facts into a world. The archive keeps the source material; the world keeps the distilled, verifiable state. # MemSync Source: https://docs.wazoo.dev/comparisons/memsync Worlds vs MemSync: an embedding-backed memory API against a verifiable fact graph. ## At a glance | | Worlds | [MemSync](https://github.com/memsync) | | :-------------- | :---------------------------- | :------------------------------------ | | Data model | RDF triples in a ledger | Embeddings plus a memory API | | How facts enter | Import, patches, agent writes | REST writes | | Retrieval | Hybrid search + SPARQL | Similarity over embeddings | | Provenance | Fact-level ledger | Inference-verifiable | | Deployment | Hosted beta or embedded | Managed REST API | ## The philosophical difference [MemSync](https://github.com/memsync) is a managed REST API that adds a long-term memory layer on top of OpenGradient's verifiable inference and embeddings infrastructure. Verification happens at the computation layer: the memory service can attest that the inference producing an embedding ran on verified infrastructure. Worlds verifies at the fact layer. A SPARQL ASK query returns a deterministic boolean for a specific assertion, and the ledger records when the fact entered and from where. The two kinds of verification answer different questions. MemSync proves the computation ran as claimed; Worlds proves the fact is in the graph. ## When Worlds fits * You need fact-level verification: which source asserted this fact, and when. * Answers depend on relationships you want to [traverse with SPARQL](/worlds/query). * You prefer to bring your own LLM and embedding providers. ## When Worlds does not fit * You want one REST call to persist and retrieve long-term memory with no graph vocabulary. * Attested inference over verified infrastructure is a hard requirement of your stack. * You want the memory provider to manage embeddings end to end; Worlds uses the embedding provider you configure ([what Worlds does not do](/comparisons/index)). ## Coexistence Use MemSync as the embedding and retrieval layer for your agents' long-term memory, and Worlds for the authoritative facts those agents act on. Query both through the [MemSDK](/projects/memsdk) interface so swapping backends does not change your calling code. # Message Queues Source: https://docs.wazoo.dev/comparisons/message-queues Worlds vs Message Queues: RDF fact ledger vs asynchronous event streams. ## At a glance | | Worlds | Message Queues ([Kafka](https://kafka.apache.org/documentation/), [RabbitMQ](https://www.rabbitmq.com/documentation.html), [SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/), [NATS](https://docs.nats.io/)) | | :----------- | :---------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Asynchronous message broker & event streaming bus | | Data model | RDF triples/quads in an append-only graph ledger | Sequential message topics, queues, & event logs | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Consumer log offsets & push/pull queue delivery | | Core purpose | Verifiable agent memory & context retrieval | Decoupling microservices & streaming event processing | | Querying | Complex multi-hop graph queries & vector search | Topic streaming & consumer group offset tracking | ## Overlap and shared capabilities Both Worlds and streaming event logs (like [Kafka](https://kafka.apache.org/documentation/)) use immutable, append-only logs as core storage primitives. Both allow tracking temporal event changes over time. The difference: * Message queues stream events between microservices. They prioritize throughput and queue delivery, but do not support indexing or querying graph relationships across historical messages. * Worlds indexes assertions into an RDF knowledge graph, enabling agents to run SPARQL queries and hybrid vector searches across historical facts. ## When Worlds fits * You need to query the current state and provenance of connected facts. * You require hybrid vector + SPARQL graph search for AI agent context retrieval. * You are storing durable knowledge rather than transient inter-service messages. ## When Message Queues fit * You need asynchronous task queueing or pub/sub broadcasting between services. * You are streaming high-volume raw telemetry or event logs. * You need microservice decoupling and guaranteed message delivery semantics. # Palantir Foundry Source: https://docs.wazoo.dev/comparisons/palantir Worlds vs Palantir: developer-native RDF agent context vs enterprise ontology platform. ## At a glance | | Worlds | [Palantir Foundry](https://www.palantir.com/platforms/foundry/) / Ontology | | :-------------- | :-------------------------------------------------- | :------------------------------------------------------------------------- | | Data model | RDF triples in an append-only fact ledger | Enterprise Object Ontology & tabular data pipelines | | Primary surface | Developer-native API & agent tool calls | Enterprise operational suits & analyst dashboards | | Query language | Standard SPARQL + Hybrid (Vector, Full-Text, RDF) | Proprietary Ontology APIs & Phonograph/Workshop | | Target audience | AI agents and developers building agentic workflows | Large enterprise operations and data integration teams | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Heavy enterprise SaaS / dedicated multi-cloud tenant | ## The philosophical difference [Palantir Foundry](https://www.palantir.com/platforms/foundry/) centers around an enterprise Object Ontology, a top-down operational digital twin that binds enterprise data sources, transactional pipelines, and user actions into business objects such as Aircraft, Supplier, and Work Order. It is designed to serve human analysts, executives, and enterprise workflows with heavy governance and integration. Worlds approaches knowledge from a developer-native, agent-first stance. Instead of acting as an all-encompassing enterprise operational platform, Worlds is a lightweight context engine. Facts are asserted as RDF triples into an append-only ledger and exposed directly to AI agents through hybrid search and SPARQL graph queries. Where Palantir provides a heavy end-to-end enterprise platform with UI applications, Worlds provides open, verifiable, edge-ready context infrastructure that agents can query deterministically. ## When Worlds fits * You are building AI agents that need deterministic, verifiable graph context via standard SPARQL and [hybrid search](/worlds/search). * You want open-standard RDF triplestore mechanics without vendor lock-in to an enterprise operational suite. * You need lightweight, edge-deployable memory adapters (e.g., SQLite/LibSQL, Postgres) that fit directly inside your existing application architecture. * You want developer-first [SDKs](/projects/memsdk) (`memsdk`) rather than enterprise analyst UIs and complex data pipeline orchestrations. ## When Worlds does not fit * You need a full-scale enterprise data integration platform with drag-and-drop data pipeline builders, enterprise access governance suites, and executive dashboards. * Your primary users are non-technical business analysts rather than software engineers building autonomous AI agents. * You require deep, out-of-the-box integration with legacy enterprise ERPs, defense systems, and legacy corporate databases. ## Coexistence Worlds and Palantir target different tiers of the software stack. Enterprise teams running Palantir can use Foundry as their macro data lake and operational ontology, while deploying Worlds as a lightweight, SPARQL-driven agent context layer where autonomous micro-agents perform real-time retrieval and fact verification. # Polygres (Evokoa) Source: https://docs.wazoo.dev/comparisons/polygres Worlds vs Polygres by Evokoa: opinionated RDF graph context vs PostgreSQL graph-relational engine. ## At a glance | | Worlds | [Polygres](https://github.com/evokoa/polygres) (Evokoa) | | :----------- | :---------------------------------------------------- | :---------------------------------------------------------- | | Data model | RDF triples in an append-only fact ledger | Relational Postgres tables + `pgGraph` index | | Schema model | Opinionated W3C graph standards (RDF/SHACL) | Your own custom relational database schema | | Retrieval | Hybrid: vector, full-text, RDF filters via SPARQL | Hybrid: SQL + `pgGraph` multi-hop & `pgContext` vectors | | Ideal for | Portable agent memory, RDF graphs, & interoperability | Custom Postgres schemas needing in-database graph traversal | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Managed Postgres platform / open-source extensions | ## The philosophical difference [Polygres](https://github.com/evokoa/polygres) (with its underlying open-source extensions `pgGraph` and `pgContext` by Evokoa) makes standard PostgreSQL "AI-native." It treats your existing relational database tables as the source of truth, building an in-memory graph index over your custom SQL schemas so you can execute multi-hop graph traversals and vector searches directly inside Postgres without moving data. Worlds approaches context with opinionated, interoperable defaults. Instead of requiring you to design, migrate, and maintain custom relational table schemas and SQL join topologies, Worlds enforces standard RDF triples in an append-only chronological ledger, with SPARQL verification out of the box. The tradeoff is do-it-yourself schema design vs. ready-to-use graph context: * Polygres is ideal when you want to build graph-style retrieval over your own existing relational schemas and custom Postgres tables ("DIY graph over SQL"). * Worlds is just as flexible, but provides opinionated RDF defaults, standards-based SPARQL verification, and portable memory SDKs (`memsdk`) so you do not have to design a custom graph database schema yourself. ## When Worlds fits * You want W3C open standards (RDF, SPARQL, SHACL) and portable agent memory across databases and model providers. * You prefer an opinionated fact ledger out of the box rather than designing custom relational tables and graph indexes. * You need chronological provenance tracking for every asserted triple. * You are deploying to [edge environments](/contribute/self-host) (e.g. SQLite/LibSQL via `worlds-libsql`) where full Postgres infra is unavailable. ## When Polygres fits * You already have an extensive PostgreSQL relational database with custom schemas and want to add graph traversal (`pgGraph`) over existing tables. * You want to keep all operational data and agent retrieval strictly within standard Postgres SQL queries without adopting RDF or SPARQL. * Your team prefers constructing and maintaining custom relational schema definitions for agent data. ## Coexistence Applications backed by a primary Postgres database can use Polygres for relational operations and Worlds as the SPARQL-driven agent context engine. Authoritative domain facts sync into Worlds, while operational SQL queries run on Polygres. # Reducto Source: https://docs.wazoo.dev/comparisons/reducto Worlds vs Reducto: RDF fact ledger vs document extraction pipeline. ## At a glance | | Worlds | [Reducto](https://reducto.ai) | | :------------ | :---------------------------------------------------- | :--------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | Document processing API & layout-aware parser | | Data model | RDF triples in an append-only graph ledger | Extracted JSON schemas, markdown, & bounding boxes | | Retrieval | SPARQL graph queries, full-text, & vector fusion | Document chunk search & structured JSON extraction | | Core strength | Deterministic multi-hop SPARQL graph verification | Complex document parsing (PDFs, tables, forms, scan) | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Managed Cloud API | ## Overlap and shared capabilities Both Worlds and [Reducto](https://reducto.ai) solve critical problems in the AI document processing and retrieval pipeline. Both systems convert unstructured content into machine-readable structures so AI agents spend fewer tokens retrieving context and avoid hallucinated values. The key distinction lies in where each system operates: * Reducto is a document parsing engine. It ingests complex, unstructured documents (PDFs, multi-page financial forms, scans) and extracts visual layouts, tables, and structured JSON schemas with high fidelity. * Worlds is an authoritative RDF fact engine. It takes verified assertions, links them into an append-only RDF triple store, and provides SPARQL graph queries alongside vector and full-text search. Reducto acts as an ingestion bridge, turning complex raw files into structured assertions that can be loaded directly into Worlds as verifiable facts. ## When Worlds fits * You need deterministic graph querying (SPARQL) to verify multi-hop relationships across enterprise domain facts. * You require immutable provenance, audit trails, and quad-level assertion tracking. * You want open-standard RDF schemas that operate natively across edge adapters (LibSQL, Postgres) and cloud infrastructure. ## When Reducto fits * You need high-accuracy parsing of visually complex PDFs, tabular data, or scanned forms. * You require bounding-box layout detection and chunking before passing document content to LLMs. * You are building an upstream document extraction pipeline prior to context storage. ## Coexistence and integration Reducto and Worlds complement each other cleanly. In an enterprise pipeline, Reducto parses unstructured documents into structured JSON entities and key-value tuples. Those assertions are then imported into Worlds as RDF quads. Agents can then query Worlds via SPARQL and hybrid search to retrieve verifiable, interconnected knowledge. # Relational Databases Source: https://docs.wazoo.dev/comparisons/relational-databases Worlds vs Relational Databases: RDF fact ledger vs SQL tables. ## At a glance | | Worlds | Relational Databases ([Postgres](https://www.postgresql.org), [MySQL](https://dev.mysql.com/doc/), [SQLite](https://www.sqlite.org/docs.html)) | | :-------------- | :---------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | General-purpose relational data management | | Data model | RDF triples/quads in an append-only graph ledger | Normalised SQL tables, rows, and foreign keys | | Schema rigidity | Flexible graph triples with SHACL shape validation | Fixed table schemas requiring DDL migrations | | Retrieval | SPARQL graph queries, full-text, & vector fusion | SQL queries with JOINs, indexes, & aggregations | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Self-hosted or managed database instances | ## Overlap and shared capabilities Both Worlds and relational databases provide ACID-compliant data persistence and structured queries. In fact, Worlds can persist its RDF quad ledger directly to relational backends like Postgres or LibSQL via adapters (`worlds-postgres`, `worlds-libsql`). The structural difference: * Relational databases require rigid table schemas and explicit foreign-key JOINs, making arbitrary multi-hop relationship discovery complex. * Worlds models data as flexible RDF graph triples. Relationships are first-class entities that can be traversed dynamically via SPARQL without schema migrations. ## When Worlds fits * You are storing dynamic, evolving domain facts and agent memories where schema rigidity is a bottleneck. * You need multi-hop graph queries (SPARQL) to verify connected facts. * You require hybrid vector + full-text + graph retrieval fused via Reciprocal Rank Fusion. ## When Relational Databases fit * You are managing standard OLTP application data (user accounts, orders, transactions). * You require fixed table schemas and established SQL tooling. * You are building core relational infrastructure before adding an AI context layer. # Supermemory Source: https://docs.wazoo.dev/comparisons/supermemory Worlds vs Supermemory: extracted memory against curated graphs. ## At a glance | | Worlds | [Supermemory](https://supermemory.ai) | | :-------------- | :----------------------------------------------- | :------------------------------------ | | Data model | RDF triples in an append-only ledger | Extracted entities and documents | | How facts enter | Curated import (quads or text) | Automatic extraction from sources | | Retrieval | Hybrid: vector, full-text, RDF filters | Search, memory graph, profiles | | Provenance | Fact-level, chronological, verifiable via SPARQL | Partial, derived from sources | | Deployment | Hosted beta or embedded adapters | Hosted or self-hosted | ## The philosophical difference [Supermemory](https://supermemory.ai) builds memory by extracting and structuring information from your connected sources, then serving it back through search, a knowledge graph, and entity profiles. Extraction does the work: you connect a source and the memory layer derives the structure. Worlds takes the opposite stance. Memory is curated, not accumulated. You decide which facts matter, assert them as RDF triples, and the engine keeps them in an append-only ledger. Nothing is inferred; everything is stated. The tradeoff is effort against control. Extraction-based memory is cheap to start and useful for loosely-structured recall. Curated graphs cost more to maintain and return exactly what you stored, with a path back to every source. ## When Worlds fits * The fact must be true, not merely similar: compliance, safety, operations. * You need to resolve contradictions at the data layer instead of leaving the model to guess between conflicting chunks. * You want a deterministic [query language](/worlds/query) (SPARQL) over your knowledge, not just retrieval. * You need a chronological record of when facts changed and who asserted them. ## When Worlds does not fit * You want zero-effort memory from messy, unstructured sources with no curation budget. * Your use case is loose recall ("what did we talk about last week") where an extracted summary is enough. * You are prototyping and have no graph vocabulary in mind yet. ## Coexistence The [MemSDK](/projects/memsdk) defines a common memory interface. You can switch which backend serves a client without changing the calling code, which lets you prototype against an extraction-based store and move to Worlds when the facts need to be authoritative. # TextQL Source: https://docs.wazoo.dev/comparisons/textql Worlds vs TextQL: RDF fact ledger vs enterprise data warehouse context engine. ## At a glance | | Worlds | [TextQL](https://textql.com) | | :------------ | :---------------------------------------------------- | :---------------------------------------------------- | | Primary role | Authoritative RDF fact ledger & SPARQL context engine | AI data analyst & warehouse semantic layer platform | | Data model | RDF triples in an append-only graph ledger | SQL warehouse tables, semantic metrics, & catalog | | Retrieval | SPARQL graph queries, full-text, & vector fusion | SQL generation, semantic search over warehouse schema | | Target domain | Persistent agent memory & verifiable domain graphs | Business intelligence, SQL analytics, & warehouse RAG | | Deployment | Edge-ready adapters (LibSQL, Postgres) or Cloud | Managed Cloud SaaS / Enterprise Warehouse integration | ## Overlap and shared capabilities Both Worlds and [TextQL](https://textql.com) make structured enterprise data accessible to AI agents without relying on ungrounded LLM guesses. Both platforms emphasize schema accuracy, metadata preservation, and verifiable data retrieval over pure vector similarity. The core distinction is target substrate and query language: * TextQL focuses on corporate data warehouses (Snowflake, BigQuery, Databricks). It acts as an AI data analyst, translating natural language into SQL queries against relational tables and semantic business metrics. * Worlds is an RDF knowledge graph context engine. It manages persistent triple assertions, subject-predicate-object graphs, and SPARQL queries with immutable quad provenance. TextQL brings natural language analytics to existing SQL data warehouses, whereas Worlds acts as a persistent, verifiable memory layer for software agents. ## When Worlds fits * You need an append-only RDF fact ledger to store agent memories and enterprise domain graphs. * You require W3C standard SPARQL graph traversal across multi-hop entity relationships. * You want portable, edge-deployable graph storage via LibSQL, Turso, or Postgres. ## When TextQL fits * You want natural language Q\&A and SQL generation over existing SQL warehouses (Snowflake, BigQuery). * You need automated data cataloging, metric definitions, and BI dashboard integration for human analysts. * Your primary data assets are stored in relational analytical tables rather than RDF graphs. ## Coexistence and integration Worlds and TextQL serve distinct layers in an enterprise AI stack. TextQL handles BI analytics and SQL generation over relational data warehouses, while Worlds provides agent fleets with persistent memory, SPARQL entity graphs, and verifiable context retrieval. # Triplestores (Fuseki, GraphDB, Blazegraph, Oxigraph) Source: https://docs.wazoo.dev/comparisons/triplestores Worlds vs Traditional RDF Triplestores: context engine vs enterprise SPARQL engines. ## At a glance | | Worlds | Traditional Triplestores (Jena, GraphDB, Oxigraph) | | :---------------- | :--------------------------------------------------- | :------------------------------------------------- | | Primary role | Multi-modal AI context engine & RDF fact ledger | Dedicated RDF graph database & SPARQL endpoint | | Data model | Append-only RDF quad ledger + hybrid vector index | RDF triples/quads with OWL/RDFS reasoning | | Retrieval | Reciprocal Rank Fusion (SPARQL + Vector + Full-text) | Standard W3C SPARQL 1.1 Query & Update | | Embedding search | Native vector index integrated into RRF retrieval | Varies (plugin-based or external vector stores) | | Storage Substrate | LibSQL/Turso, Postgres, or Cloud | Custom disk structures / RocksDB / Java storage | ## Overlap and shared capabilities Worlds and traditional triplestores (such as [Apache Jena Fuseki](https://jena.apache.org/documentation/fuseki2/), [Ontotext GraphDB](https://graphdb.ontotext.com/), [Blazegraph](https://github.com/blazegraph/database), and [Oxigraph](https://github.com/oxigraph/oxigraph)) share a foundation: W3C open-standard RDF data models and SPARQL query support. Both allow querying deterministic graph relationships using standard subject-predicate-object triples. The difference lies in target architecture: * Traditional triplestores are standalone graph databases optimized for heavy Semantic Web reasoning (OWL/RDFS), enterprise ontologies, and pure SPARQL 1.1 endpoints. * Worlds is built specifically as an AI context engine. It fuses SPARQL graph traversal with native vector embeddings and full-text search using Reciprocal Rank Fusion (RRF), running on lightweight storage backends like LibSQL/Turso and Postgres. ## When Worlds fits * You need hybrid retrieval combining SPARQL graph filters with vector semantic search for AI agents. * You want lightweight, edge-ready storage adapters (LibSQL, Postgres) without managing a Java JVM cluster. * You require append-only quad ledgers with built-in provenance tracking for agent context. ## When Traditional Triplestores fit * You require complex OWL/RDFS enterprise reasoning and heavy semantic inference rules. * You need a standard, standalone SPARQL endpoint for legacy Semantic Web toolchains. * You are running dedicated graph database clusters (e.g. GraphDB Enterprise or Blazegraph). # Worlds vs TrustGraph Source: https://docs.wazoo.dev/comparisons/trustgraph Worlds vs TrustGraph: managed curated graphs against a self-hosted agent platform. ## At a glance | | Worlds | [TrustGraph](https://trustgraph.ai) | | :-------------- | :--------------------- | :------------------------------------- | | Data model | RDF triples | RDF triples (holonic context graph) | | How facts enter | Curated import | Automated extraction plus manual load | | Query | SPARQL + hybrid search | SPARQL + GraphRAG, Document RAG, NL | | Provenance | Fact-level ledger | Extraction traces, audit logs | | Hosting | Managed data plane | You run it (Docker, Kubernetes, cloud) | | Scope | Context engine | Full agent platform | ## The philosophical difference Both platforms build on the same standards: RDF triples and SPARQL queries. That is where the similarity ends. [TrustGraph](https://trustgraph.ai) is a self-hosted agent intelligence platform. It ingests documents, automatically constructs a holonic context graph through entity and relation extraction, and wraps that graph with GraphRAG, ontology RAG, agent runtimes, flows, MCP integration, and model serving. You operate the stack, choose the graph and vector stores, and keep everything inside your infrastructure. Worlds is a managed context engine and deliberately narrow. Facts enter by curation, not extraction, and land in an append-only ledger where every fact carries a traceable path to its source. Retrieval is deterministic by construction: the graph either contains the fact or it does not, and SPARQL can prove which. You bring the LLM and the embedding provider; Worlds stores and retrieves. The practical difference is who decides what a fact is. TrustGraph's platform extracts context at scale and makes it explainable. Worlds asserts curated facts and makes them auditable. The extraction pipeline suits breadth; the curated ledger suits defensibility. ## When Worlds fits * You want the RDF and SPARQL model without operating graph infrastructure. * Facts must be curated and reviewed rather than inferred by a model. * Agents need [hybrid search](/worlds/search) and SPARQL behind scoped tokens, with edge adapters for local and edge deployment. ## When Worlds does not fit * You need automated knowledge graph construction from documents at scale. * You want an all-in-one platform: agents, flows, MCP, model serving, and monitoring in one self-hosted stack. * Your requirements mandate running the entire pipeline on-premise. ## Coexistence Both platforms speak RDF. Export a world to N-Triples and load it into TrustGraph (`tg-load-turtle`), or bring an extracted graph into Worlds when the facts need curation and versioning. The serialization interoperates even when the pipelines do not. # Twilio Memory Store Source: https://docs.wazoo.dev/comparisons/twilio-memory-store Worlds vs Twilio Memory Store: structured buckets against a queryable fact graph. ## At a glance | | Worlds | [Twilio Memory Store](https://www.twilio.com/docs) | | :-------------- | :---------------------------- | :------------------------------------------------- | | Data model | RDF triples in a ledger | Conversational and factual buckets | | How facts enter | Import, patches, agent writes | Bucket writes | | Retrieval | Hybrid search + SPARQL | Bucket lookup + vectors | | Provenance | Fact-level ledger | Bucket-level | | Isolation | Per-world | Strict per-tenant | ## The philosophical difference [Twilio Memory Store](https://www.twilio.com/docs) organizes memory for customer-facing agents. It separates conversational memory, observations and summaries, from factual memory, traits and profiles, and isolates each tenant's data strictly. That isolation makes it a fit for regulated industries such as healthcare and finance. Memory is a structured record you write into the right bucket. Worlds organizes memory as a graph. Tenants map to worlds, and inside a world relationships are first-class: `user:person` connects to `wazoo:organization` through an explicit property. Retrieval is a query, so SPARQL can resolve who owns an account exactly, rather than a read of a predetermined bucket. Both systems keep facts separate from conversation. Worlds goes further by recording every fact against a timeline, so you can see when state changed. ## When Worlds fits * Memory needs relationships, not just categories: ownership, reporting lines, dependencies. * You want to [query facts](/worlds/query) across worlds rather than read fixed buckets. * You need a chronological ledger of fact changes. ## When Worlds does not fit * You need strict per-tenant isolation enforced at the platform level for regulated workloads, rather than per-world isolation with world-scoped tokens ([tokens](/projects/worlds)). * You are building inside the Twilio ecosystem and want memory native to that platform. * Your memory is mostly conversational transcripts where summaries suffice. ## Coexistence Keep conversational history in Twilio Memory Store, the observations and summaries customer agents produce, and store the profile facts agents act on in Worlds. The chat memory stays in the CX platform; the durable facts live in the graph where they can be verified and queried. # Vault-LD Source: https://docs.wazoo.dev/comparisons/vault-ld Linked Markdown vs Vault-LD: portable RDF-in-markdown specs compared. ## At a glance | | Linked Markdown (Wazoo) | [Vault-LD](https://github.com/The-Knowledge-Graph-Guys/vault-ld) (The-Knowledge-Graph-Guys) | | :------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------ | | Core focus | Formal W3C specification, multi-lang Extract API, & toolchain | Open specification & round-trip parser concept | | Frontmatter | Standard JSON-LD / YAML-LD frontmatter | YAML-LD (JSON-LD serialized as YAML) with `@context` | | Reference SDKs | PyPI ([`linked-markdown`](https://pypi.org/project/linked-markdown/)) & JSR ([`@wazoo/linked-markdown`](https://jsr.io/@wazoo/linked-markdown/)) | Reference specification repo | | Ecosystem | Integrated with [`wiki`](/projects/wiki), [`Worlds`](/projects/worlds), and [`memsdk`](/projects/memsdk) | Standalone note vault specification | | Publications | Published W3C CG Editor's Draft & [Zenodo DOI paper](https://zenodo.org/records/21216085) | Open specification (`SPEC.md`) | ## The convergence of Linked Markdown and Vault-LD Both [Linked Markdown](/projects/linked-markdown) (by Wazoo) and [Vault-LD](https://github.com/The-Knowledge-Graph-Guys/vault-ld) (by [The Knowledge Graph Guys](https://www.knowledge-graph-guys.com/)) arrived at the same realization: standard CommonMark files with valid W3C JSON-LD / YAML-LD frontmatter are the open primitive for semantic Markdown and agent knowledge graphs. Because both specifications converged on zero nonstandard syntax and native JSON-LD semantics, an LMD document and a Vault-LD document accept the exact same document structure. A single `.md` file functions simultaneously as human-readable prose and a valid RDF graph node in both ecosystems. ```markdown theme={null} --- "@id": "https://wazoo.dev/team/Ethan_Davidson" "@type": "Person" "@context": "@vocab": "http://schema.org/" givenName: "Ethan" familyName: "Davidson" --- # Ethan Davidson Ethan leads engineering and product on Wazoo/Worlds. ``` The distinction is toolchain maturity and real-world deployment, not document format: * Linked Markdown (LMD) is backed by production-grade tooling: official multi-language Extract APIs (`linked-markdown-py` on PyPI, `@wazoo/linked-markdown` on JSR), a formal W3C Community Group Editor's Draft, a published research paper (Zenodo DOI: `10.5281/zenodo.21216085`), and a complete CLI toolchain (`wiki`, Wazoopedia, `memsdk`, and Wazoo Worlds). * Vault-LD is an open specification (`SPEC.md`) for lossless round-trip parsing in personal knowledge bases. ## Why choose Linked Markdown * Ready-to-install packages for Python ([`pip install linked-markdown`](https://pypi.org/project/linked-markdown/)) and TypeScript ([`jsr:@wazoo/linked-markdown`](https://jsr.io/@wazoo/linked-markdown)) with deterministic [`extract()`](https://jsr.io/@wazoo/linked-markdown/doc/~/extract) APIs that convert markdown directly to RDF quads and JSON-LD nodes. * A formal W3C JSON-LD Community Group specification and a published DOI paper on semantic Markdown infrastructure. * Native integration with the `wiki` CLI (linting, SHACL shape validation, SPARQL querying, and static site rendering) and Wazoo Worlds context engines. ## Interoperability Because Linked Markdown and Vault-LD converged on the exact same underlying RDF 1.1 data model and JSON-LD semantics, they are 100% interoperable. Any Vault-LD document can be extracted, validated, and queried with [`linked-markdown`](/projects/linked-markdown) SDKs or the [`wiki`](/projects/wiki) CLI toolchain. # Vector databases Source: https://docs.wazoo.dev/comparisons/vector-databases Worlds vs vector databases: similarity search against verifiable context. ## At a glance | | Worlds | Vector databases | | :------------- | :------------------------------- | :------------------- | | Data model | RDF triples | Embedding vectors | | Retrieval | Vector + full-text + RDF filters | Nearest neighbors | | Relationships | First-class graph structure | None | | Provenance | Fact-level ledger | None | | Query language | SPARQL | SDK similarity calls | ## The philosophical difference Vector databases (such as [Pinecone](https://www.pinecone.io), [Qdrant](https://qdrant.tech), or [pgvector](https://github.com/pgvector/pgvector)) answer "what is semantically similar?" They index embeddings and return the nearest neighbors. That is a useful primitive, and it is one signal among three in Worlds' [hybrid search](/worlds/search). Worlds stores facts as RDF triples with typed relationships. Retrieval can walk the graph, filter by relationship, and fuse results with vector and full-text signals. When an agent asks "Ethan's manager", a vector store returns the most similar text, which can be another person's manager. Worlds resolves the exact entity, then lets SPARQL traverse the actual relationship. ## When Worlds fits * Answers depend on relationships, not just similarity: ownership, reporting lines, dependencies, provenance. * You need exact answers you can verify with a deterministic query. * Facts change and stale chunks must not contradict current state. ## When Worlds does not fit * Your workload is pure similarity: deduplication, recommendations, anomaly detection over dense data. * You have no relational structure to model. * You are already on a vector store and similarity-only recall is sufficient. ## Coexistence You can keep a vector index for fuzzy recall and add Worlds for the facts that must be exact. Hybrid search inside Worlds already uses vector similarity as one signal, so moving from a vector-only store to Worlds keeps the semantic layer while adding graph precision. # Worlds vs Zep Source: https://docs.wazoo.dev/comparisons/zep Worlds vs Zep: verifiable graph facts against temporal agent memory. ## At a glance | | Worlds | [Zep](https://www.getzep.com) | | :-------------- | :--------------------- | :-------------------------------------- | | Data model | RDF triples | Session memory and extracted entities | | How facts enter | Curated import | Automatic extraction from conversations | | Retrieval | Hybrid search + SPARQL | Similarity search | | Provenance | Fact-level ledger | Session-level | | Query language | SPARQL | SDK retrieval | ## The philosophical difference [Zep](https://www.getzep.com) keeps long-term memory for agents by capturing conversation history and extracting entities and facts over time. Retrieval returns what is similar to the current context, with temporal awareness baked into the memory model. Worlds stores facts you assert as RDF triples in an append-only ledger. The engine does not watch conversations and extract from them. You curate, the graph holds, and [SPARQL](/worlds/query) verifies. Temporal memory is valuable for chat continuity: the agent remembers what happened earlier in the session. It is a weaker foundation for acting on facts, because the recalled item is a derived memory, not a fact with a verifiable source. ## When Worlds fits * The agent's actions depend on facts that must be exact and checkable. * You want one source of truth shared across sessions, agents, and models. * Contradicting facts need resolution at the data layer, not by the model. ## When Worlds does not fit * You need rich conversation recall with minimal setup. * Factual exactness is less important than remembering context. * You have no curation budget for maintaining a graph vocabulary. ## Coexistence Run Zep for conversation memory and Worlds for the facts the agent is allowed to act on. The two answer different questions: "what happened" stays in Zep, "what is true" comes from Worlds. # Export Source: https://docs.wazoo.dev/console/export Download graph data in standard RDF formats from the Console. The export page lets you download all triples from a world in your choice of [RDF serialization format](/worlds/index#serialization). ## Supported formats | Format | Extension | | :--------- | :-------- | | JSON quads | `.json` | | Turtle | `.ttl` | | N-Triples | `.nt` | | N-Quads | `.nq` | | Plain text | `.txt` | ## Export a world 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world. 3. Click **Export** in the sidebar. 4. Select the export format. 5. Click **Download**. The console downloads the full graph as a file. ## Use the API You can also export programmatically: ```bash theme={null} curl -X GET "https://worlds-api.wazoo.dev/worlds/{worldId}/export?format=text%2Fturtle" \ -H "Authorization: Bearer $WORLDS_TOKEN" ``` Change the `format` query parameter for other formats: | Format | `format` value | | :--------- | :---------------------- | | JSON quads | `application/json` | | Turtle | `text/turtle` | | N-Triples | `application/n-triples` | | N-Quads | `application/n-quads` | | Trig | `application/trig` | | JSON-LD | `application/ld+json` | | Plain text | `text/plain` | # Import Source: https://docs.wazoo.dev/console/import Load RDF data into your worlds using the Console. The import page lets you upload graph data into a world. ## Supported formats | Format | Content type | | :--------------- | :----------------- | | JSON quads | `application/json` | | Plain text / CSV | `text/plain` | * JSON quads: an array of objects with `subject`, `predicate`, and `object` fields, and an optional `graph` field. * Plain text: one chunk of text per line. Each line becomes a text chunk indexed for full-text and vector search. ## Import a file 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world. 3. Click **Import** in the sidebar. 4. Select a `.json`, `.txt`, or `.csv` file. 5. Click **Execute Import**. The console parses the file and shows a preview before importing. After the import completes, the console reports the number of quads or text chunks added. If search results look stale after a large import, [reindex](/console/reindex) the world. ## Merge behavior Import appends data to the existing graph. It does not replace existing triples. To replace data, delete the world and create a new one. For how imports fit into the wider mutation model, see [Update](/worlds/update). # Console Source: https://docs.wazoo.dev/console/overview Manage worlds, tokens, and graph data from the Wazoo Console. The [Wazoo Console](https://console.wazoo.dev) is the web interface for managing your worlds, tokens, and graph data. ## Features Run SPARQL queries against your worlds. Load RDF data into your worlds. Browse and find items in your worlds. Manage world-scoped API tokens. Download graph data in standard RDF formats. Rebuild the search index for a world. ## Next steps * [Getting started](/getting-started): create your first world # Reindex Source: https://docs.wazoo.dev/console/reindex Rebuild the search index for a world from the Console. Reindexing rebuilds the full-text and vector search indexes for a world. Use this after bulk [imports](/console/import) or when search results seem stale. For how the [search index](/worlds/search) is built, see the Worlds search docs. ## When to reindex * After a large import * When search results do not reflect recent changes * If the search index state is unknown ## Reindex a world 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world. 3. Click **Reindex World** in the world header. Reindexing is asynchronous. The button shows a confirmation when the reindex completes. Depending on world size, reindexing can take from seconds to minutes. ## What happens Reindexing processes every triple in the world and: 1. Updates the full-text search index. 2. Recomputes vector embeddings for text literals. 3. Rebuilds the graph structure index. The world remains available for queries during reindexing. SPARQL queries continue to work off the underlying graph store. # Search Source: https://docs.wazoo.dev/console/search Browse and find items in your worlds using the Console. The search page lets you browse items in a world using hybrid search. ## Search a world 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world. 3. Click **Search** in the sidebar. Enter a natural language query or an item IRI. The console returns matching items ranked by relevance. ## Filter results Use the filter controls to tune the search: * **Limit (Top K)**: the maximum number of results returned. * **Min Similarity Score**: the minimum vector-similarity threshold for semantic results. ## View results Search results are listed in a table with the subject, predicate, content or object, similarity score, and graph for each hit. See the [Worlds search docs](/worlds/search) for how hybrid search works under the hood. # SPARQL editor Source: https://docs.wazoo.dev/console/sparql Run SPARQL queries against your worlds from the Console. The SPARQL editor lets you run queries and updates against any of your worlds directly from the browser. ## Open the editor 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world from the world list. 3. Click **SPARQL** in the sidebar. ## Run a query Paste a SPARQL query into the editor and click **Run**. Results appear in the panel below the editor. ```sparql theme={null} PREFIX schema: SELECT ?subject ?object WHERE { ?subject a schema:Person ; schema:knows ?object . } ``` ## Run an update Use `INSERT DATA` or `DELETE DATA` to modify graph state. The console shows a success message when the update completes. ```sparql theme={null} PREFIX schema: INSERT DATA { a schema:Person ; schema:givenName "Alice" . } ``` ## Save queries Click **Save Current Query** to keep a query for later, then reopen it from the Saved Queries list. See the [Worlds query docs](/worlds/query) for more on SPARQL with Worlds. # Tokens Source: https://docs.wazoo.dev/console/tokens Manage world-scoped API tokens from the Console. World tokens (prefixed with `wzw_`) are API keys scoped to a single world. Use them to authenticate [data-plane requests](/platform/api) from applications and agents. ## Create a token 1. Open the [Wazoo Console](https://console.wazoo.dev). 2. Select a world. 3. Click **Tokens** in the sidebar. 4. Click **Create token**. 5. Copy the token value. You will not be able to see it again. ## Revoke a token Click **Revoke** next to any token. Revoked tokens stop working immediately. ## Token types | Token | Prefix | Scope | | :------------- | :----- | :----------------- | | World token | `wzw_` | Single world | | Platform token | `wzp_` | All worlds you own | Platform tokens are managed from the **Platform API tokens** section of the console. ## Security * Store tokens in environment variables, not in code. * Use the most restrictive token type for each use case. * Rotate tokens regularly. * Revoke unused tokens. For the full token model and security boundaries, see [Security](/contribute/security). # Security Source: https://docs.wazoo.dev/contribute/security Manage tokens and security boundaries Worlds separates management credentials from world data credentials. Treat them as different secrets with different blast radii. ## Authentication strategies The platform uses separate token kinds depending on the use case. ### Platform tokens Platform tokens use the `wzp_` prefix. They authenticate management operations against the [Wazoo Platform API](/platform/api), including user-owned World metadata, platform tokens, world auth tokens, and usage records. Include the token in the `Authorization` header: ```bash theme={null} Authorization: Bearer wzp_... ``` ### World tokens World tokens use the `wzw_` prefix. They are data-plane credentials for access to specific worlds. Agents and applications should use world tokens when they query or update graph data. Create and revoke them from the [Console](/console/tokens). Store world tokens separately from platform tokens. A world token should not be able to manage platform metadata or mint new platform credentials. World token rotation is revoke-and-replace. The rotation operation revokes the existing World tokens and returns one replacement token once; it must not expand the active token count or access duration when a World is throttled. ### Admin platform tokens Admin platform tokens are global operator credentials for private-beta support. They are manually seeded, never created through public token endpoints, and must use `kind = "ADMIN"`, `user_uid = NULL`, and include the `admin` scope. Admin-only operations and quota bypasses write internal audit events. There is no public audit log API in v1. ### Identity service The Console is the human-facing control surface for Wazoo. Identity and team management are separate from bearer tokens used by APIs and agents. ## Tenant isolation The platform enforces resource boundaries at the user and World level. The current Platform API stores management metadata separately from world graph data. * **Platform boundary**: Platform tokens manage metadata and credentials. * **World boundary**: World tokens authorize data-plane access to specific worlds. * **Resource boundary**: Applications should only receive the narrowest token needed for the task. ## Local development Local and self-hosted deployments may use different authentication settings while they are being developed. Do not expose a deployment publicly unless token validation is enabled and secrets are stored outside source control. Never commit platform tokens, world tokens, database credentials, or tunnel credentials. Rotate any token that appears in logs, source control, screenshots, or shared chat transcripts. # Self-host Source: https://docs.wazoo.dev/contribute/self-host Host Worlds locally or via Docker Worlds self-hosting is available through the respective GitHub repositories. Use the repository README and package docs for the component you are deploying. For how hosted Worlds work, see [Worlds](/worlds/index). ## Current status Self-hosting is not part of the private beta. The supported path depends on which Worlds components you run: * [`worlds-api`](https://github.com/wazootech/worlds-api): the self-hostable Worlds data-plane service (search, SPARQL, import, export). * [`worlds-sdk-ts`](https://github.com/wazootech/worlds-sdk-ts): local and embedded Worlds SDK usage. * [`worlds-client-ts`](https://github.com/wazootech/worlds-client-ts): generated data-plane HTTP client for the hosted or self-hosted Worlds API. * [`worlds-libsql`](https://github.com/wazootech/worlds-libsql): durable SQLite-compatible storage through LibSQL/Turso-style backends. * [`worlds-postgres`](https://github.com/wazootech/worlds-postgres): durable PostgreSQL-backed storage. Private networking patterns such as Docker Compose, Tailscale, or Cloudflare Tunnel depend on your deployment environment and should be configured alongside the repository-specific setup. ## Deployment responsibilities When you self-host, you own: * Worlds data services and storage. * Network ingress and access control. * Token issuance and rotation. * Backups, monitoring, and incident response. Do not assume a compliance posture from these docs alone. Treat each self-hosted deployment as an architecture review for your environment. # Style Guide Source: https://docs.wazoo.dev/contribute/style Documentation formatting and structural guidelines The Worlds documentation follows strict editorial guidelines to optimize for **developer momentum, technical authority, and zero fluff.** Note that "zero fluff" does not mean "zero character." Clarity is prioritized, but project flavor (such as the memory metaphor) is essential for intuition. ## File conventions * Match existing naming patterns in the directory * Use kebab-case (`getting-started.mdx`) for new files or inconsistent directories ## Architecture & structural integrity * **Quality over Quantity**: Prioritize concision and ruthless word economy. Every word must earn its keep. Strip stylistic adjectives (e.g., "facts" not "logical facts") and reduce verbose transitional phrases (e.g., "switch to" not "transition cleanly into using"). If a sentence delivers the same technical weight in fewer words, it *must* be rewritten. * *Bad:* "By combining these logical, structured facts with a search index, your agent can use semantic search to instantly find the right item, and then transition cleanly into using the RDF graph to reason about everything connected to it." * *Good:* "By combining facts with a search index, agents can use semantic search to instantly find the right item, and then switch to reasoning over the RDF graph." * **Standard Terminology**: * **Worlds API / Platform**: The product and interface names. * **Wazoo / Wazoo Technologies**: The company and ecosystem that oversees Worlds and its sibling open-source projects. Use it for company-level references: Wazoo Platform API, Wazoo Console, the `@wazoo/*` packages, and the project family. The product itself is "Worlds". * **Worlds**: The canonical product name. Use bare "Worlds" in general prose, headings, and navigation. * **Wazoo Worlds**: The full brand name. Use it only where it disambiguates or anchors the product: the first mention paired with a named competitor on a comparison page, or ecosystem listings that name sibling Wazoo tools. Use bare "Worlds" everywhere else, including later mentions on the same page. * **world / worlds** (lowercase): Specific world instances (knowledge graphs under the Worlds default engine; the world contract is data-model agnostic). * **engine / context engine**: Functional descriptions of the technical processing layer. * **Verified facts**: Technical descriptions of graph state. * **Memory**: Conceptual analogy permitted for developer intuition. * **Graph pattern query (SPARQL)**: Friendly phrasing for first-touch pages. On introductory pages, introduce SPARQL as "graph pattern query (SPARQL)" on first mention, then bare "SPARQL" afterwards. Keep bare SPARQL on technical pages such as query references and comparisons. * **Actionable Documentation**: Publish pages only when they provide actionable technical value. ## Writing standards ### Voice and structure * **Second-person active voice**: Use "you" ("You can write..." not "Developers can write..."). * **Positive Phrasing**: State what to do, not what to avoid. * **Prescriptive Guidance**: Use definitive verbs like *must*, *requires*, or *use*. * **Timeless Documentation**: Write as if the reader is viewing the docs years from now. * **Global & Inclusive Language**: Omit idioms, slang, and exclusionary terms. * **Sentence-case headings**: Use "Getting started" (not "Getting Started"). Keep headings concise; avoid colons. * **No numbered headings**: Avoid using numbers in section headings (e.g. avoid `### 1. Get token`). Use Mintlify's built-in `` component (`...`) when documenting sequential procedures. * **Sentence-case code titles**: Use "Expandable example". * **Lead with context**: Explain what something is before how to use it. * **Prerequisites first**: Place prerequisites at the start of procedural content. * **Keep markers in body**: Keep contextual markers (like dates) in the body text. * **Contextual examples**: Ensure examples remain self-contained. ### What to avoid * **Zero Marketing Adjectives**: Avoid words like "powerful", "seamless", "robust", or "cutting-edge". * **Filler phrases**: Omit transitional cliches like "at its core", "it's important to note", or "in order to". * **Punctuation cliches**: Do not use em dashes as a crutch to connect thoughts. * **Excessive conjunctions**: Omit "moreover", "furthermore", or "additionally". * **Editorializing words**: Omit "obviously", "simply", "just", or "easily". * **Generic fluff**: Omit generic introductions and concluding summaries. * **Imaginative phrasing**: Avoid anthropomorphic language to describe AI (e.g., avoid "brain", use "model"). **Exception:** High-utility metaphors like **Memory** are permitted to aid developer intuition, though technical descriptions should prioritize terms like **Worlds API** and **Verified facts**. * **Idioms and metaphors**: Avoid phrases that obscure precision (e.g., "heavy lifting"). * **Single-model references**: Discuss general capabilities future-proofed by lists (e.g., "Gemini, Claude, or ChatGPT"). ### Formatting * **Parentheses**: Use sparingly for direct definitions (acronyms). * **Language tags**: All code blocks must have explicit language tags. * **Alt text**: All images and media must have descriptive alt text. * **Link text**: Use descriptive text for links. * **No styling**: Do not use bold or italics in body text. Use meaningful headings and code blocks instead. * **No decorative emojis**: No decorative formatting or emoji. * **Lists**: Use unordered bullets by default. Use ordered lists only for sequences or step-by-step procedures. When a list item defines a term or feature, use a colon to separate the term from its description. * *Good:* "**API**: Programming interface for worlds." * *Bad:* "**API**. Programming interface for worlds." ### Code examples * **Source-Truth Alignment**: Method signatures and properties must mirror TypeScript definitions. * **Keep it simple**: Keep examples practical and concise. * **Realistic values**: Use realistic values (avoid "foo" or "bar"). Relational facts should use canonical project examples like `user:person` and `wazoo:worlds`. * **Tested code**: Verify code works before including it. * **Import consistency**: Group type imports above value imports. When importing from the same path, the `import type` declaration must appear first. ## Development standards ### Exports and namespaces * **SDK entry points**: Use `export *` in `mod.ts` files to re-export all public members from submodules. * **Rationale**: This ensures maximum maintainability and reduces manual export management for comprehensive SDK entry points. ### Imports * **Import grouping**: Group by module source path (e.g., `ai`, `@worlds/sdk`). * **Import separation**: Mandate separate `import type` and `import` declarations per source. * **Import ordering**: When importing from the same path, the `import type` declaration must appear immediately BEFORE the `import` (value) declaration. * *Good:* ```typescript theme={null} import type { Tool } from "ai"; import { tool } from "ai"; import type { ClientInterface } from "@worlds/sdk"; import { Client } from "@worlds/sdk"; ``` * *Bad:* ```typescript theme={null} import { type ClientInterface, Client } from "@worlds/sdk"; ``` * **Tree-shaking optimization**: Use the most specific module entry points (e.g., `import { ulid } from "@std/ulid/ulid"`). * **Import path strategy**: Use aliases (`#/`, `@/`) for cross-package imports. Local relative paths (`./`) are permitted for files within the same directory or subdirectories. Never use parent relative paths (`../`). ### Documentation (JSDoc) * **Identifier-first descriptions**: Descriptions must start with the exact name of the identifier. Use multiline format for readability. * *Good:* ```typescript theme={null} /** * signOutAction signs out the current user session. */ ``` * *Bad:* `/** Signs out the current user session. */` ### HTTP routes and path parameters * **Path names match fields**: Use the same segment names in routes, OpenAPI, and tests as in your TypeScript properties (for example `:worldId` and `{worldId}` for a public World ID). ### Clean code * **Early returns**: Use guard clauses to handle error conditions early, keeping the primary logic at the shallowest possible indentation level. * **Focused functions**: Functions must have a single responsibility. Decompose functions that are excessively large or handle multiple concerns. * **Semantic naming**: Use precise names for all identifiers. Avoid generic terms like `data` or `res` when a domain-specific noun is available. * **Spelled-out locals**: Use full words in variable names, not abbreviations (for example `resolvedSource` not `r`, `inputNamespace` not `ns`). When a natural name collides with another binding in scope, add a short suffix (for example `requestUrl`, `parsedBody`) instead of shortening the word. * **Immutability**: Prefer `const` over `let`. Avoid reassigning variables to store different states of the same data. ### Verification * **Precommit verification**: Always run the relevant precommit task (`deno task precommit` or `npm run precommit:console`) before finalizing a commit. ## Sources and citations * [Mintlify documentation best practices](https://mintlify.com/docs) * [Google developer documentation style guide: Active voice](https://developers.google.com/tech-writing/one/active-voice) # Console quickstart Source: https://docs.wazoo.dev/getting-started From invite to your first query in the Wazoo Web Console UI. Looking to connect programmatically via API, cURL, or SDK? See the [Developer quickstart](/quickstart). This guide walks you from your invite email through signing in, creating a world, importing data, and running your first graph pattern query (SPARQL). ## Before you start You need an invite to the Wazoo private beta. Sign up at [wazoo.dev/beta](https://wazoo.dev/beta). ## 1. Sign in Visit [console.wazoo.dev](https://console.wazoo.dev). Sign in with the email address you used to join the beta. You will receive a one-time passcode. If your email is not on the allowlist, you will see an error. Contact the team if you believe you should have access. ## 2. Create a world After signing in, click **Create world**. Give your world a name and an ID. The ID must be unique across all worlds in the platform. World IDs are public and used in API requests. Choose something descriptive like `my-knowledge-base` or `project-context`. ## 3. Import data Click **Import** in the sidebar. Upload a file with graph data. The console accepts: * JSON quads: an array of objects with `subject`, `predicate`, and `object` fields. * Plain text: one chunk of text per line, indexed for full-text and vector search. If you do not have data yet, upload a JSON file with this content: ```json theme={null} [ { "subject": "https://example.org/user/alice", "predicate": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type", "object": "https://schema.org/Person" }, { "subject": "https://example.org/user/alice", "predicate": "https://schema.org/givenName", "object": "Alice" }, { "subject": "https://example.org/user/bob", "predicate": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type", "object": "https://schema.org/Person" }, { "subject": "https://example.org/user/bob", "predicate": "https://schema.org/givenName", "object": "Bob" } ] ``` ## 4. Run your first graph query (SPARQL) Click **SPARQL** in the sidebar. Paste this query and click **Run**: ```sparql theme={null} PREFIX schema: SELECT ?name WHERE { ?person a schema:Person ; schema:givenName ?name . } ``` You should see `Alice` and `Bob` in the results. ## Next steps * [Console overview](/console/overview): explore all console features * [Worlds concepts](/worlds/index): understand worlds, items, and facts * [Quickstart](/quickstart): connect via the API and SDK # Glossary Source: https://docs.wazoo.dev/glossary Core terminology, concepts, and definitions across the Wazoo neuro-symbolic platform. ## Knowledge graph & RDF concepts ### RDF (resource description framework) A [W3C RDF standard](https://www.w3.org/RDF/) framework for representing information about resources on the web using Subject-Predicate-Object triples. ### SPARQL A declarative query language and protocol for RDF graph databases defined by the [W3C SPARQL 1.1 specification](https://www.w3.org/TR/sparql11-query/). SPARQL allows agents to perform deterministic graph traversals and pattern matching. ### Triple / quad The foundational unit of RDF data: * **Triple**: Subject, Predicate, Object (e.g. `ex:Agent ex:uses ex:Worlds`). * **Quad**: A triple bound to a named graph context (Subject, Predicate, Object, Graph/World ID). ### SHACL (shapes constraint language) A [W3C SHACL standard](https://www.w3.org/TR/shacl/) language for validating RDF graphs against specified shapes and constraints. ### world A stateful dataset that acts as an agent's verifiable, AI-native context. A world records changes chronologically and stays synchronized with retrieval indexes. Worlds' default data model is an RDF knowledge graph with a hybrid search index combining FTS5/BM25 keyword matching, vector embeddings, and RDF structural filters, fused via [reciprocal rank fusion (RRF)](#reciprocal-rank-fusion-rrf). The world contract is data-model agnostic: a world can also be backed by a relational database or another syncable store. ## Neuro-symbolic AI & memory ### Context engine A specialized system that combines structured knowledge graph querying with vector similarity search to provide precise, verifiable context to AI models. ### Reciprocal rank fusion (RRF) An algorithmic technique used by Worlds to fuse search rankings from multiple retrieval signals (pattern queries, full-text search, and vector embeddings) into a single, optimized rank list. ### Provenance The immutable, auditable lineage of facts stored in Worlds, tracking the exact source, timestamp, and context of every quad assertion. ## Wazoo ecosystem ### Worlds The authoritative context engine and RDF fact ledger platform ([wazootech/worlds](https://github.com/wazootech/worlds-api)) built by Wazoo Technologies. ### MemSDK A backend-agnostic TypeScript SDK interface ([wazootech/memsdk](https://github.com/wazootech/memsdk)) that standardizes memory operations (add, search, profile, forget) across multiple memory backends. ### Wazoo skills The official skills package ([wazootech/wazoo-skills](https://github.com/wazootech/wazoo-skills)) that equips AI coding agents with decision mapping and memory context tools. # Build a company brain Source: https://docs.wazoo.dev/guides/company-brain Turn scattered team knowledge into a verifiable knowledge graph agents can query. A company brain is a shared knowledge graph that your agents query instead of scraping Slack threads and stale Notion pages. This guide builds one with Worlds, the Wiki CLI, and the `wazoo` agent skill. Vector-only chunk search returns whatever text is most similar to a query. A company brain returns verified facts: assertions that passed shape validation and carry provenance you can trace to their source. ## Prerequisites * A Wazoo private beta account. Sign up at [wazoo.dev/beta](https://wazoo.dev/beta). * A platform token (`wzp_`) with world permissions. Generate one on the [Console tokens page](/console/tokens). * The `wazoo` CLI, installed per the [CLI reference](/reference/cli). * The `wiki` CLI, installed per the [Wiki install guide](/projects/wiki#install). ## Steps Worlds stores facts in isolated worlds. Create one for the company brain: ```bash theme={null} wazoo worlds create company-brain --name "Company Brain" ``` The world ID `company-brain` is public and used in every data-plane request. Choose a descriptive ID so agents can find the right world. Define SHACL shape constraints for the entities your company tracks: `Person`, `Team`, `Project`, `Decision`, `Meeting`, and `Architecture`. Wiki validates documents against these shapes before they reach the world. Start a wiki vault: ```bash theme={null} wiki init ``` Add a shape for decisions in `brain/shapes/decision.md`: ```yaml theme={null} --- id: wiki:DecisionShape type: sh:NodeShape sh:targetClass: wiki:Decision sh:property: sh:path: schema:name sh:datatype: xsd:string sh:minCount: 1 --- ``` Write an architecture decision record that satisfies the shape in `brain/decisions/ADR-004.md`: ```yaml theme={null} --- id: wiki:ADR-004 type: wiki:Decision name: Adopt Worlds as the company context engine status: Accepted author: https://wazoo.dev/team/Ethan_Davidson --- ``` Run the integrity and convention checks before any document syncs into the company brain: ```bash theme={null} wiki check --strict wiki lint ``` Add both to your CI pipeline so a document with a broken shape or a dangling link cannot reach the ledger. Export the validated ADR as Turtle, then import it into the world: ```bash theme={null} wiki export brain/decisions/ADR-004.md -f turtle -o brain/ADR-004.ttl wazoo worlds import company-brain --file ./brain/ADR-004.ttl ``` The import endpoint accepts Turtle, JSON-LD, N-Triples, N-Quads, and Trig. Every import appends to the chronological ledger, so the brain keeps a complete history of what it knows. Install the `wazoo` skill so coding agents can query the brain with native tool calls: ```bash theme={null} npx skills add wazootech/wazoo-skills --skill=wazoo ``` Export the tokens the skill reads: ```bash theme={null} export WAZOO_PLATFORM_TOKEN=wzp_YOUR_PLATFORM_TOKEN export WORLDS_TOKEN=wzw_YOUR_WORLDS_TOKEN ``` Claude Code, Cursor, OpenCode, and Gemini agents pick up the skill from their workspace automatically. See the [Wazoo skill](/skills/wazoo) page for environment setup and update instructions. ## Check for success Search the brain for the decision you imported: ```bash theme={null} wazoo worlds search company-brain --query "company context engine" ``` Then confirm the fact exists in the graph with a SPARQL query: ```bash theme={null} wazoo worlds sparql company-brain --query "SELECT * WHERE { ?s ?p ?o } LIMIT 10" ``` The search returns the ADR document, and the SPARQL query returns its quads. Both results prove the agent-facing ledger contains verified, queryable facts. ## Use cases * **Autonomous onboarding**: New engineers query the brain for architecture decisions, system topology, and team roles instead of asking in Slack. * **Verifiable ADR tracking**: Agents check accepted decisions before proposing refactors or API changes. * **Multi-agent fleet coordination**: A shared ledger keeps Letta, Hermes, and custom bots working from the same verified facts. ## Next steps * [Worlds overview](/projects/worlds): understand worlds, items, and facts * [Hybrid search](/worlds/search): tune retrieval for your agents * [Graph queries](/worlds/query): write SPARQL patterns against the brain * [MemSDK](/projects/memsdk): add a backend-agnostic memory interface # Entity resolution with Worlds Source: https://docs.wazoo.dev/guides/entity-resolution Keep one person, many names from fragmenting into disconnected histories by composing Worlds' RDF primitives into an entity-resolution pipeline. Worlds does not ship a write-path entity resolver. Identity in a world is an IRI: two mentions of the same person are the same entity only when they carry the same IRI, and facts enter deliberately through import and patches rather than being inferred from transcripts. That is a design decision, not a missing capability. RDF is the substrate. Worlds provides the primitive building blocks — items, facts, the append-only ledger, hybrid search, SPARQL, provenance, and SHACL — and this guide composes those primitives into entity resolution: deciding when "Sarah", "Sarah Chen", and "S. Chen" refer to the same real-world person. Two patterns are covered. **Pattern A resolves at retrieval time**, which Worlds supports natively. **Pattern B resolves at write time**, the conservative three-signal approach popularized by extraction-based memory layers, rebuilt here from Worlds primitives so every decision is auditable. ## Prerequisites * A Wazoo private beta account. Sign up at [wazoo.dev/beta](https://wazoo.dev/beta). * A platform token (`wzp_`) and a world token (`wzw_`), generated on the [Console tokens page](/console/tokens). * A world containing person entities, modeled as [items and facts](/worlds/index). * Familiarity with [hybrid search](/worlds/search) and [SPARQL](/worlds/query). ## The primitives Entity resolution needs five things. Worlds provides all five as RDF primitives — you compose them rather than building storage: | Resolution need | Worlds primitive | | :---------------------------- | :-------------------------------------------------------------------------------------- | | Entity identity | A unique IRI per item | | One person, many names | Label literals (`rdfs:label`, `schema:name`, `schema:alternateName`) indexed as aliases | | "Who does it appear next to?" | Co-occurrence, expressed as a SPARQL pattern over shared neighbors | | "How recently seen?" | A timestamp predicate you assert — time is just another fact | | Merge decisions | `wazoo:resolvesTo` assertions written as ledger patches | The last two are the point of this guide: recency and resolution are not built-in features, but every fact you need to compute them is a triple you can assert and query. ## Pattern A: resolve at retrieval time (native) The default Worlds answer keeps all aliases on one IRI and lets hybrid search collapse mentions at query time. ### Model aliases as labels on one entity Give the person entity every name it answers to: ```turtle theme={null} @prefix user: . @prefix schema: . user:sarah-chen a schema:Person ; schema:givenName "Sarah" ; schema:familyName "Chen" ; schema:name "Sarah Chen" ; schema:alternateName "the new PM" . ``` Worlds indexes label literals as search aliases (a built-in set of label predicates, extendable via the `labelPredicates` option), so a search for "Sarah Chen" or "new PM" resolves to `user:sarah-chen` — the same subject IRI. ### Disambiguate same-name people with co-occurrence Name similarity cannot tell two people named Sarah apart. The graph can: find which candidate shares relationships with your current context. ```sparql theme={null} PREFIX schema: SELECT ?candidate (COUNT(DISTINCT ?shared) AS ?overlap) WHERE { ?candidate a schema:Person ; ?p ?shared . ?p ?shared . FILTER(?candidate != ) } GROUP BY ?candidate ORDER BY DESC(?overlap) ``` The candidate that shares a `schema:knows` or `schema:worksFor` neighbor with Sarah Chen is the Sarah your context means. This is the graph-context signal of [hybrid search](/worlds/search), applied deliberately. ### Ground intent in the ontology Before an agent queries, retrieve the world's ontology with the [`discoverSchema`](/integrations/ai-sdk) tool and map the mention to a concrete class and predicate. Exact terms beat fuzzy matches. ## Pattern B: resolve at write time (Hindsight-style) When mentions arrive as an extraction stream, resolve them before they reach the ledger. Worlds does not do this for you — the guide shows the pipeline. ### 1. Extract and assert mentions with provenance Extract entities from the source with an LLM tool call, then assert each mention as a temporary node tied to its source and timestamp: ```turtle theme={null} @prefix user: . @prefix wazoo: . urn:mention:42 a schema:Person ; schema:name "Sarah Chen" ; wazoo:source ; wazoo:assertedAt "2026-08-04T16:30:00Z"^^ . ``` The timestamp predicate is your choice — asserting it as a fact is itself a use of the substrate. Import these quads through the normal [import path](/worlds/update). ### 2. Retrieve candidates with hybrid search Search the world for the mention's name and take the top candidates: ```bash theme={null} curl -s -X POST "https://worlds-api.wazoo.dev/worlds/my-world-id/search" \ -H "Authorization: Bearer $WORLDS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "query": "Sarah Chen", "topK": 5 }' ``` FTS5 covers keyword and prefix token matches. Candidate retrieval is Worlds' problem; scoring is yours. ### 3. Score with three signals For each candidate compute a weighted score. Name similarity runs in the application layer — SPARQL 1.1 offers no built-in fuzzy string metric, and a string-ratio function over the retrieved label literals is the honest equivalent of a trigram index: ```ts theme={null} const SCORE = { name: 0.5, cooccurrence: 0.3, recency: 0.2 }; const THRESHOLD = 0.6; type Candidate = { iri: string; label: string; overlap: number; lastSeen: string; }; function resolve(mention: string, candidates: Candidate[]) { let best = { iri: null as string | null, score: 0 }; for (const c of candidates) { const score = stringRatio(mention, c.label) * SCORE.name + c.overlap * SCORE.cooccurrence + recencyScore(c.lastSeen) * SCORE.recency; // 1.0 inside a 7-day window, decaying after if (score > best.score) best = { iri: c.iri, score }; } return best.score > THRESHOLD ? best.iri : null; // null means: mint a new entity } ``` `overlap` and `lastSeen` come from two SPARQL queries: ```sparql theme={null} PREFIX schema: PREFIX wazoo: -- Co-occurrence: shared sources between the mention and each candidate SELECT ?candidate (COUNT(DISTINCT ?shared) AS ?overlap) WHERE { ?candidate a schema:Person ; wazoo:source ?shared . wazoo:source ?shared . FILTER(?candidate != ) } GROUP BY ?candidate ``` ```sparql theme={null} PREFIX schema: PREFIX wazoo: -- Recency: when each candidate was last seen SELECT ?candidate (MAX(?t) AS ?lastSeen) WHERE { ?candidate a schema:Person ; wazoo:assertedAt ?t . } GROUP BY ?candidate ``` ### 4. Decide conservatively A wrong merge is worse than a missed one: a duplicate record is recoverable, a corrupted one is not. When the score clears the threshold, link the mention to the existing entity. When it does not, mint a fresh IRI — do not guess. ```turtle theme={null} @prefix user: . @prefix wazoo: . urn:mention:42 wazoo:resolvesTo user:sarah-chen . ``` Unlike a silent record collapse, this resolution is a ledger patch. If it was wrong, retract it with a patch and re-resolve — both states remain in the chronological ledger, and the provenance of every decision is queryable. ### 5. Audit every decision Ask the ledger why a mention resolved the way it did: ```sparql theme={null} PREFIX wazoo: SELECT ?mention ?entity ?t WHERE { ?mention wazoo:resolvesTo ?entity ; wazoo:assertedAt ?t . ?mention wazoo:source ?source . } ``` Every resolution is a fact with a source and a timestamp. That is the property extraction-based memory layers have to build by hand. ## What you build vs what Worlds gives you | Layer | You build | Worlds provides | | :--------------- | :------------------------------------------------------------ | :-------------------------------------------------------- | | Extraction | LLM prompt that pulls mentions from a source | Import path for the asserted quads | | Candidate lookup | Search call | Hybrid search with label-alias indexing | | Similarity | String-ratio function over labels (SPARQL has no fuzzy match) | FTS5 keyword retrieval | | Co-occurrence | — | The graph itself; one SPARQL pattern | | Recency | A timestamp predicate you choose | Chronological, append-only ledger | | Decision | Weighted score and threshold policy | `wazoo:resolvesTo` patches, SHACL shapes to validate them | ## Check for success Search the world for both names and confirm they resolve to one subject: ```bash theme={null} curl -s -X POST "https://worlds-api.wazoo.dev/worlds/my-world-id/search" \ -H "Authorization: Bearer $WORLDS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "query": "Sarah" }' ``` Then verify the resolution exists in the graph: ```bash theme={null} curl -s -X POST "https://worlds-api.wazoo.dev/worlds/my-world-id/sparql" \ -H "Authorization: Bearer $WORLDS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "query": "PREFIX wazoo: ASK WHERE { wazoo:resolvesTo }" }' ``` ## Use cases * **Coherent agent memory**: transcript mentions accumulate into one person history instead of fragmented records. * **Customer identity**: support agents resolve "the customer on the Acme account" to the correct contact without merging accounts. * **Auditable AI pipelines**: every resolution is a provenance-carrying fact a reviewer can replay. ## Next steps * [Worlds concepts](/worlds/index): items, facts, and the ledger * [Hybrid search](/worlds/search): tune the retrieval signal * [Graph queries](/worlds/query): write the patterns behind the score * [Update](/worlds/update): patch state with provenance * [Build a company brain](/guides/company-brain): a sibling guide for shared team knowledge # Manage multiple wikis as a workspace Source: https://docs.wazoo.dev/guides/multi-wiki Compose an umbrella wiki from independent sub-wiki repositories, and manage those repositories as one multi-repo workspace with wspace. A single wiki suits one team or one domain. When teams move independently, separate wikis keep their history and release cadence separate. The trade-off is that isolated wikis stop answering queries as one corpus. This guide shows how to compose an umbrella wiki from independent sub-wiki repositories, and how to manage those repositories as one multi-repo workspace with `wspace`. The umbrella wiki lists each sub-wiki under `sources:` in its `wiki.yml`, pins exact commits in `wiki.lock`, and keeps each sub-wiki as a named RDF graph. You can query the whole corpus at once, or trace a result back to its source repository. `wspace` keeps the repositories in sync with `check`, `update`, and worktree workflows. ## Prerequisites * The `wiki` CLI, installed per the [Wiki install guide](/projects/wiki#install). * The `wspace` CLI, installed per the [Workspace install guide](/projects/workspace#installation). * A repository for each sub-wiki, and one repository for the umbrella wiki. ## Reasons to split Split when you want independent ownership, versioning, or release surfaces: * Each team owns its wiki history and merges its own changes. * A reference library (product docs, regulations, shared domain models) can be reused across multiple umbrellas. * Sub-wikis can publish or evolve on their own schedule. Keep one wiki when the corpus is small or static, or when every page changes at the same pace. Splitting adds a composition layer; a single wiki is still simpler. ## Layout The umbrella repository owns `wiki.yml` with a `sources:` block that points at each sub-wiki repository. Each sub-wiki is its own Git repository. All repositories, umbrella and sub-wikis, are listed in one `repos.json` manifest so `wspace` manages them as a workspace: ```text theme={null} workspace-root/ wiki.yml # umbrella: inputs + sources repos.json # wspace manifest repos/ umbra-wiki/ # umbrella repository product-docs/ # sub-wiki repository team-brain/ # sub-wiki repository ``` ## Steps List the umbrella and each sub-wiki repository in `repos.json`, following the [manifest schema](/projects/workspace#manifest-schema): ```json theme={null} { "$schema": "https://raw.githubusercontent.com/wazootech/workspace-cli/main/schema/workspace-manifest.schema.json", "workspaceRoot": ".", "repositoriesDirectory": "repos", "repositories": [ { "name": "umbra-wiki", "url": "https://github.com/acme/umbra-wiki.git" }, { "name": "product-docs", "url": "https://github.com/acme/product-docs.git" }, { "name": "team-brain", "url": "https://github.com/acme/team-brain.git" } ] } ``` Clone the missing repositories and confirm the workspace is healthy: ```sh theme={null} wspace init wspace check ``` `wspace check` confirms every repository is present and clean. Keep the default branch current with the remote so later updates fast-forward cleanly: ```sh theme={null} wspace update ``` See [Workspace](/projects/workspace) for the full command reference. In the umbrella repository, declare each sub-wiki as an external source. Use a git URL with a `#ref` pin (branch, tag, or commit) so the composition is reproducible: ```yaml theme={null} sources: - name: product-docs type: git url: https://github.com/acme/product-docs.git ref: v2.4.0 - name: team-brain type: git url: https://github.com/acme/team-brain.git ref: main ``` If a sub-wiki keeps its pages in a subdirectory, add `path: ` to point at it. Each source name must be unique across the umbrella. Fetch the sources and pin the resolved commits: ```sh theme={null} wiki install ``` This clones each repository into `.wiki/sources//repo/`, resolves the requested refs to commit SHAs, and writes `wiki.lock`: ```text theme={null} wiki.lock: { "product-docs": "9f2a1c4", "team-brain": "3be7d90" } ``` Check `wiki.lock` into version control; it is the source of truth for which commit of each sub-wiki builds the corpus. If a source declares its own `sources:` block, `wiki install` fetches those transitive dependencies recursively; circular dependency chains raise an error. For the full contract, see [wiki install](https://wiki.wazoo.dev/wiki_install/) and [External data sources (`sources:`)](https://wiki.wazoo.dev/Wiki_Configuration/#external-data-sources-sources). For the product framing, see [Recursive Semantic Datasets](https://wiki.wazoo.dev/Recursive_Semantic_Datasets/). Each sub-wiki stays a named RDF graph. List the graph boundaries: ```bash theme={null} wiki graph list ``` This prints the root graph plus one graph per installed source, with the named graph URI, resolved commit, and dependency owner. Query the whole umbrella as one corpus: ```sparql theme={null} SELECT ?s ?name WHERE { ?s schema:name ?name . } ``` Scope a query to one sub-wiki with a `GRAPH` clause: ```sparql theme={null} SELECT ?s ?name WHERE { GRAPH { ?s schema:name ?name . } } ``` Return the source graph with each result to trace provenance: ```sparql theme={null} SELECT ?g ?s ?name WHERE { GRAPH ?g { ?s schema:name ?name . } } ``` For the read-only boundary and graph URI derivation, see [wiki graph](https://wiki.wazoo.dev/wiki_graph/). Refresh repository baselines, then refresh installed sources: ```sh theme={null} wspace update wiki update ``` `wspace update` fast-forwards clean default branches and skips dirty or feature-branch checkouts. `wiki update` re-fetches the installed sources, installs newly declared transitive sources, and reports orphaned ones. Remove sources you no longer want from the corpus (and their now-unused transitive dependencies): ```sh theme={null} wiki remove team-brain ``` Sub-wiki edits happen in the sub-wiki repository, not in the umbrella's `.wiki/sources/` cache. Make changes there with the normal worktree workflow, then publish the umbrella: ```sh theme={null} wiki build ``` ## Check for success Run the integrity checks in the umbrella repository: ```sh theme={null} wiki check --strict wiki lint --strict ``` Then confirm each source resolves and its graph exists: ```sh theme={null} wiki graph list ``` ## Next steps * [Wiki](/projects/wiki): validate, query, and publish semantic Markdown wikis * [Workspace](/projects/workspace): manage multi-repository workspaces with `wspace` * [External data sources (`sources:`)](https://wiki.wazoo.dev/Wiki_Configuration/#external-data-sources-sources): the composition reference * [Recursive Semantic Datasets](https://wiki.wazoo.dev/Recursive_Semantic_Datasets/): the design behind named-graph provenance # Agents, skills, and MCP Source: https://docs.wazoo.dev/integrations/agents-skills-mcp How AI coding agents connect to Wazoo memory using skills and MCP protocol. ## Overview Agents connect to Worlds through two REST surfaces: * **Control plane** (`api.wazoo.dev`): manage worlds and API tokens with a `wzp_` token. * **Data plane** (`worlds-api.wazoo.dev`): [import](/worlds/update), [search](/worlds/search), [pattern queries](/worlds/query), and [export](/console/export) using a `wzw_` token. The MCP protocol is part of this agent-native surface. The REST endpoints above are the stable way to reach it today. ## Install the `wazoo` skill For install instructions and the full reference, see [the `wazoo` skill docs](/skills/wazoo). # Agno Source: https://docs.wazoo.dev/integrations/agno Connect Worlds to Agno [Agno](https://www.agno.com), formerly Phidata, is a framework for building agents with memory, knowledge, and tools. # AI SDK Source: https://docs.wazoo.dev/integrations/ai-sdk Connect Worlds knowledge graphs to Vercel AI SDK The [Vercel AI SDK](https://sdk.vercel.ai/) is the TypeScript toolkit for building AI applications with React, Svelte, and Vue. The Wazoo AI tools package (`@wazoo/tools`) exposes tools that let LLMs [search](/worlds/search) and [query](/worlds/query) `@worlds/sdk` knowledge graphs. ## Installation Install the Wazoo AI Tools from JSR: ```bash npm theme={null} npx jsr add @wazoo/tools ``` ```bash deno theme={null} deno add jsr:@wazoo/tools ``` ```bash pnpm theme={null} pnpm dlx jsr add @wazoo/tools ``` ```bash yarn theme={null} yarn dlx jsr add @wazoo/tools ``` ```bash bun theme={null} bunx jsr add @wazoo/tools ``` ## Usage The tools are designed to work with the [Vercel AI SDK](https://sdk.ai/docs/ai-sdk-core/tools-and-tool-calling). ```typescript theme={null} import { generateText } from "ai"; import { openai } from "@ai-sdk/openai"; import { Client } from "@worlds/sdk"; import { ComunicaSparqlEngine } from "@worlds/sdk/comunica"; import { RdfjsQuadStore, RdfjsSearchIndex } from "@worlds/sdk/rdfjs"; import { QueryEngine } from "@comunica/query-sparql-rdfjs-lite"; import { Store } from "n3"; import { createTools } from "@wazoo/tools"; const store = new Store(); const client = new Client({ quadStore: new RdfjsQuadStore(store), searchIndex: new RdfjsSearchIndex(store), sparqlEngine: new ComunicaSparqlEngine({ queryEngine: new QueryEngine(), store, }), }); const tools = createTools({ client, sources: ["my-world"], }); const { text } = await generateText({ model: openai("gpt-4o"), tools, prompt: "Find all people in the knowledge base and describe them.", }); ``` ## Tools The `createTools` function returns a full toolset for use with LLM frameworks. ### Individual tools If you require granular control, you can import and initialize tools individually: ```typescript theme={null} import { createDiscoverSchemaTool, createExecuteSparqlTool, createSearchEntitiesTool, createImportRdfTool, createExportRdfTool, } from "@wazoo/tools"; // client is the @worlds/sdk instance from the usage example above. const discoverSchema = createDiscoverSchemaTool(client, { sources: ["my-world"], }); const executeSparql = createExecuteSparqlTool(client); const searchEntities = createSearchEntitiesTool(client); const importRdf = createImportRdfTool(client); const exportRdf = createExportRdfTool(client); const tools = { discoverSchema, executeSparql, searchEntities, importRdf, exportRdf, }; ``` ### Tool reference | Tool | Description | | :--------------- | :--------------------------------------------------------- | | `executeSparql` | Direct execution of SPARQL queries (read-only by default). | | `searchEntities` | Vector and keyword search for entities within a graph. | | `discoverSchema` | Explore the ontology and schema of a specific world. | | `importRdf` | Utility for ingesting RDF triples into a world graph. | | `exportRdf` | Utility for exporting RDF triples from a world graph. | # Claude Code Source: https://docs.wazoo.dev/integrations/claude-code Connect Worlds to Claude Code **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview) is an agentic coding companion built by Anthropic that operates directly inside your local terminal. # Claude Memory Tool Source: https://docs.wazoo.dev/integrations/claude-memory-tool Connect Worlds to Claude Memory Tool The [Claude Memory Tool](https://docs.anthropic.com/) lets AI agents persist context and recall facts across multiple interactions. # CrewAI Source: https://docs.wazoo.dev/integrations/crewai Connect Worlds to CrewAI [CrewAI](https://www.crewai.com/) is an open-source framework for orchestrating role-playing autonomous AI agents. # Gemini Source: https://docs.wazoo.dev/integrations/gemini-api Connect Worlds to Google Gemini **Experimental Integration** Worlds capabilities for Gemini are under active development. Expect API friction and missing language parity. Google's [Gemini API](https://ai.google.dev/) provides multimodal AI models for reasoning and text generation. # Gemini Live API (Voice) Source: https://docs.wazoo.dev/integrations/gemini-live-api Connect Worlds to Gemini Live API The [Gemini Live API](https://ai.google.dev/) streams low-latency, bidirectional multimodal conversations from Google's foundation models. # LangChain Source: https://docs.wazoo.dev/integrations/langchain Connect Worlds to LangChain [LangChain](https://www.langchain.com/) is a framework for building context-aware applications with large language models. # LangGraph Source: https://docs.wazoo.dev/integrations/langgraph Connect Worlds to LangGraph [LangGraph](https://www.langchain.com/langgraph) is a framework-agnostic library for building stateful, multi-actor applications with LLMs. # Mastra Source: https://docs.wazoo.dev/integrations/mastra Connect Worlds to Mastra [Mastra](https://mastra.ai/) is an un-opinionated AI framework you can run alongside your application code. Because it follows Vercel AI SDK standards, `@wazoo/tools` works with Mastra agents out of the box. ## Installation Install Mastra core and the Wazoo AI tools: ```bash npm theme={null} npm i @mastra/core && npx jsr add @wazoo/tools ``` ```bash deno theme={null} deno add npm:@mastra/core jsr:@wazoo/tools ``` ```bash pnpm theme={null} pnpm add @mastra/core && pnpm dlx jsr add @wazoo/tools ``` ```bash yarn theme={null} yarn add @mastra/core && yarn dlx jsr add @wazoo/tools ``` ```bash bun theme={null} bun add @mastra/core && bunx jsr add @wazoo/tools ``` ## Usage You can pass `@wazoo/tools` directly to a Mastra `Agent`. ```typescript theme={null} import { Agent } from "@mastra/core/agent"; import { openai } from "@ai-sdk/openai"; import { Client } from "@worlds/sdk"; import { ComunicaSparqlEngine } from "@worlds/sdk/comunica"; import { RdfjsQuadStore, RdfjsSearchIndex } from "@worlds/sdk/rdfjs"; import { QueryEngine } from "@comunica/query-sparql-rdfjs-lite"; import { Store } from "n3"; import { createTools } from "@wazoo/tools"; const store = new Store(); const client = new Client({ quadStore: new RdfjsQuadStore(store), searchIndex: new RdfjsSearchIndex(store), sparqlEngine: new ComunicaSparqlEngine({ queryEngine: new QueryEngine(), store, }), }); const { executeSparql, searchEntities } = createTools({ client, sources: ["my-world"], }); // Create a Mastra agent with Worlds tools const agent = new Agent({ name: "WorldsAgent", instructions: "You are a knowledge graph assistant.", model: openai("gpt-4o"), tools: { executeSparql, searchEntities, }, }); const result = await agent.generate("Find all people in my world."); console.log(result.text); ``` ## Granular selection If you only need specific tools, you can import and initialize them individually: ```typescript theme={null} import { Agent } from "@mastra/core/agent"; import { openai } from "@ai-sdk/openai"; import { createSearchEntitiesTool } from "@wazoo/tools"; // client is the @worlds/sdk instance from the usage example above. const agent = new Agent({ name: "SearchAgent", model: openai("gpt-4o"), tools: { search: createSearchEntitiesTool(client), }, }); ``` # MS Agent Framework Source: https://docs.wazoo.dev/integrations/ms-agent-framework Connect Worlds to MS Agent Framework The [Microsoft Agent Framework](https://azure.microsoft.com/) provides deployment tools for orchestrating and scaling AI agents securely in Azure. # n8n Source: https://docs.wazoo.dev/integrations/n8n Connect Worlds to n8n **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [n8n](https://n8n.io/) is an extendable, source-available workflow automation tool for visually connecting apps and APIs. # OpenAI Source: https://docs.wazoo.dev/integrations/openai Connect Worlds to OpenAI **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. The [OpenAI SDK](https://platform.openai.com/) is the client for calling models like GPT-4o and o1 from your own code. The [OpenAI Agents SDK](https://platform.openai.com/docs/agents) manages multi-turn conversations, tool calls, and thread state across a session. # OpenCLAW Source: https://docs.wazoo.dev/integrations/openclaw Connect Worlds to OpenCLAW **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [OpenClaw](https://openclaw.ai/) is an AI messaging gateway that connects logic agents natively to WhatsApp, Discord, Slack, and Telegram. # OpenCode Source: https://docs.wazoo.dev/integrations/opencode Connect Worlds to OpenCode **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [OpenCode](https://opencode.de/) is an open-source collaborative software exchange environment built exclusively for the public administration sector. # ViaSocket Source: https://docs.wazoo.dev/integrations/viasocket Connect Worlds to ViaSocket [viaSocket](https://viasocket.com/) is a declarative integration platform for building AI-powered microservices and API workflows. # Zapier Source: https://docs.wazoo.dev/integrations/zapier Connect Worlds to Zapier **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [Zapier](https://zapier.com/) is an automation platform that connects thousands of web applications so you can build workflows across them. # Zo Computer Source: https://docs.wazoo.dev/integrations/zo Connect Worlds to Zo Computer **Experimental Integration** The official Worlds capabilities for this framework are under active development. Expect API friction and missing language parity. [Zo](https://zo.computer/) is a personal AI that runs on your own cloud computer. It lets you text instructions, schedule agents, build tools, and sync your apps 24/7. # Introduction Source: https://docs.wazoo.dev/introduction Verifiable context engine for AI. Worlds is an open-source verifiable context engine for edge knowledge graphs. It gives agents a deterministic context graph with source provenance and explainability. Reasoning is traceable, with none of the opacity of vector-only memory. ## Core surfaces Onboarding from invite to first query. Connect and run queries in 2 minutes. Manage Worlds, tokens, usage, and billing. Use `@wazoo/client` for platform management. Visual platform for graph management. ## Core capabilities Deterministic graph logic and decision traces. Vectors fused with full-text and RDF traversal. Connect your own LLMs and embeddings. Low-latency graph architecture for edge runtimes. ## Next steps * [Getting started](/getting-started) - Onboarding from invite to first query. * [Quickstart](/quickstart) - Execute your first query. * [Console overview](/console/overview) - Manage your worlds in the browser. * [Projects](/projects) - Browse ecosystem libraries. # Manifesto Source: https://docs.wazoo.dev/manifesto The next default for human knowledge With the rise of autonomous agents, the externalized hard drive can now read, synthesize, pattern-match, and generate artifacts. But modern AI systems are stateless out of the box: advanced reasoning engines with no memory of past interactions. Worlds is the engine for personalized software. It gives autonomous agents the stateful context they need to move from statistical mimicry toward intentional agency. It fuses Large Language Models with the Semantic Web, using a [knowledge graph](/projects/worlds) that steers behavior through individual preference data. We believe computing still falls short of its potential for people. Software is about to eat the world again. # Wazoo Platform Source: https://docs.wazoo.dev/platform Management surfaces for Worlds, tokens, usage, and platform status Worlds has two API layers: * **Wazoo Platform API**: manages users, world metadata, platform tokens, world tokens, usage records, limits, and billing state. * **Worlds Data API**: reads and writes graph data through worlds, including [import](/worlds/update), [export](/console/export), [search](/worlds/search), and [graph pattern queries (SPARQL)](/worlds/query). Use the Platform API when you are provisioning or managing resources. Use the Worlds Data API when an application or agent needs to query or update graph state. Usage and limits use transparent resource accounting: Worlds records the underlying resources consumed by Worlds operations, such as database operations, import bytes, query duration, and storage bytes. Stripe is the billing source of truth, but private beta access does not require live payment enforcement. The Console is the human-facing control surface for the same platform concepts. Some Console flows are still private-beta and may not be available to every user. Manage Worlds, tokens, usage, limits, and billing state. Use `@wazoo/client` for platform management from JavaScript or TypeScript. Open the private-beta Console when your account has access. # Platform API Source: https://docs.wazoo.dev/platform/api Manage Worlds, tokens, and usage. The Worlds architecture separates management operations from graph data operations: ```mermaid theme={null} graph TD Client["Client / AI Agent"] subgraph ControlPlane ["Control Plane (api.wazoo.dev)"] TokenWzp["Platform Token (wzp_)"] ResMgmt["Provision Worlds, API Tokens & Billing"] end subgraph DataPlane ["Data Plane (worlds-api.wazoo.dev)"] TokenWzw["World Token (wzw_)"] GraphOps["SPARQL, Hybrid Search, Import/Export"] end Client -->|"Manage resources"| ControlPlane Client -->|"Query & mutate graphs"| DataPlane ``` ## Authentication Platform API requests use platform tokens with the `wzp_` prefix: ```http theme={null} Authorization: Bearer wzp_... ``` Platform tokens manage resources. World auth tokens use the `wzw_` prefix and are intended for data-plane access to specific worlds. ## Base URL ```text theme={null} https://api.wazoo.dev/v1/ ``` For local development of the Platform API server, use the Wrangler dev URL for your Worker. ## Resources The Platform API covers these management resources: | Resource | Routes | | ----------------- | ----------------------------------------------------------------------- | | Worlds | `/v1/worlds`, `/v1/worlds/:worldId` | | Platform tokens | `/v1/auth/api-tokens` | | World auth tokens | `/v1/worlds/:worldId/auth/tokens` | | Usage | `/v1/worlds/:worldId/usage` | | Limits | `/v1/worlds/:worldId/limits` | | Billing | `/v1/worlds/:worldId/billing`, `/v1/worlds/:worldId/billing/openPortal` | | Users | `/v1/users/me` | | Stripe webhook | `/v1/stripe/webhook` | Public `worldId` values must match `^[a-z][a-z0-9-]{2,62}$`. Internal `uid` values use prefixes such as `w_...` so they cannot be confused with public path IDs. ## Data-plane boundary The Platform API does not execute SPARQL, search triples, import RDF, or export RDF. Those operations belong to the Worlds Data API (`worlds-api.wazoo.dev`), its generated client `@worlds/client`, or the embedded `@worlds/sdk`. ## Related * [TypeScript SDK](/platform/typescript-sdk) — typed client for the Platform API. * [Worlds CLI](/reference/cli) — command-line management of worlds. * [Console tokens](/console/tokens) — create and revoke platform tokens. * [OpenAPI spec](https://api.wazoo.dev/openapi.json) — live API reference. # Pricing Source: https://docs.wazoo.dev/platform/pricing Pricing and billing details during the Wazoo Platform private beta. The Wazoo Platform is currently free during private beta. Payment is not required, and billing is not enforced. ## Private beta pricing * **Free access**: Access to hosted Worlds, the Wazoo Console, and the Platform API is completely free during private beta. * **Tracked, not metered**: Resource accounting tracks database operations, import bytes, query durations, and storage bytes, but usage limits are not enforced and live payment is not required. * **No self-service signup**: Private beta access is managed via allowlist. Sign up at [wazoo.dev/beta](https://wazoo.dev/beta). ## Billing architecture Stripe-backed billing endpoints exist in the Wazoo API infrastructure, but billing enforcement remains inactive for private beta accounts. For detailed information on resource-accounting dimensions and platform tokens, see the [Platform API reference](/platform/api). ## Beta limitations To maintain parity with [Private Beta status](/platform/private-beta), active platform limitations include: * Data-plane API stability subject to minor updates before general availability. * Selective availability of console features. * Account onboarding restricted to allowlisted users via manual invite. * Search index updates require triggering a manual [reindex](/console/reindex) after large imports. Commercial pricing tiers and self-service plans will be announced prior to general availability. # Private beta Source: https://docs.wazoo.dev/platform/private-beta Sign up for the Wazoo Platform private beta and get access to Worlds, the Console, and the Platform API. The Wazoo Platform is in private beta. Sign up to get access to hosted Worlds, the Console, and the Platform API. ## Sign up Visit [wazoo.dev/beta](https://wazoo.dev/beta) and fill out the form. After you're added to the allowlist, you can sign in to the [Console](https://console.wazoo.dev) with your email. Sign-in uses a one-time passcode (WorkOS). ## What's included * Console: manage Worlds, tokens, usage, and billing at `console.wazoo.dev`. * Wazoo Platform API: provision Worlds and manage platform resources programmatically. See the [Platform API reference](/platform/api). * Hosted Worlds: persistent, queryable knowledge graphs with SPARQL and vector search. * World Tokens: API keys scoped to individual worlds for data-plane access. ## Beta status The Platform API is public-facing and production-oriented. Some Console flows are still private-beta and may not be available to every user. Usage tracking is in place, but private beta access does not require live payment enforcement. ## Known limitations These are active limitations during the private beta: * Data-plane API: the Worlds Data API is stable but may see breaking changes before general availability. * Console flows: some Console features are still in development and may not be available to every user. * No self-service signup: access is managed through a manual allowlist. * No billing enforcement: usage is tracked but not metered. Limits may be adjusted. * Search index staleness: after imports, trigger a [reindex](/console/reindex) to refresh search results. * Mobile responsiveness: the console is optimized for desktop browsers. ## Privacy The Console asks you to confirm that you are at least 13 years old before creating an account. See the [privacy policy](/privacy-policy) for how Wazoo handles personal information and users under 13. ## Next steps * [Getting started](/getting-started): onboarding from invite to first query. * [Console overview](/console/overview): explore console features. * [Quickstart](/quickstart): connect to the API in 2 minutes. * [Troubleshooting](/platform/troubleshooting): common errors and fixes. # Troubleshooting Source: https://docs.wazoo.dev/platform/troubleshooting Common errors and solutions for the Wazoo Platform. ## Allowlist errors ### Not on the allowlist Your email has not been added to the private beta allowlist. This can happen if: * You signed up but have not been approved yet. * You signed in with a different email than the one you used to sign up. Contact the team if you believe you should have access. ## Token issues ### Invalid token Your token is malformed or has been revoked. Generate a new token from the [tokens page](/console/tokens) in the console. ### Token expired World tokens do not expire by default but can be revoked. Platform tokens may have a limited lifespan depending on how they were created. ### Unauthorized The token does not have access to the resource. Check that: * A world token is scoped to the correct world. * A platform token has the required permissions. ## Connection issues ### Cannot reach the console Check that `console.wazoo.dev` is accessible from your network. If you are behind a corporate VPN, you may need to allowlist the domain. ### API returns 502 or 503 The service is temporarily unavailable. Wait a few minutes and retry. ## Import errors ### Format not supported The file is not in a supported import format. The console accepts JSON quads (an array of `subject`/`predicate`/`object` objects) or plain text lines. Convert your data to one of those formats and try again. ### Invalid JSON The JSON file must contain an array of objects, each with `subject`, `predicate`, and `object` fields. Fix the file and try again. ## Search issues ### Search returns no results The search index may need to be rebuilt. Go to the Reindex page for your world and trigger a reindex. See [Search](/worlds/search) for how the index is built. ### Search results are stale The index is rebuilt asynchronously. If you recently imported data and search results do not reflect it, trigger a [reindex](/console/reindex). ## Verify a world is working 1. Open the world in the console. 2. Run `SELECT * WHERE { ?s ?p ?o } LIMIT 10` in the SPARQL editor. 3. If results appear, the world is online and queryable. If the query returns results but search does not, trigger a [reindex](/console/reindex). # TypeScript SDK Source: https://docs.wazoo.dev/platform/typescript-sdk Use @wazoo/client to manage Wazoo platform resources. `@wazoo/client` is the primary TypeScript SDK for the [Wazoo Platform API](/platform/api). It provides a typed interface for managing your Wazoo infrastructure: provisioning Worlds, managing API tokens (`wzp_` and `wzw_`), and tracking resource usage and billing. ## Install ```bash npm theme={null} npx jsr add @wazoo/client ``` ```bash deno theme={null} deno add jsr:@wazoo/client ``` ```bash pnpm theme={null} pnpm dlx jsr add @wazoo/client ``` ```bash yarn theme={null} yarn dlx jsr add @wazoo/client ``` ```bash bun theme={null} bunx jsr add @wazoo/client ``` ## Quickstart ```typescript theme={null} import { listWorlds } from "@wazoo/client"; // Connects to https://api.wazoo.dev and reads process.env.WAZOO_PLATFORM_TOKEN out of the box const { data, error } = await listWorlds(); console.log(data?.worlds); ``` Platform tokens require the `wzp_` prefix. ## Worlds ```typescript theme={null} import { listWorlds, createWorld, getWorld, updateWorld, deleteWorld, } from "@wazoo/client"; // List active worlds const { data } = await listWorlds(); console.log(data?.worlds); // Create a world const created = await createWorld({ body: { worldId: "support-knowledge", world: { displayName: "Support Knowledge", region: "auto" }, }, }); // Get a world by ID const world = await getWorld({ path: { worldId: "support-knowledge" }, }); // Update display name await updateWorld({ path: { worldId: "support-knowledge" }, body: { updateMask: "displayName", world: { displayName: "Support Knowledge Base" }, }, }); // Soft-delete (recoverable for 30 days) await deleteWorld({ path: { worldId: "support-knowledge" } }); ``` Creating a platform world provisions a per-World Turso database. Use `worlds-api.wazoo.dev`, the generated [`@worlds/client`](/projects/worlds), or the embedded [`@worlds/sdk`](/projects/worlds) for graph data operations inside that world. ## Platform API tokens ```typescript theme={null} import { listPlatformTokens, createPlatformToken, deletePlatformToken, } from "@wazoo/client"; // List tokens const { data } = await listPlatformTokens(); // Create a token (secret shown once) const created = await createPlatformToken({ body: { name: "my-read-token", scope: "users.read worlds.read usage.read", }, }); console.log(created.data?.token); // wzp_... // Revoke a token by name await deletePlatformToken({ path: { tokenName: "my-read-token" } }); ``` ## World auth tokens World data-plane tokens use the `wzw_` prefix. They are scoped to a single namespace and optionally a single world. ```typescript theme={null} import { listWorldTokens, createWorldToken, deleteWorldToken, } from "@wazoo/client"; const { data } = await listWorldTokens({ path: { worldId: "support-knowledge" }, }); const created = await createWorldToken({ path: { worldId: "support-knowledge" }, }); console.log(created.data?.token); // one-time secret await deleteWorldToken({ path: { worldId: "support-knowledge", tokenUid: created.data!.token.uid }, }); ``` ## Usage and limits ```typescript theme={null} import { getWorldUsage, getWorldLimits } from "@wazoo/client"; const usage = await getWorldUsage({ path: { worldId: "support-knowledge" }, }); console.log(usage.data?.usage.total); const limits = await getWorldLimits({ path: { worldId: "support-knowledge" }, }); ``` ## Billing ```typescript theme={null} import { getWorldBilling } from "@wazoo/client"; const billing = await getWorldBilling({ path: { worldId: "support-knowledge" }, }); console.log(billing.data?.billing.state); ``` ## Custom client configuration By default, SDK functions automatically use the built-in client. You can configure global defaults or create isolated custom client instances: ```typescript theme={null} import { client, createClient, listWorlds } from "@wazoo/client"; // Configure default client globally (e.g. set global headers or custom token) client.setConfig({ auth: process.env.CUSTOM_PLATFORM_TOKEN, }); // Or create an isolated client instance for multi-tenant setups const customClient = createClient({ baseUrl: "https://api.wazoo.dev", auth: "wzp_custom_token", }); const { data } = await listWorlds({ client: customClient }); ``` ## Error handling The SDK returns a discriminated union by default: ```typescript theme={null} const r = await listWorlds(); if (r.error) { console.error(r.error.error.code, r.error.error.message); } else { console.log(r.data?.worlds); } ``` Set `throwOnError: true` on the client for exception-based handling. ## Runtime The SDK is a fetch-based ESM package published on JSR. It runs in any modern JavaScript runtime that provides `fetch`: Node.js, Cloudflare Workers, Deno, Bun, and browsers. # Privacy policy Source: https://docs.wazoo.dev/privacy-policy How Wazoo handles personal information, including our COPPA age gate and treatment of users under 13. ## Age gate Wazoo is intended for people aged 13 and older. The Console asks you to confirm that you are at least 13 years old before you create an account. We do not knowingly collect personal information from children under 13. If you are under 13, do not create an account unless a parent or guardian has given verifiable consent. If we learn that we have collected personal information from a child under 13 without verifiable parental consent, we will delete it. ## What we collect * Account information you provide, such as your email address and display name. * Usage and billing data needed to operate the service, including world resources, API tokens, and usage events. * Standard web analytics data from the Console and documentation site. ## How we use information * To operate and secure your account and worlds. * To meter and manage platform usage during the private beta. * To respond to support requests and maintain service quality. ## Sharing We do not sell personal information. We share data only with the service providers required to operate the platform (for example, hosting and database providers) and when required by law. ## Do Not Sell or Share Wazoo does not sell or share your personal information for money or otherwise, and has not done so in the preceding twelve months. You do not need to submit a request to opt out, because there is nothing to opt out of. If this changes in the future, we will update this policy and honor Global Privacy Control signals. ## Your choices You can request deletion of your account and associated data by contacting the team at [wazoo.dev/meet](https://wazoo.dev/meet). See the [Worlds data API](/worlds/query) for tools to export and manage the data in your worlds. ## Contact Questions about this policy or the age gate: [wazoo.dev/meet](https://wazoo.dev/meet). # Projects Source: https://docs.wazoo.dev/projects Open-source projects in the Wazoo ecosystem. Wazoo maintains an ecosystem of independent open-source projects. While **Worlds** powers hosted context infrastructure, these child projects exist as standalone libraries, CLI tools, specs, and adapters. Context infrastructure for agents: graphs, hybrid search, graph pattern queries, and edge storage. CLI for semantic Markdown wikis: validate, query, render, and publish. Spec and parsers for Markdown graph nodes. Backend-agnostic AI memory interface. ## Ecosystem repositories ### Wazoo platform | Project | Repository | Scope & description | | :------------ | :---------------------------------------------------------------- | :-------------------------------------- | | **Wazoo SDK** | [`wazoo-client-ts`](https://github.com/wazootech/wazoo-client-ts) | Primary TypeScript platform SDK | | **Wazoo CLI** | [`wazoo-cli`](https://github.com/wazootech/wazoo-cli) | Command line interface for the platform | | **AI tools** | [`wazoo-tools`](https://github.com/wazootech/wazoo-tools) | Vercel AI SDK tools integration | | **Skills** | [`wazoo-skills`](https://github.com/wazootech/wazoo-skills) | Agent skills for coding agents | ### Worlds | Project | Repository | Scope & description | | :------------------ | :------------------------------------------------------------------ | :---------------------------------- | | **Worlds client** | [`worlds-client-ts`](https://github.com/wazootech/worlds-client-ts) | Graph client & embedded database | | **Worlds adapters** | [`worlds-libsql`](https://github.com/wazootech/worlds-libsql) | Storage adapters for LibSQL / Turso | ### Wiki | Project | Repository | Scope & description | | :----------------- | :------------------------------------------ | :---------------------------------------- | | **Wiki toolchain** | [`wiki`](https://github.com/wazootech/wiki) | Semantic Markdown validator and generator | ### Linked Markdown | Project | Repository | Scope & description | | :------------------------- | :---------------------------------------------------------------------- | :---------------------------------- | | **Linked Markdown** | [`linked-markdown`](https://github.com/wazootech/linked-markdown) | Format spec & conformance suite | | **Linked Markdown TS** | [`linked-markdown-ts`](https://github.com/wazootech/linked-markdown-ts) | TypeScript parser & AST transformer | | **Linked Markdown Python** | [`linked-markdown-py`](https://github.com/wazootech/linked-markdown-py) | Python parser implementation | ### MemSDK | Project | Repository | Scope & description | | :------------------ | :------------------------------------------------------------ | :------------------------------------ | | **MemSDK** | [`memsdk`](https://github.com/wazootech/memsdk) | Portable memory interface | | **MemSDK adapters** | [`memsdk-worlds`](https://github.com/wazootech/memsdk-worlds) | Native MemSDK driver for Wazoo Worlds | # WorldsKit Source: https://docs.wazoo.dev/projects/kit React and UI component kit for building Wazoo Worlds memory experiences. `@worlds/kit` provides UI components, React hooks, and state utilities for embedding Wazoo Worlds context, graph visualization, and memory management into web applications. ## Key features * **React components**: pre-built memory search, fact views, and graph inspectors. * **State hooks**: reactive hooks for loading, querying, and mutating worlds memory. * **TypeScript and React**: designed for modern TypeScript and React stacks. ## Repositories | Repository | Purpose | | :---------------------------------------------------- | :---------------------------------------------------- | | [worlds-kit](https://github.com/wazootech/worlds-kit) | React component kit and frontend SDK for Wazoo Worlds | # Linked Markdown Source: https://docs.wazoo.dev/projects/linked-markdown Linked Markdown structures Markdown documents as semantic graph nodes. Linked Markdown is a specification for Markdown documents with semantic frontmatter. It lets ordinary Markdown pages carry typed JSON-LD-style attributes that can be validated, queried, and loaded into RDF tooling such as Wazoo [Worlds](/worlds/index). ## Example ```md theme={null} --- { "@id": "https://example.org/docs/ethan-davidson", "@type": "schema:Person", "@context": { "schema": "https://schema.org/" }, "schema:givenName": "Ethan", "schema:familyName": "Davidson", } --- # Ethan Davidson Ethan Davidson is a [knowledge graph engineer](./roles/knowledge-graph-engineer.md). ``` ## Markdown to JSON-LD Before: a plain Markdown page with no machine-readable structure. ```md theme={null} # Ethan Davidson Ethan Davidson is a knowledge graph engineer. ``` After: the same content as a Linked Markdown document, where the frontmatter block parses as JSON-LD. ```md theme={null} --- { "@id": "https://example.org/docs/ethan-davidson", "@type": "schema:Person", "@context": { "schema": "https://schema.org/" }, "schema:givenName": "Ethan", "schema:familyName": "Davidson", "schema:jobTitle": "Knowledge graph engineer", } --- # Ethan Davidson Ethan Davidson is a knowledge graph engineer. ``` The frontmatter parses directly into JSON-LD attributes via `extract`: ```json theme={null} { "@id": "https://example.org/docs/ethan-davidson", "@type": "schema:Person", "@context": { "schema": "https://schema.org/" }, "schema:givenName": "Ethan", "schema:familyName": "Davidson", "schema:jobTitle": "Knowledge graph engineer" } ``` ## What it unlocks * Markdown that remains pleasant for humans to write. * Frontmatter that machines can interpret as semantic data. * Compatibility with JSON-LD, RDFLib, and RDF graph workflows. * Shared conformance tests across language implementations. ## Repositories | Repository | Purpose | | --------------------------------------------------------------------- | ---------------------------------------------------------------- | | [linked-markdown](https://github.com/wazootech/linked-markdown) | Specification, paper, conformance suite, and community materials | | [linked-markdown-ts](https://github.com/wazootech/linked-markdown-ts) | TypeScript implementation published on JSR | | [linked-markdown-py](https://github.com/wazootech/linked-markdown-py) | Python implementation published on PyPI | ## Install ```bash npm theme={null} npx jsr add @wazoo/linked-markdown ``` ```bash deno theme={null} deno add jsr:@wazoo/linked-markdown ``` ```bash pnpm theme={null} pnpm dlx jsr add @wazoo/linked-markdown ``` ```bash yarn theme={null} yarn dlx jsr add @wazoo/linked-markdown ``` ```bash bun theme={null} bunx jsr add @wazoo/linked-markdown ``` ```bash python theme={null} pip install linked-markdown ``` ## Parse frontmatter Use `extract` to read semantic attributes from a Markdown document: ```typescript TypeScript theme={null} import { extract } from "@wazoo/linked-markdown"; const result = extract(`--- { "@id": "https://example.org/docs/alice", "@type": "schema:Person" } --- # Alice `); console.log(result.attrs); // { "@id": "https://example.org/docs/alice", "@type": "schema:Person" } ``` ```python Python theme={null} from linked_markdown import extract result = extract("""--- { "@id": "https://example.org/docs/alice", "@type": "schema:Person" } --- # Alice """) print(result.attrs) # {'@id': 'https://example.org/docs/alice', '@type': 'schema:Person'} ``` ## RDF compatibility The `attrs` data returned by `extract()` is valid JSON-LD, ready for loading into RDF graph stores: ```python Python (RDFLib) theme={null} import json import rdflib from linked_markdown import extract result = extract(markdown) graph = rdflib.Graph() graph.parse(data=json.dumps(result.attrs), format="json-ld") ``` ```typescript TypeScript (jsonld) theme={null} import jsonld from "jsonld"; import { extract } from "@wazoo/linked-markdown"; const result = extract(markdown); const quads = await jsonld.toRDF(result.attrs); // quads is an Array of RDF/JS quads, directly loadable into RDF quad stores ``` # MemSDK Source: https://docs.wazoo.dev/projects/memsdk MemSDK is a portable SDK interface for AI memory backends. MemSDK extracts Supermemory's public API surface into a backend-agnostic TypeScript contract. Application code can target one memory interface, then swap adapters without rewriting its memory layer. > "Oh wow that is awesome." > [Dhravya Shah](https://x.com/DhravyaShah/status/2074650939072618968), founder > of Supermemory ## The problem Every AI memory backend ships a different SDK. Moving from Supermemory to Letta to another backend usually means rewriting document add, search, forget, and list workflows even when the product behavior is conceptually the same. ## The approach MemSDK freezes a proven interface instead of inventing a new one. It provides: * `SupermemoryInterface` as a type-level contract. * Zod schemas for runtime request validation. * Adapters that prove the contract can map to real backends. ## Repositories | Repository | Purpose | | ----------------------------------------------------------- | ------------------------------------------------ | | [memsdk](https://github.com/wazootech/memsdk) | Core interface and schemas | | [memsdk-letta](https://github.com/wazootech/memsdk-letta) | Letta-backed implementation | | [memsdk-worlds](https://github.com/wazootech/memsdk-worlds) | [Worlds](/projects/worlds)-backed implementation | | [memsdk-e2e](https://github.com/wazootech/memsdk-e2e) | Private conformance scenarios across backends | ## Installation Both `memsdk` and its adapters are distributed directly from GitHub. They are not currently published to the npm registry. Install the core package with any npm-compatible package manager: ```sh npm theme={null} npm install github:wazootech/memsdk ``` ```sh pnpm theme={null} pnpm add github:wazootech/memsdk ``` ```sh yarn theme={null} yarn add github:wazootech/memsdk ``` ```sh bun theme={null} bun add github:wazootech/memsdk ``` Install a backend adapter (e.g. Letta): ```sh npm theme={null} npm install github:wazootech/memsdk-letta ``` ```sh pnpm theme={null} pnpm add github:wazootech/memsdk-letta ``` ```sh yarn theme={null} yarn add github:wazootech/memsdk-letta ``` ```sh bun theme={null} bun add github:wazootech/memsdk-letta ``` For reproducible installs, pin to a tag or commit: ```sh npm theme={null} npm install github:wazootech/memsdk# ``` ```sh pnpm theme={null} pnpm add github:wazootech/memsdk# ``` ```sh yarn theme={null} yarn add github:wazootech/memsdk# ``` ```sh bun theme={null} bun add github:wazootech/memsdk# ``` Packages build from source during installation via `prepare`, then expose compiled ESM entrypoints and TypeScript declarations from `dist`. ### Runtime support `memsdk` is plain ESM compiled with `tsc`. Zod is the only runtime dependency, and the package declares no `engines` constraint. Runtime support therefore comes down to how the package is resolved, not runtime-specific code: | Runtime | Status | Resolution path | | ------------- | ------------------------- | ------------------------------------------------------------------------------------------------- | | Node.js | Supported | Any npm-compatible package manager (`npm`, `pnpm`, `yarn`) | | Bun | Supported | `bun add github:wazootech/memsdk` | | Vite/browser | Supported through bundler | Package dependency, then import normally from app code | | Edge runtimes | Supported through bundler | Package dependency, bundled by the platform deployer | | Deno | Not first-class yet | Blocked by distribution channel, not the runtime: `npm:` specifiers need an npm-registry artifact | | Browser/CDN | Not first-class yet | Blocked by distribution channel: esm.sh/jsdelivr/unpkg resolve npm packages | Because `memsdk` is primarily a TypeScript contract plus Zod schemas, browser and edge use should go through a bundler today. Direct `