Platform capabilities
What is implemented across Loams, from retrieval and durable execution to SDKs, graphs, analytics, agents and native applications.
Loams is an open-source platform for AI applications, built around your data in your bucket. The repository contains much more than the retrieval engine: reactive transactions, durable execution, native RPCs, thirteen language runtimes, graph and analytics services, SQL and WAL infrastructure, engine authentication, browser tools, plugins and native applications.
This inventory was checked against the full loams checkout at ce9e6811 on 2026-10-12. “Implemented” describes the named component in the code on dev; “Released” means it ships in Loams 0.1.0, the first release (2026-10-18), as container images and packages you run yourself. Production readiness and complete platform integration are separate milestones.
Retrieval and data
| Component | Implemented scope | Next scope |
|---|---|---|
| Retrieval engine | Lance and Tantivy collections; dense, sparse and BM25 retrieval; filters; RRF, DBSF and weighted fusion; strong/token-aware reads | Broader framework and retrieval-quality exit gates |
| Storage and compute | Object-store WAL, exactly-once links, manifest commits, GC, HNSW hot tiers, RAM/NVMe cache, maintenance, cluster routing and backpressure | Expanded stream contracts and larger-scale metadata/WAL |
| Native APIs | REST, including stream and link listings, link lag and CloudEvents ingest; Flight SQL/DoPut; Connect, gRPC and gRPC-Web instance, namespace, collection, document and typed hybrid Search services | Remaining SQL and stream RPC migration; new-service SDK facade generation |
| Engine authentication | LOAMS_AUTH_MODE: hashed API keys (loams auth new-key), OIDC JWTs checked against the issuer's JWKS, Tailscale identity on a dedicated loopback listener, or off (loopback only, the default) | Roles, per-namespace authorization and tenancy |
| Compatibility | Qdrant REST/gRPC and Elasticsearch 8 Phase A subset | Broader compatibility gates; no full upstream feature-parity claim |
| Loams Live | In the default build: transactions, documents, indexes, commit journal, subscriptions, sessions, function deployments with rollback and a dedicated sync service, on an embedded store or TiKV (live-tikv) | Faster cross-node pickup (up to 60 s today), tenancy, restore and retrieval bridge |
| Loams Durable | Embedded Resonate behind the durable feature, in-process Rust runtime, SQLite store; MySQL/TiDB (legacy) and native TiKV stores behind their own features | TiKV store for clusters, per-namespace integration, operations and managed agents |
Metadata uses embedded Raft or optional TiKV. Live defaults to its embedded store under <data-dir>/live/. Durable state uses its configured execution store. Retrieval data lives in object storage; compute caches are rebuildable.
Fabric, analytics, graphs and SQL
| Component | What exists in the repo | Integration boundary |
|---|---|---|
| Loams Flow | 204 connector manifests and schemas, including 21 priority connectors; registry, capability validation and license gates | A catalog entry is a declared contract, not a working adapter; connectors are not in Loams 0.1.0 |
| Loams House | chDB bindings and the loams-fabric House front: a sandboxed worker pool, the ClickHouse HTTP interface, sessions, a statement deny list and loams.house.v1, which the engine's main port proxies with --house-endpoint | Not yet wired to the engine by default; multi-block results in header/footer formats over the ClickHouse HTTP interface await a fix |
| Loams Graph | Embedded Grafeo engine, graph catalog and admin service, GQL execution, statement limits, streaming results; writes reach the Loams log before they are acknowledged. Served as loams.graph.v1 on the native port with the graph feature | Crash recovery is not done; retrieval-plan GraphRAG expansion is a different future feature |
| Loams SQL | MySQL-compatible SQL on a patched TiDB (v8.5.8-loams.1) over TiKV, and the SQL gate (sqldb feature, --sqlgate-listen) with TLS, auth and session migration | Lifecycle and console pages are still being integrated |
| SQL wire reads | Optional read-only Postgres and MySQL listeners over collections | MySQL rejects writes/prepared statements; this is not a full OLTP database |
| Loams Postgres and Neon WAL | A Neon fork with storage on the bucket; the loams pg-control control plane (postgres feature: projects, branches, roles, reconcilers, Neon upcalls); acceptor, fenced TiKV stores, NVMe journal, loams-wal with an in-process interpreted sender and broker publication | Computes and endpoints are not yet provisioned through the control plane |
| Router tooling | Shard-map kernel, key ranges, hashing, TLA+ checks, Lean partition proofs, oracle, compatibility replay and spec/test viewer | Verified components do not imply verification of the entire distributed platform |
Agents, browsers and applications
The plugin workspace implements a Cordis host, persisted enable/disable, real route teardown, scope checks, agent bus, A2A-style message endpoint, stdio MCP tooling and collaboration/observability adapters. Core plugins are named @loams-core/*. The A2A binding documents its protocol deviations. This plugin MCP surface is separate from the planned engine-native retrieval MCP server.
Browser components include local and Cloudflare Browser Run providers, an Obscura-based docked browser with isolated profiles, and optional WebM/MP4 recording. Remote execution needs provider credentials. The recorder's real-Obscura playback and browser fidelity have explicit validation limits.
The console has a WebMCP action registry with manifest declarations, permission/risk checks and destructive-action approval gates. Tools are exposed only when the browser supports the API; the new registry's stdio consumer is not wired yet. Several console pages, including Jobs, Connectors, SQL, the Postgres control plane and Live deployments, still run on mocked clients.
Loams Desktop is an Electron application (apps/desktop-electron) that replaces the earlier GPUI desktop. It connects to any server, supervises a local loams dev engine with Data Studio, runs local Loams Postgres and Loams SQL stacks through Podman or Docker, embeds Software Factory apps and provides an agent panel that asks for approval before every write. Its headless daemon, loams-agentd, serves sessions, harnesses and an MCP shim (run, mcp, status, version). Android Kotlin/Compose and iOS SwiftUI apps are mock-first; real-server identity and app-store releases remain separate. loams-apps-mock serves console REST, app RPCs, mock pairing/OAuth and optional console assets on port 8084. These are working development surfaces; the website console contains preview data.
SDKs and shipping
Thirteen SDK runtimes are implemented: TypeScript, Python, Go, Rust, Swift, Kotlin, Java, C#, Dart, Ruby, PHP, C++ and Objective-C. The required-fixture runner marks every language command verified. Shared fixtures cover idempotency, consistency tokens, errors and pagination. This is runtime evidence, not a claim that every future server service exists or every registry package is published.
Loams 0.1.0 is a self-hosted stack: deploy/release/compose.yaml runs PD, TiKV, the patched TiDB, the engine, the House front, the Postgres stack and a Tailscale sidecar, locally or on your own VM over SSH, with a hosted console at console.loams.dev. Its container images (loams, loams-fabric and the optional loams-agentd) are on ghcr.io/ostrium-labs. Release engineering also includes Debian, RPM and Arch packages, a Windows zip, Electron desktop packages, service units, self-tests, signing workflows and repository-generation tooling. Linux packages, macOS tarballs and the Windows zip ship with the release; macOS builds are ad-hoc signed and Windows builds are unsigned.
Functions, Jobs, Loams Git, SystemOne, the complete BYOC/GitOps control plane and managed Loams Cloud remain future services. Their implemented prerequisites deserve credit without treating the full service as delivered.
Start with the quickstart, explore the API reference, or see the full roadmap. The engine source preserves the evidence behind this inventory.