Spec-19-Adapter-ABI
What this page is
Rendered compatibility entry point for
Spec-19-Adapter-ABI.
Minimum contract for platform adapters: env vars, assert/query,
source binding.
Authoritative source:
spec/stigmem-spec-v0.9.0a1.md
Each subsection below shows the most recent normative text from the spec source.
pre-reset status.
Promoted from the pre-reset design work reserved section to normative
spec, grounded in the three pre-reset adapters shipped: MCP
(stigmem/adapters/mcp/), Paperclip
(stigmem/adapters/paperclip/), and OpenClaw
(stigmem/adapters/openclaw/).
§12.1 Adapter archetypes
The ABI recognizes two adapter archetypes with different startup failure contracts.
server.tshook.sh · OpenClaw adapter.py§12.2 Required environment variables
All adapters MUST honor the following environment variables.
STIGMEM_API_KEYauth=required.STIGMEM_SOURCE_ENTITYsource on all write operations. Adapters SHOULD default to a descriptive identity; "agent:unknown" is an acceptable last-resort fallback.Process-mode adapters: MUST exit with a non-zero status code and
a clear error message to stderr if STIGMEM_URL is absent.
Middleware adapters: MUST silently skip all Stigmem operations if
STIGMEM_URL is absent. MUST NOT modify the agent process exit code.
§12.3 Boot handshake protocol
The boot handshake runs once when the adapter initializes. It has two phases: a node probe and (for middleware adapters) a context pull.
§12.3.1 Node probe
Adapters SHOULD issue GET /.well-known/stigmem to verify node
reachability on startup.
Expected response shape:
{
"version": "0.8",
"node_id": "<URI>",
"node_url": "<string>",
"auth": "none" | "required",
"federation": "disabled" | "enabled"
}
Required fields: version, node_id, node_url, auth,
federation.
If the probe fails or required fields are absent:
StigmemError rather than killing the process.BootContext. MUST NOT crash or alter the agent's exit code.§12.3.2 Context pull (middleware adapters only)
After a successful node probe, middleware adapters that inject context into the agent system prompt MUST issue the following queries in order. All queries are non-fatal: a failed or empty response on any individual query MUST NOT abort the boot sequence.
- User entity facts.
GET /v1/facts?entity={user_entity}&scope=company&min_confidence=0.7. Adapters SHOULD filter the result to relevant relation namespaces (e.g.preference:). - Project constraints. One query per project entity; skip if no project entities configured:
GET /v1/facts?entity={project_entity}&relation=roadmap:constraint&scope=company&min_confidence=0.7. - Pending handoffs targeting this adapter.
GET /v1/facts?relation=intent:handoff_to&scope=company&min_confidence=0.8. Filter client-side to facts wherevalue.v == STIGMEM_SOURCE_ENTITY. - Recent escalations.
GET /v1/facts?relation=intent:escalation&scope=company&min_confidence=0.8&limit=10.
§12.3.3 BootContext shape
BootContext {
facts: Fact[] // all successfully retrieved facts; empty list if node unreachable
summary: string // markdown-formatted context for system prompt injection (see §12.5)
}
BootContext is always returned, even on total failure. A failed
boot returns BootContext { facts: [], summary: "" }.