MindForge keeps its memory engine running between requests
MindForge’s new release adds a background service that keeps its local memory engine running between requests from an application. The change avoids starting a separate process for each memory operation. Applications exchange structured messages with the same service to add, retrieve and compress memories. Version 6.4.0, released on November 8, also adds automated checks for the service and engine.
Artificial Intelligence··Midday
The memory engine stays in one process
MindForge, an open-source local memory system for artificial intelligence agents, added a resident background service in version 6.4.0 on November 8. The memory engine stays in a long-lived process between application requests. This changes the route used to reach it: an application can use the same running service instead of starting Python again for each command-line call. The release introduces the service as a new feature, while retaining the existing command-line interface.[1], [2]
Structured messages separate results from logs
Applications send one request per line using JSON, a structured data format. Each request identifies itself and supplies a command and its arguments. The service responds with the same identifier, a success indicator and result data or an error. Standard output carries only responses; logs use a separate error channel. Operations include adding, searching and recalling memories, preparing context and compressing stored material. Response fields match the command-line tool’s existing JSON output.[1]
Request failures leave the service running
A health check returns the process identifier and uptime. The service supports an orderly shutdown command and exits when its input stream ends, while an error affecting one request leaves the process running. The release also adds automated engine-latency checks to the development workflow. A separate end-to-end check starts a real subprocess and exercises connection, memory retrieval and compression. These checks accompany the new service’s communication and lifecycle behaviour.[1]
