Skip to main content
Run ReMe as a shared service when multiple agents or applications should use the same workspace without owning ReMe in process. The service owns persistence, indexing, scheduled consolidation, and the configured jobs.

Choose an Interface

MCP, CLI, and HTTP reach the same ReMe workspace and jobs. Choose the boundary your host already supports: MCP and HTTP are service protocols. The CLI is a client for the running service and is usually the simplest boundary for shell-capable agents.

Service Lifecycle

Keep one runtime owner for a workspace. Start one shared service and let every client connect to it; do not run a second in-process ReMe application against the same workspace. The service owns background indexing and scheduled consolidation. The host still owns session hooks, stable session identifiers, and decisions about when to recall or record memory.

MCP

Start ReMe with an MCP backend:
The default endpoint is http://127.0.0.1:2333/mcp. Add this URL to the MCP client, which discovers the tools exposed by the installed ReMe version. Keep the client and server ports aligned. MCP lets the model select tools. Automatic session recording still belongs in the host’s hooks or lifecycle.

CLI

Start the service, then use ordinary reme <action> commands as its command client:
The CLI detects the running service configuration, including an MCP backend. Use reme find_reme and reme health_check before debugging client behavior.

HTTP

The default launch mode exposes an HTTP service:
Each served job maps to POST /{action} with a JSON body:
Use /docs or /openapi.json on the running service for schemas that match the installed version. Avoid copying a fixed parameter table into client code.

Next Step

After choosing and starting a service interface, see the service-based agent integration guide for tool, plugin, and Skill patterns.