Tu petición al agente atraviesa doce contenedores. Solo uno ejecuta un modelo.

La reacción más común ante nuestro quickstart es que doce contenedores son muchos para una demo. Es una reacción justa, y la respuesta honesta no es defender el número, sino recorrer una ejecución completa servicio por servicio y decir de qué responde cada contenedor y qué garantía se pierde al borrarlo. Un artículo anterior respondía hasta cuántos servicios se pueden recortar. Este responde por qué están los demás.

Primero conviene corregir la cifra, porque se discuten dos números distintos. El comando del quickstart nombra doce servicios; el fichero compose define catorce. En realidad arrancan trece: minio-init no está en el comando, pero api depende de que termine correctamente, así que se levanta, crea el bucket, desactiva el acceso anónimo y sale. El decimocuarto es scheduler, del que no depende ningún servicio y que por tanto el quickstart nunca arranca. Cuántos servicios define un compose y cuántos ejecutas de verdad son dos números diferentes.

Tres contenedores son tareas de una sola vez que terminan antes de que llegue tu primera petición: migrate crea las tablas, bootstrap crea el administrador y el tenant, y minio-init prepara el bucket. Cuestan tiempo de arranque, no huella permanente. Otros dos son sencillamente lo que se está demostrando: api y web. Todo lo demás es el libro de ejecución y las fronteras que lo rodean.

Postgres es ese libro. Una ejecución queda registrada en cinco tablas que cubren la propia ejecución, sus pasos, sus llamadas a herramientas, sus artefactos y su coste. Esa es la base física de las dos promesas que la plataforma hace sobre cada ejecución: que puede observarse y que puede reproducirse. MinIO es la otra mitad, guarda los objetos grandes mientras la base de datos conserva solo una clave de almacenamiento y un SHA-256. Son además las dos únicas barreras duras de readiness: si alguna cae, la plataforma se declara no lista en lugar de aceptar peticiones que no podría registrar.

Los contenedores restantes compran cada uno una sola frontera. Vault guarda las credenciales en un almacén KV v2 para que nunca aterricen en un proceso ni en un fichero dotenv. Redis cachea decisiones de permisos con un TTL de cinco minutos, sostiene el limitador de tasa y transporta el bus de eventos entre instancias. Milvus aporta la recuperación vectorial, y etcd merece mención precisa porque es una fuente frecuente de confusión: es el almacén de metadatos del propio Milvus, no una dependencia de la plataforma. Además, una caída de Milvus hace fallar la recuperación de conocimiento pero no baja el readiness, y esa asimetría es deliberada.

Un contenedor solo cobra interés después de que la respuesta ya se ha devuelto. Los eventos que genera una ejecución se persisten en la misma transacción que el trabajo; quien los entrega después es el outbox dispatcher, con idempotencia por checkpoint. Si lo quitas, nada parece romperse durante la petición, porque la petición ya había tenido éxito: los eventos simplemente se quedan pendientes para siempre y ningún consumidor recibe nada. Conviene saber también que ese proceso y el worker de ingesta de conocimiento son el mismo código que api con otro punto de entrada.

Reagrupados por lo que garantizan en lugar de por su nombre, el conjunto permanente es pequeño: dos contenedores son el producto, dos son el soporte físico del libro y sus artefactos, dos y medio son una sola capacidad, la recuperación vectorial, uno es aislamiento de secretos, uno es difusión entre réplicas y caché, y dos son procesos en segundo plano construidos con el mismo código. Exactamente un proceso de toda la topología ejecuta un modelo. El resto del peso compra una única cosa: que al terminar quede evidencia de lo ocurrido y que una caída a mitad de camino no deje medio estado.

Si la compensación merece la pena depende de para qué lo quieras. Para averiguar si un agente completa una tarea, este stack te sobra, y el artículo anterior explica cómo reducirlo a cuatro contenedores permanentes. Si el agente entra en un proceso que alguien tendrá que cuadrar después, estos contenedores son lo que acabarías escribiendo tú. Una advertencia: este recorrido es una lectura estática del código y del compose, no una nueva ejecución de extremo a extremo. El repositorio está en github.com/soit-ai/soit y la topología completa en docker/docker-compose.yml.