Overview

MemoryProxy lets ordinary OpenAI-compatible and Anthropic clients use TencentDB Agent Memory without adopting a new memory protocol. It authenticates callers, normalizes session identity, binds Team–Agent–Task context, injects permitted assets, forwards the familiar request, and writes useful responses back. Client-specific adapters separate main turns from compaction and other auxiliary requests; streaming taps preserve delivery while capturing output. Transparency preserves wire shape, not guaranteed context or persistence.

Learning outcomes

MemoryProxy preserves the client’s familiar protocol while adding authentication, session binding, context injection, and write-back.
Session parsing is a correctness boundary: missing or misread identifiers can bypass memory or recover the wrong binding, even when Core data exists.
Auxiliary-request classification and streaming response taps protect data quality and responsiveness, but optional context or persistence can still fail without blocking a successful upstream answer.

Keywords

MemoryProxyProtocolsSessionsAdaptersStreamingWriteback

The Transparent Proxy: One Turn In, One Turn Out

MemoryProxy is the part of TencentDB Agent Memory that makes the rest of the system usable by an ordinary coding Agent client. The specific problem is not how to forward an HTTP request; it is how to add identity, session binding, remembered context, and write-back without breaking the protocol the client and upstream model already expect. Tracing one main turn and one auxiliary turn makes the boundary clear: the Proxy is transparent in format, but active in lifecycle management.

A client can continue to speak OpenAI Chat Completions or Anthropic Messages. The Proxy receives that request, works out who is calling and which memory instance is in scope, prepares the session’s allowed context, and forwards the request to the upstream LLM. When the response returns, it records the useful parts of the interaction and may trigger later Skill extraction. The model sees a modified context; the client still sees the protocol it knows.

The main request is a lifecycle, not a relay

The first step is authentication. The Proxy reads the caller’s bearer credential and, when the route carries a memory instance identifier, uses that identifier to route the request to the appropriate Core tenant. This is more than an early security check. The resolved user identity becomes part of the internal key used for session state, asset lookup, logging, and later write-back. Two users can send the same client-generated conversation identifier without being treated as one shared session.

The next step is session identity. Different clients put their session identifier in different headers or body fields. Claude Code normally supplies an automatically generated session ID; CodeBuddy uses a conversation header; OpenClaw and Hermes rely on a configured conversation header. The Proxy normalizes these inputs into a session key. If the client’s identifier is absent or the adapter does not recognize it, the Proxy may fall back to a less precise key or bypass the memory flow. That is why session parsing is a correctness boundary: the wrong key can make an initialization state appear to belong to another conversation or make every request look like a new one.

A new interactive session is then registered to a Team, an Agent, and optionally a Task. The interactive path uses the client’s native question tool. Claude Code’s path uses Anthropic’s AskUserQuestion; CodeBuddy’s uses ask_followup_question. The Proxy stores the result so subsequent turns do not repeat the form. Clients without a form interface can use header preselection instead, supplying the identity directly. In the current documented behavior, header-only clients such as OpenClaw need the relevant team, Agent, task, and conversation headers; if the required identity is missing, the session can be bypassed rather than silently guessed.

This interaction is not just onboarding decoration. The selected Team and Agent determine the namespace from which memory and assets can be resolved, while the Task can narrow the working context. Once the session is registered, the Proxy can append a labeled session context containing the Agent’s description or prompt and the Task’s details. This makes the model aware of the role it is operating under without confusing that role description with a recalled historical fact.

Published by DeepMox

FAQ

How does MemoryProxy preserve compatibility across Agent clients?

It parses each client’s request into a common context, injects memory at the correct protocol location, and serializes the result back into the original wire shape. Client-specific fields and question-tool differences still require adapter handling.

Why must a proxy distinguish auxiliary requests from main turns?

It must distinguish them because compaction, title generation, forks, and internal calls can contain scaffolding rather than durable user work. Recognized auxiliary requests bypass session setup, injection, capture, and Skill extraction.

What happens to memory capture during streaming responses?

During streaming, MemoryProxy passes response bytes through immediately while a tap collects assistant text, tool fragments, and usage for write-back when the stream closes. Tracked retries and bounded shutdown waiting reduce, but do not eliminate, persistence loss.

Previous8 minTencentDB Agent Memory: Scoped Retrieval

Next10 minTencentDB Agent Memory: Diagnose Missing Context

TencentDB Agent Memory: Proxy Request Lifecycle

The Transparent Proxy: One Turn In, One Turn Out

The main request is a lifecycle, not a relay

FAQ