feat(sdk): ship the integration layer, so memory is automatic instead of remembered

[rrader26]

What this is

This SDK has 14 resources and ~40 memory methods. It is a very complete API client and it has no integration layer at all — no OpenAI/Anthropic/AI-SDK wrapper, no per-turn hook. The examples are demos, not integrations.

So every customer writes the same forty lines of glue: pull a query out of the conversation, call search, decide how much fits, prepend a system message, remember to write the turn back. Memory quality then varies with how well each of them wrote it — and the most common version of those forty lines is none, which is how a real deployment reaches 182k memories against 98 subjects.

Handing the hard part to the caller is what makes memory a feature people have to remember to use, rather than something that works.

const openai = withMemory(new OpenAI(), mm, { subject, sessionId })

Every existing call site is unchanged and now retrieves relevant memory, injects it within a token budget, runs, and writes the turn back.

Coverage

Client	How
OpenAI	withOpenAI / withMemory — context as a system message
Anthropic	withAnthropic — context on system, since {role:'system'} in messages is rejected by that API
Vercel AI SDK	memoryMiddleware() for wrapLanguageModel
Anything else	MemoryMiddleware — the provider-agnostic core

Client detection is structural, not instanceof. Depending on three provider packages in order to support three provider packages is how an integration layer becomes unusable to everyone on the fourth. No new dependencies.

It cannot break the host's turn

Every memory call is wrapped. An outage, timeout, 5xx or malformed response degrades to "no context this turn" and the model runs exactly as it would have. Failures surface through onError, never as a throw on the caller's request path.

That's the contract, not defensive coding — the moment adding memory can take an app down, nobody leaves it switched on.

Two things it deliberately does not pretend to do

• Injected context lands after the caller's own system prompt. Their system prompt is their product; memory is context, not policy. A memory block above it reads to the model as the higher-priority instruction.
• Streaming captures only the user half. The assistant text doesn't exist when the call returns, and consuming the stream to get it would break the caller's. The README says so and shows the tee, rather than appearing to work.

The proxy, and why every function is bound

Provider SDKs use real #private class fields. Those are keyed to the instance, so a method invoked with this set to a proxy throws TypeError: Cannot read private member — and the natural implementation (return methods unbound, or pass the proxy as the Reflect.get receiver) does exactly that, while typechecking perfectly.

There's a test for it against a fake client with a real #private field.

Also here

• context.forConversation() — client for the new POST /memory/context. The subject-keyed build() needs you to know who before you can ask what we know; this answers "what should the model know before it replies to this".
• admin.merge(), dry-run by default — the measurement that gates whether cluster merging is safe to enable server-side.
• Two docstrings corrected because they made false claims:
  • memory.delete was "Delete one of your own memory items". It is project-scoped: your API key can delete any memory in its project. Right for a backend, wrong behind an end user's "forget this" button.
  • subject was "not needed with text (the engine resolves subjects during extraction)". It did not.

⚠️ Do not publish ahead of the server

Requires POST /memory/context and POST /admin/memory/merge — ThinkfleetAI/memory-thinkfleet#410 and #409.

Tests

11 integration checks via npm run test:integrations — injection, capture of both halves, system-prompt ordering, the private-field trap, and the failure contract in both phases. Runs against fake clients, so no network or key needed.

Version 0.9.0 → 0.10.0: new public surface, nothing removed.