Skip to content

v1.14.3-ce — Persistent agent memory (CREATE MEMORY)

Released: 2026-08-18 · Tag: v1.14.3-ce · Docker: synapcores/community:v1.14.3-ce

Persistent agent memory as first-class SQL, plus a repair to cloud LLM providers that made provider = "anthropic" usable from SQL for the first time.

CREATE MEMORY — persistent multi-turn agent memory

Agents forget between turns unless you build the plumbing yourself. This release makes memory a database object.

CREATE MEMORY assistant IDENTITY user_id;

REMEMBER assistant FOR user_id = 42 'I prefer dark mode and oat milk';
RECALL   assistant FOR user_id = 42 ABOUT 'what are their preferences?';
CURRENT  assistant FOR user_id = 42 ATTRIBUTE theme;      -- 'dark'
TRACE    assistant FOR user_id = 42 ATTRIBUTE theme;      -- why we believe it
FORGET   assistant FOR user_id = 42 ABOUT 'oat milk';

Seventeen statements in total, covering writes (REMEMBER), assembled reads (RECALL), point lookups (CURRENT), lineage (HISTORY, TRACE), removal (FORGET), search, relations, and maintenance (CONSOLIDATE).

What makes it a database feature rather than a table convention:

  • Identity-scoped and tenant-isolated. Memories belong to an identity you name; a caller cannot read across identities.
  • An authority hierarchy. When two statements conflict, resolution is defined — system_of_record outranks a verified user statement, which outranks an inference. TRACE shows which source won and why.
  • Confidence is not relevance. Evidence strength and retrieval score are separate fields, so a strongly-held fact that is off-topic does not masquerade as a good match.
  • Consolidation runs in the engine. No prompt, no tool call, no callback — correctness does not depend on the application remembering to ask.

Available to every agent in the engine, over the REST API, and to external agents (OpenClaw, MCP).

Cloud LLM providers now work for SQL

Reported by an operator: setting [query.ai_service] provider = "anthropic" logged Unknown AI provider and GENERATE() returned an empty string.

The providers were implemented — but only half-wired. The engine has two provider dispatchers: one for the /v1/ai/* REST endpoints, one for every SQL AI function. Only the REST one knew about anthropic and gemini, so SQL fell through to a stub. Both now delegate to a single shared builder, so they cannot drift apart again.

Three further defects surfaced only when calling the real API:

  • every Anthropic model ID the engine shipped had been retired — including the default, the health check, and the vision default (all would 404)
  • the engine sent a sampling parameter current models reject (HTTP 400)
  • the response parser predated thinking blocks, so valid answers were discarded
[query.ai_service]
provider        = "anthropic"
model           = "claude-opus-5"
embedding_model = "all-minilm"   # Anthropic has no embeddings endpoint;
                                  # EMBED() routes to the bundled local model

Also in this release

  • REMEMBER never initialised the AI service, so memories written before the first EMBED/GENERATE kept a NULL embedding and semantic recall silently degraded to insertion order. Fixed, and the consolidator now re-embeds any row left un-embedded by a transient outage.
  • Interactive logins are pinned to an identity, enabling credential-scoped memory access without the caller supplying an identity.

Validation

Gate Result
Feature validator (published artifact) 200 / 200
Recipe certification (pristine data dir) 162 / 162
Non-AVX-512 canary (i5-10400F) boot + EMBED + GENERATE, 0 SIGILL
Live cloud provider GENERATE / EMBED / RECALL end to end
Unit 133 memory · 11 routing · 7 provider

Upgrading

Drop-in. No migration, no schema change. Existing agents and recipes are unaffected; CREATE MEMORY objects are created on demand.