status
Roadmap without theatre
sempods is early. The useful thing is not a list of dates; it is a clear distinction between what runs today, what is being opened next, and what the model needs in order to become broadly useful.
Running today
- public pods serving real event data as JSON-LD
- Kotlin reference implementation
- Linked Data CRUD over HTTP
- SPARQL endpoint with server-enforced context sandboxing
- OAuth-based authorization with context-scoped grants
- pod MCP endpoint at
/_system/mcp - preview apps that connect to pods by URL
- hosted test pods available on request
- JVM artifacts published for people who want to build against it
Opening next
sempods-spec, the dedicated specification repository- an OpenAPI contract for the public pod surface
- a public TypeScript SDK
- search and optional vector retrieval adapters behind
find - simpler examples that do not require starting with the server internals
- better try-it-out paths from the website
Model work
The concrete technical work now is graph retrieval: find as the semantic entry point, structural traversal through Linked Data, and MCP tools that expose the same pattern to agents.
SHACL shapes and a TBox model are still design work, not final specification. They may become the place where apps describe expected shapes and shared semantics, but the public contract should not pretend that is settled.
Permission work is in the same category: contexts are the working boundary today, while alignment with ACP-style and finer-grained authorization remains under active design.
Agent layer
AI agents are clients of the pod model. The direction here is graph retrieval, MCP, local or personal memory contexts, and provider-independent reasoning over the relevant slice of knowledge.
The principle should stay simple: the agent sees what its token allows. No special permission model, no hidden path around the pod.
Ecosystem
The long-term goal is not one hosted sempods platform. It is an open, decentralized and federated knowledge web where multiple implementations and products can interoperate.
If independent teams adopt the same open model for their own knowledge-management problems, the personal data vision becomes more realistic, not less.