Developer model
Integrate authorized context, preserve source lineage, and retrieve qualified memory for the next task. The current product is a managed, isolated beta service—not a generally available multi-tenant API.
Integration sequence
The implemented system separates ingestion, private source contribution, canonical memory, and published retrieval. That separation makes source replacement, correction, and deletion tractable.
The current service accepts participant-authorized Hermes history, explicit captures, text, files, and supported public URLs inside one isolated deployment. Broader calendar, CRM, support, email, and product-usage connectors are deployment-dependent beta inputs, not generally available promises.
A successful reprocessing generation replaces that source’s earlier active contribution instead of appending an unbounded duplicate. Incomplete staging work is not published.
Search and read surfaces return published memory and citations. The deeper people-memory interface is being shaped with partners; the example below describes the intended contract, not a released public SDK.
Your agent decides how to use returned context within its own permissions. Substrate memory does not grant permission to message someone, change a record, or commit resources.
Illustrative contract
A future-facing integration can name the subject, agent, scope, and task, then receive qualified context with citations and state. The exact route, field names, enums, and response shape below are not a public API promise.
POST /illustrative/v1/memory/search
Authorization: Bearer ••••••••
{
"subject": "maya-chen",
"agent": "customer-success",
"scope": "northstar-account",
"task": "prepare executive review",
"include": ["current", "conflicting", "provenance"]
}200 OK
{
"status": "qualified",
"memories": [
{
"statement": "Adoption replaced seats as the renewal measure.",
"state": "current",
"confidence": "supported",
"citations": [{ "source": "capture-184", "observed_at": "2026-06-18" }]
}
],
"authority": "context_only"
}Data model
The system’s useful retrieval surfaces are intentionally narrower than its private evidence and quality-control state.
Searchable pages and memory cards are derived views. They are not the authoritative store for identity, source lineage, conflict, or correction state.
Source contributions and detailed provenance remain in the private ledger. Routine retrieval is designed to expose bounded citations rather than raw internal workflow state.
Reprocessing can supersede a prior source generation. Corrections and source replacement are modeled explicitly so a stale extraction does not have to remain the active truth.
The current beta topology is not a shared team workspace. Each environment belongs to one invited participant acting for one defined organizational unit.
Closed-beta expectations
Early partners should expect explicit source selection, synthetic and isolated acceptance checks, active correction, and contract changes as the public developer surface is validated.
One clear agent workflow, authorized source categories, and a person who can inspect whether the resulting memory is useful and correctly scoped.
A managed deployment, evolving interfaces, bounded diagnostics, explicit failure states, and support involvement during ingestion and quality review.
General availability, shared multi-user tenancy, every connector, fixed quotas, autonomous external action, or a final compatibility policy.
Build with the current boundary
We are looking for partners who can provide authorized context and evaluate the memory—not just the generated answer—with us.