13 de mayo de 2026. La afirmación de hoy es modesta pero importante: un sistema de memoria tiene que estar disponible como servicio antes de poder convertirse en una infraestructura fiable para agentes. La superficie FastAPI de VALESKA pasa a Docker Compose junto con PostgreSQL. La API deja de ser una disposición que depende de que un proceso concreto de escritorio se inicie en el orden correcto. Tiene una imagen definida, un puerto publicado, una política de reinicio y una comprobación de salud. PostgreSQL debe informar que está saludable antes de que inicie la API. Eso no responde todas las preguntas sobre la calidad de la memoria, pero da al sistema una forma operativa que puede inspeccionarse y reiniciarse.
La pregunta de trabajo
¿Puede un servicio local de conocimiento seguir siendo utilizable durante interrupciones ordinarias sin perder silenciosamente los registros que debe preservar? La pregunta trata de algo más que contenedores. Un proceso reiniciable solo tiene valor si su cadena de dependencias y sus datos almacenados son visibles. En la disposición local anterior, una incompatibilidad entre el bucle de eventos de Windows y el controlador de base de datos exigía una solución alternativa en el host. Mover la API a un contenedor Linux elimina esa condición operativa específica de la ruta de la API. El servicio puede alcanzar PostgreSQL por la red de Compose, mientras los agentes usan el contrato HTTP de memoria documentado en el puerto del host.
Lo que establece la evidencia
El cambio de Compose añade un servicio dedicado valeska_api con restart: unless-stopped, una solicitud de salud a la API y una dependencia explícita de PostgreSQL saludable. Sus ajustes de conexión apuntan al servicio de base de datos en lugar del bucle local del host. El almacenamiento de la base de datos y de pgAdmin está montado en rutas del host. Esa decisión de almacenamiento importa porque los registros no deben existir solo dentro del disco virtual de Docker; la ubicación de persistencia forma parte del modelo operativo. El Dockerfile proporciona el entorno de ejecución de la API y sus dependencias de base de datos, haciendo disponible la misma definición de servicio para un inicio nuevo en lugar de depender de una secuencia recordada de comandos locales.
El otro trabajo registrado hoy mantiene este cambio de infraestructura en proporción. Un punto final duradero no hace útil la recuperación por sí solo. El plan de capa de conocimiento enumera vacíos pendientes: paquetes de contexto en vez de fragmentos aislados ordenados; resúmenes jerárquicos para documentos largos; acceso gobernado a material tabular; recuperación de grafos; y solicitudes de recuperación que indiquen intención, actualidad, confianza y presupuesto. También distingue el trabajo ya presente del que solo está planificado. Existen estructuras de gobernanza y procedencia, mientras varias formas de recuperación siguen siendo vacíos o trabajo parcial. Esa distinción evita que un hito de despliegue se convierta en la afirmación de que la capa de conocimiento está terminada.
Por qué el servicio y el plan van juntos
Los agentes necesitan una forma estable de pedir y registrar conocimiento, pero la estabilidad por sí sola puede hacer más fácil repetir un patrón poco fiable. La API ofrece una ruta duradera para captura y recuperación. El plan plantea preguntas para decidir qué debe devolver esa ruta y bajo qué reglas. Una solicitud que solo pide texto similar puede omitir la política rectora, el historial pertinente o el origen de un registro. Una respuesta con un contexto mayor también puede dificultar una tarea si incluye material sin uso declarado. La dirección prevista es, por tanto, el contexto apropiado: material seleccionado con autoridad, procedencia, permisos e incertidumbre disponibles para revisión.
Siguiente prueba
La prueba inmediata es operativa. Iniciar el servicio Compose desde un estado limpio, verificar la ruta de salud y el contrato de memoria, luego reiniciarlo y confirmar que los registros almacenados siguen disponibles mediante la API documentada. En paralelo, la siguiente prueba de planificación consiste en convertir el trabajo de contrato de recuperación en una propuesta de implementación acotada: qué campos suministra quien llama, cómo limitan la selección y cómo la respuesta muestra su procedencia. Hasta que se realicen esas comprobaciones, esto es una base de servicio y un plan, no evidencia de que la recuperación gobernada haya resuelto el problema de contexto del agente.
Base histórica: commits del 13 de mayo de 2026 0876323 y a5e3cd9.