May 13, 2026. Today’s claim is modest but important: a memory system has to be available as a service before it can become dependable infrastructure for agents. VALESKA’s FastAPI surface is moving into Docker Compose alongside PostgreSQL. The API is no longer an arrangement that depends on a particular desktop process being started in the right order. It has a defined image, a published port, a restart policy, and a health check. PostgreSQL must report healthy before the API starts. That does not answer every question about memory quality, but it gives the system an operating shape that can be inspected and restarted.
The working question
Can a local knowledge service remain usable across ordinary interruptions without quietly losing the records it is meant to preserve? The question is about more than containers. A restartable process is valuable only if its dependency chain and stored data are visible. In the previous local arrangement, a Windows event-loop and database-driver incompatibility required a host-side workaround. Moving the API into a Linux container removes that specific operating condition from the API path. The service can reach PostgreSQL over the Compose network, while agents can use the documented HTTP memory contract at the host port.
What the evidence establishes
The Compose change adds a dedicated valeska_api service with restart: unless-stopped, a health request to the API, and an explicit dependency on healthy PostgreSQL. Its connection settings point at the database service rather than host loopback. The database and pgAdmin storage are bind-mounted to host paths. That storage decision matters because records should not exist only inside Docker’s virtual disk; the persistence location is part of the operating model. The Dockerfile supplies the API runtime and its database dependencies, making the same service definition available to a fresh start rather than relying on a remembered sequence of local commands.
The other work recorded today keeps this infrastructure change in proportion. A durable endpoint does not by itself make retrieval useful. The knowledge-layer plan names gaps that remain: context bundles instead of isolated ranked fragments; hierarchical summaries for long documents; governed access to tabular material; graph retrieval; and retrieval requests that state intent, freshness, confidence, and budget. It also distinguishes work already present from work only planned. Governance and provenance structures exist, while several retrieval shapes are still gaps or partial work. That distinction keeps a deployment milestone from becoming a claim that the knowledge layer is finished.
Why the service and the plan belong together
Agents need a stable way to ask for and record knowledge, but stability alone can make an unreliable pattern easier to repeat. The API provides a durable route for capture and retrieval. The plan supplies questions for deciding what that route should return and under which rules. A request that asks only for similar text can omit the governing policy, the relevant history, or the origin of a record. A larger context response can also make a task harder if it includes material with no stated use. The intended direction is therefore appropriate context: selected material with authority, provenance, permissions, and uncertainty available for review.
Next test
The immediate test is operational. Start the Compose service from a clean state, verify the health path and memory contract, then restart it and confirm that stored records remain available through the documented API. In parallel, the next planning test is to turn the retrieval-contract work into a bounded implementation proposal: which request fields the caller supplies, how they constrain selection, and how the response shows its provenance. Until those checks are performed, this is a service foundation and a plan, not evidence that governed retrieval has solved the agent’s context problem.
Historical basis: May 13, 2026 commits 0876323 and a5e3cd9.