06 - Chat Works. Does the Agent Actually Retrieve Memory?

The images in this article are explanatory diagrams with Chinese labels, not screenshots of test results. Each caption summarizes the diagram in English. I wanted to make projects easier to resume across conversations and agents. Before testing whether the next agent could pick up where the previous one stopped, I checked something more basic: could it actively retrieve memory? In the Docker deployment I was investigating, retrieval requests timed out while ordinary conversation continued. That combination was easy to misread. The assistant still answered, and memory content appeared in its context. Neither observation proved that its retrieval tools worked. A successful conversation validates only part of the system Chat and tool execution involve different requests. A working conversation showed that the client could communicate with the gateway. It did not establish that the client's tool execution environment could reach an address supplied inside a tool prompt. The responsibility split matters: the model chooses a tool; the agent client's execution environment sends the request. A sensible tool choice can therefore produce a network failure. Debugging the model's decision alone will not reveal where that request actually went. Figure 1: A simplified architecture diagram, rearranged from an existing Archify diagram. The chat connection and client-executed tool requests need separate checks. Memory in context is not proof of retrieval The proxy has two paths that share configuration and injection machinery but can succeed or fail separately. Passive injection reads memory content or indexes on the server side and includes them in the context. This can include L3 core memory, L2 scenario indexes, persona information, and a skill list. In this deployment, passive injection continued to work. Active retrieval supplies endpoints through tool prompts. The client then requests addresses such as ${base}/memory-bridge/v3 and ${base}/skill-bridge/v3/skill . This depends on the client being able to reach the generated address. That explains how context could contain memory while retrieval failed. The server's read path worked; the URL handed to the client's tool executor did not. The failure was also easy to miss in the conversation. Tool requests timed out or produced no HTTP response, recorded as 000 . The assistant continued with file reads and local searches, without presenting a visible tool error to the user. I did not measure how much this fallback affected answer quality. Figure 2: Passive injection can supply context even when active retrieval fails. A plausible answer is insufficient evidence that the retrieval path succeeded. The missing setting was the injected gateway address Following the failing path led to the URL-generation logic. In the feat/server_team source I checked on September 19, 2026, injection.externalGatewayUrl takes precedence when configured. If it is absent and the configured host is 0.0.0.0 or 127.0.0.1 , the fallback selects the first non-internal IPv4 address and builds an http:// : base URL. It also emits a warning. My Docker deployment had taken that fallback. The selected address belonged to the deployment's container network, while the client's tool execution environment was outside that network. Retrieval requests consequently timed out or received no HTTP response. The missing piece was an existing configuration field. The source already documented explicit configuration for multi-node deployments; this was a deployment mistake, not a newly discovered upstream vulnerability. Two useful starting points are the startup warning and the address actually injected into the tool prompt. Comparing that address with the client's gateway configuration can expose a discrepancy. A discrepancy still needs investigation: different addresses may be intentional, so test from the environment that executes the tool. Interpret the probe before changing configuration Two probe results deserve careful reading: - 401 means an HTTP service responded and requires authentication. It does not demonstrate a successful memory operation, or establish by itself that this is the intended service. - 000 means the probe received no HTTP response. It is not an HTTP status code identifying one cause. Timeouts, DNS resolution, and routing still need examination. For the gateway, the proposed configuration change is straightforward: injection: externalGatewayUrl: "https://gateway.example.com" The domain above is a placeholder. The real entry point must be reachable from the tool execution environment, and the reverse proxy must forward the relevant bridge paths. The source handles a trailing slash; reachability and routing are the consequential checks. I also need to change the persistent configuration source. Editing a file regenerated by a startup script would make the correction disappear on the next run. Knowledge resources have their own URLs Another failure in the same investigation had a separate cause. Tools for resources such as a wiki or code graph use URLs stored when those resources are registered. The injector copies those resource URLs. Changing externalGatewayUrl does not update independently registered knowledge-resource addresses. Each one needs its own check. The example in my notes used host.docker.internal . That name is a Docker Desktop convention; in a Linux environment without corresponding configuration, it may not resolve. The useful question is whether the name resolves and connects from this particular tool execution environment. These failures pointed to injected addresses and name resolution. They did not establish that memory storage was damaged. Figure 3: Memory and skill bridge addresses use the gateway base URL. Knowledge tools use their individually registered resource URLs. Fixing one source does not fix the other. The verification I still need to finish I have the diagnosis and a proposed correction. The post-fix checks are still pending. My next steps are: - Probe from the actual tool execution environment. Confirm that the injected address is reachable and routes to the intended gateway. - Update persistent configuration and start a fresh conversation. Inspect the newly injected tool addresses and confirm they no longer come from the unwanted fallback. - Make an authorized memory-tool request. Verify application-level success and content from the expected source, rather than inferring success from a later answer assembled through local search. - Test each registered knowledge-resource URL independently. Check resolution and connectivity, then retrieve an expected item and confirm its source. Figure 4: My planned post-fix verification checklist. These steps have not yet been completed. Only after those checks will I evaluate recall quality and cross-agent handoffs. Otherwise, I could spend time judging “memory” while the assistant is quietly using a different source. First I need to establish that retrieval actually happened. References - Injection address generation in TencentDB-Agent-Memory - Configuration example, including externalGatewayUrl My blog: Aiclaw - AI learning notes. Top comments (0)