Arquitectura de un chatbot empresarial listo para producción: de chunking a planner/validador

La demo funciona siempre. Es el primer lunes de tráfico real cuando se descubre que el chatbot que tanto gustó en la presentación es un castillo de naipes. Los errores se acumulan, el estado se pierde entre reinicios de pods, un agente se cuela otro equipo y lo que parecía un producto es, en realidad, un prototipo con traje.

Construir un chatbot empresarial que aguante en producción no es una cuestión de elegir el modelo más potente ni de escribir el prompt más elaborado. Es arquitectura. Capas bien apiladas, cada una resolviendo un problema específico que, si lo ignoras, te explota en la cara en el peor momento posible.

En mayo de 2026, BerriAI publicó el código de LiteLLM Agent Platform bajo licencia MIT. No es solo otra librería de Python: es una infraestructura completa sobre Kubernetes para correr agentes en producción con sandboxes aislados por sesión y persistencia de estado que sobrevive a reinicios de pods. Lo que BerriAI resolvió con eso es el problema que nadie quiere admitir: los agentes son stateful por naturaleza, y la mayoría de plataformas los tratan como si fueran stateless. El resultado predecible es el castillo de naipes del párrafo anterior.

Este artículo desglosa las ocho capas que necesitas. No es teoría: cada una viene con el porqué, las decisiones concretas y los puntos donde la gente se equivoca.

Capa 1: Chunking, partir bien antes de indexar

El chunking es el proceso de dividir documentos en fragmentos manejables antes de convertirlos en vectores y almacenarlos. Parece trivial. No lo es.

Un chunk mal cortado destroza el contexto que el modelo necesita para responder bien. Si cortas una cláusula contractual a la mitad, o separas la pregunta de su respuesta en un FAQ, el modelo recibe información incompleta y alucina para rellenar los huecos. Es exactamente como darle a alguien la mitad de un contrato y pedirle que lo firme.

Las decisiones que importan aquí:

Respeta los límites semánticos: párrafos, secciones, bloques de código. No cortes por número fijo de caracteres sin más.
Overlap controlado: un pequeño solapamiento entre chunks consecutivos (repetir las últimas frases del chunk anterior al inicio del siguiente) evita que el contexto se pierda en los cortes.
Tamaño según el modelo: los rangos de 256-512 tokens son un punto de partida habitual para modelos de chat, pero el tamaño óptimo depende de la naturaleza del documento y del modelo de embeddings que uses. No hay un número mágico universal.

Lo que no consta en las fuentes disponibles: los parámetros exactos de chunking que usa LiteLLM Agent Platform internamente, ni qué modelos de embeddings emplea por defecto. Si alguien te vende una configuración "óptima" universal sin contexto, miente.

Capa 2: Embeddings y vector store, coordenadas del significado

Un embedding es una representación numérica de un chunk de texto: un vector de cientos o miles de dimensiones donde textos con significados parecidos quedan cerca en el espacio matemático. La analogía más honesta: son coordenadas de mapa donde "política de devoluciones" y "cómo devolver un producto" quedan a dos pasos de distancia, aunque no compartan ni una palabra.

El vector store es la base de datos que almacena esos vectores y permite buscar en ellos de forma eficiente.

Por qué importa: sin esto, la recuperación de información es búsqueda por palabras clave, tecnología del año 2003. No entiende sinónimos, no entiende contexto, no escala.

Decisiones concretas:

pgvector si ya tienes PostgreSQL en tu stack. LiteLLM Agent Platform lo usa como backing store principal, con migraciones de esquema gestionadas vía init container. Si ya pagas por Postgres, añadir pgvector tiene coste marginal cero y elimina una dependencia externa.
Qdrant si necesitas escala seria o funcionalidades avanzadas de filtrado. Es una base de datos vectorial dedicada, más flexible para casos de uso complejos.
El índice ANN (Approximate Nearest Neighbor): buscar el vector más similar entre millones no puede hacerse comparando uno a uno. Los índices ANN como HNSW (Hierarchical Navigable Small World) permiten búsquedas aproximadas en milisegundos en lugar de segundos. El tradeoff es exactitud vs. velocidad, y en producción casi siempre ganas eligiendo velocidad con una pequeña pérdida de precisión.

La elección del vector store es también una decisión de coste por token y por consulta: cada búsqueda vectorial tiene un coste de compute que se acumula con el tráfico real.

Capa 3: Retrieval y reranking, recuperar bien, no solo rápido

Recuperar los chunks más similares al query del usuario es el primer paso. El segundo, que mucha gente se salta, es reordenarlos por calidad real antes de pasárselos al modelo.

El problema: la similitud coseno (la métrica estándar para comparar vectores) mide parecido geométrico, no relevancia real para responder una pregunta específica. El chunk con la puntuación más alta puede ser temáticamente cercano pero contextualmente inútil.

El stack que funciona:

BM25 para léxico exacto: cuando el usuario escribe un número de contrato, un nombre propio o un código de producto, la búsqueda semántica puede fallar porque no hay "significado" que capturar, solo coincidencia exacta. BM25 es el algoritmo de recuperación clásico basado en frecuencia de términos, y sigue ganando en estos casos.
Búsqueda semántica vectorial: para el resto, la que ya describimos.
Reranker cross-encoder: un modelo más pequeño y específico que toma los top-N resultados combinados y los reordena evaluando cada par (query, chunk) de forma conjunta. Más lento que el retrieval inicial, pero mucho más preciso. Se aplica solo al subconjunto reducido, no a toda la base de datos.

La combinación de BM25 + semántica se llama búsqueda híbrida, y es el estándar de facto para sistemas de producción con documentación variada.

Capa 4: El planner, decidir antes de actuar

Aquí es donde un chatbot pasa de ser un wrapper de LLM a ser un agente real.

Sin planificación explícita, el modelo improvisa paso a paso. Eso funciona en demos y explota en producción: el agente entra en bucles, pierde el hilo del objetivo original o ejecuta herramientas en el orden incorrecto porque nadie le dijo cuál era el plan.

El tutorial publicado por MarkTechPost en mayo de 2026 (construido sobre OpenAI API con el modelo gpt-5.2) muestra una implementación concreta: el planner recibe el objetivo del usuario y devuelve un JSON estricto con tres campos: objective (qué se quiere conseguir), steps (lista ordenada de acciones) y tool_checkpoints (qué herramientas se usan en cada paso y cómo verificar que funcionaron).

{
"objective": "Calcular el ROI del proyecto X y escribir el resultado en un archivo",
"steps": [
"Extraer cifras de inversión y retorno del contexto",
"Calcular ROI con la calculadora segura",
"Verificar el resultado contra los datos originales",
"Escribir el resultado en archivo con verificación SHA-256"
],
"tool_checkpoints": {
"step_2": "safe_calculator",
"step_4": "file_writer"
}
}

El planner usa temperatura 0.1 en ese tutorial. No es capricho: el planner necesita ser determinista. Alta temperatura aquí significa planes distintos para el mismo objetivo en ejecuciones distintas, lo que hace el sistema impredecible.

El estado del agente se almacena en un dataclass AgentState con tres campos: goal (el objetivo original), memory (información acumulada durante la ejecución) y trace (registro de cada acción tomada). Esto es lo que permite auditar qué hizo el agente y por qué, algo imprescindible en entornos empresariales.

Capa 5: Executor y self-critique, ejecutar y verificar sin humano en el bucle

El executor toma el plan, ejecuta las herramientas y genera un borrador de respuesta. El loop corre hasta 12 iteraciones antes de cortar: si en 12 intentos no ha resuelto el objetivo, algo está mal en el plan o en las herramientas, y seguir iterando infinitamente es un agujero de coste y latencia.

Las herramientas del tutorial son deliberadamente seguras:

_safe_calc: una calculadora que solo permite caracteres numéricos y funciones matemáticas. Usa eval() con un namespace restringido, no el namespace completo de Python. Esto es importante: eval() sin restricciones en un agente de producción es una vulnerabilidad, no una feature.
_kb_search: búsqueda por palabras clave con scoring, sobre una base de conocimiento pequeña (3 entradas en el tutorial). En producción, esto se sustituye por el stack de retrieval de la capa 3.
_extract_json: extracción de JSON mediante regex. Simple y predecible.
_write_file: escritura de archivos con verificación SHA-256. El hash garantiza que lo que se escribió es exactamente lo que se generó, sin corrupción ni truncado silencioso.

Cada herramienta tiene un schema JSON completo para function calling. El modelo no adivina cómo la herramienta: le llega la especificación exacta de parámetros, tipos y descripciones.

Después del executor viene el critic. Este es el self-critique: un rol separado (con su propio system prompt) que recibe el borrador del executor y devuelve tres cosas: issues (qué está mal), fixes (cómo corregirlo) y la respuesta mejorada. El executor usa temperatura 0.2; el critic puede ser más conservador aún.

El self-critique no es un lujo para proyectos grandes. Es el mecanismo que reduce alucinaciones sin necesitar un humano revisando cada respuesta. En producción, es la diferencia entre un sistema que falla silenciosamente y uno que se corrige solo.

Este patrón planner/executor/critic es lo que Vention describe en su modelo de madurez de IA como Stage 4 (multi-agent orchestration), según su artículo publicado en TechCrunch en abril de 2026. La mayoría de organizaciones están en Stage 1-2: uso individual y fragmentado sin contexto compartido del proyecto. Llegar a Stage 3, desarrollo spec-driven con IA integrada, ya puede acelerar el trabajo rutinario entre un 50% y un 80% según estimaciones de Vention basadas en un proyecto de un año, aunque sin metodología estadística detallada publicada.

Capa 6: Sandboxing y sesión persistente, la capa que nadie construye hasta que tiene un incidente

Esta es la capa que diferencia una infraestructura de producción real de un prototipo escalado a la fuerza.

El problema del estado: los agentes acumulan contexto a lo largo de una conversación. Historial de mensajes, resultados de herramientas, razonamiento intermedio. Si el pod de Kubernetes se reinicia (y en producción, se reinicia), ese estado desaparece. El usuario obtiene un agente con amnesia que no recuerda nada de lo que hablaron. En un chatbot de soporte empresarial, eso es inaceptable.

LiteLLM Agent Platform resuelve esto usando PostgreSQL como store de sesión persistente. El historial de conversación, los resultados de tool calls y el razonamiento intermedio se persisten en Postgres antes de que el pod muera. Cuando el pod se reinicia o la sesión se migra a otro nodo, el agente retoma exactamente donde lo dejó. Las migraciones de esquema se gestionan vía init container, lo que significa que los upgrades de la plataforma no rompen las sesiones en curso.

El problema del aislamiento: en un entorno multiequipo, los agentes de distintos equipos no pueden compartir contexto ni credenciales. Un agente del equipo de finanzas no puede, ni por accidente, acceder a datos del equipo de RRHH.

LiteLLM Agent Platform gestiona esto con el CRD (Custom Resource Definition) kubernetes-sigs/agent-sandbox: cada sesión corre en un sandbox Kubernetes aislado. Las credenciales se inyectan vía variables de entorno con el prefijo CONTAINER_ENV_, que se strippea al entrar en el contenedor. Esto permite gestionar secretos sin modificar las imágenes de contenedor, algo crítico en entornos con pipelines de CI/CD y políticas de seguridad estrictas.

Para desarrollo local, el quickstart usa kind para crear un cluster llamado agent-sbx. El script bin/kind-up.sh es idempotente: puedes ejecutarlo varias veces sin romper nada. Para producción, la recomendación es AWS EKS para los sandboxes y Render para web y worker.

La plataforma también incluye un sistema de harnesses bajo harnesses/opencode para agentes de código como Claude Code o Codex, con un vault proxy para gestión de credenciales. El repositorio separado litellm-agent-runtime añade soporte para agentes con VM por sesión, para casos donde el aislamiento contenedor no es suficiente.

Capa 7: Control de acceso y trazabilidad

El sandboxing de la capa 6 aísla sesiones entre sí. Pero eso no responde a una pregunta diferente: ¿quién puede consultar qué dentro del índice RAG? Un comercial no debería ver los documentos de due diligence de M&A. Un agente de soporte no debería tener acceso a las nóminas. El aislamiento por sesión no es control de acceso por rol: son dos problemas distintos que se confunden con frecuencia y cuya confusión cuesta cara.

Control de acceso al índice RAG por rol de usuario

La forma operativa de implementarlo es filtrar en el momento del retrieval, no antes ni después. Cuando el usuario lanza una query, el sistema de retrieval recibe no solo el texto de la búsqueda sino también los metadatos de rol del usuario autenticado. El vector store filtra los chunks elegibles antes de calcular similitud: solo se busca dentro del subconjunto de documentos que ese rol tiene permiso de ver.

En pgvector, esto se implementa con filtros de metadatos en la query SQL: cada chunk almacenado lleva un campo allowed_roles (array de strings) y la búsqueda añade una cláusula WHERE allowed_roles @> ARRAY['rol_del_usuario']. En Qdrant, el mecanismo equivalente son los payload filters que se aplican antes del ANN search. El resultado es el mismo: el modelo nunca recibe chunks que el usuario no debería ver, porque esos chunks nunca entran en el contexto.

Lo que no funciona: filtrar la respuesta del modelo después de que ya ha procesado los chunks. Si el modelo vio el documento, ya lo procesó. El control tiene que estar en el retrieval, no en el output.

Qué debe registrar el log de auditoría por sesión

En un entorno empresarial con requisitos de compliance, "el agente respondió algo" no es suficiente. Necesitas poder reconstruir exactamente qué pasó, con qué información y por qué. Los campos mínimos que debe registrar cada entrada de log de auditoría son:

session_id: identificador único de la sesión
user_id: quién lanzó la query (no el nombre, el identificador del sistema de identidad)
user_role: el rol activo en el momento de la consulta
timestamp_utc: marca de tiempo en UTC, no en hora local
query_text: el texto exacto que envió el usuario
chunks_retrieved: lista de IDs de chunks que entraron en el contexto, con su puntuación de relevancia
tool_calls: qué herramientas se invocaron, con qué parámetros y qué devolvieron
model_response: la respuesta completa generada, antes de cualquier post-procesado
planner_trace: el JSON del plan generado (si hay planner)
latency_ms: tiempo total de la sesión en milisegundos
error_code: si hubo fallo, el código y el mensaje exacto

Estos campos no son opcionales si tienes que pasar una auditoría de seguridad o cumplir con normativas como GDPR, SOC 2 o ISO 27001. Sin chunks_retrieved, no puedes demostrar que el modelo no accedió a información que no debía. Sin tool_calls, no puedes reconstruir qué acciones tomó el agente en sistemas externos.

Por qué MCP es el conector, no la garantía

Model Context Protocol (MCP) es el estándar que permite a los modelos conectarse a herramientas y fuentes de datos externas de forma estructurada. Es útil. Pero hay una confusión frecuente que conviene cortar de raíz: MCP define cómo se comunica el modelo con las herramientas, no quién tiene permiso de qué.

Dicho de otra forma: MCP es el cable. El control de acceso es la cerradura. Tener MCP configurado no significa que tengas control de acceso implementado. Un agente con acceso MCP a una base de datos puede, si no hay lógica de autorización en el servidor MCP, consultar cualquier tabla independientemente del rol del usuario que lanzó la sesión.

La autorización tiene que vivir en el servidor MCP (o en la capa de datos que expone), no en el prompt del agente. Un system prompt que dice "no consultes datos de RRHH si el usuario no es de RRHH" es una sugerencia, no un control. Un servidor MCP que rechaza la llamada con un 403 si el token del usuario no tiene el scope correcto es un control real.

Cómo estructurar los logs para que sirvan en una auditoría real

Un log que existe pero no se puede consultar en tiempo razonable no sirve para una auditoría. La estructura importa tanto como el contenido.

Los logs de auditoría de agentes tienen que estar en un store separado del log operacional. El log operacional (errores, latencias, métricas de infraestructura) tiene una retención corta y se optimiza para debugging en tiempo real. El log de auditoría tiene retención larga (mínimo el periodo que exija tu normativa, típicamente 1-7 años), es inmutable una vez escrito y está indexado para consultas por user_id, session_id y rango de timestamp_utc.

El formato recomendado es JSON estructurado, una entrada por evento, con todos los campos del apartado anterior. No texto libre, no logs concatenados en un string. JSON estructurado permite hacer queries directas con herramientas como AWS Athena, BigQuery o simplemente jq sobre los archivos, sin parsear texto.

Un patrón que funciona en producción: escribir los logs de auditoría en un bucket de object storage (S3, GCS) con particionado por fecha y user_id, con políticas de retención configuradas en el bucket y acceso de escritura solo para el sistema de logging (no para los agentes ni para los desarrolladores). Así el log es append-only por construcción, no por promesa.

Capa 8: Actualización del índice

Un índice RAG que se construye una vez y no se toca más es un índice que envejece. Los documentos cambian: se actualizan políticas, se retiran productos, se corrigen errores en la documentación. Si el índice no refleja esos cambios, el agente responde con información obsoleta con la misma confianza con la que respondería con información actualizada. El modelo no sabe que el documento que está citando fue retirado hace tres meses.

El problema: documentos que cambian, se versionan o se retiran

Hay tres escenarios distintos que requieren tratamiento distinto:

Documento actualizado: el contenido cambia pero el documento sigue siendo válido. Los chunks del índice que corresponden a ese documento están desactualizados y hay que reemplazarlos.
Documento versionado: coexisten varias versiones del mismo documento (v1.2 y v2.0 de un contrato tipo, por ejemplo). El índice tiene que saber qué versión es la vigente y cuáles son históricas, y el retrieval tiene que poder filtrar por versión si la query lo requiere.
Documento retirado: el documento ya no es válido y no debe aparecer en ningún resultado. Si los chunks siguen en el índice, el agente puede citarlos. Hay que eliminarlos, no solo marcarlos.

Re-indexado incremental vs. re-indexado completo: cuándo cada uno

Re-indexado completo: se borra el índice y se reconstruye desde cero con todos los documentos. Es la opción más simple de implementar y garantiza consistencia total. El problema es el coste: en una base documental grande, recalcular todos los embeddings tiene un coste de compute y tiempo no trivial. En producción, un re-indexado completo diario puede ser viable para bases de datos pequeñas (cientos de documentos); para bases de miles de documentos o más, es prohibitivo como operación frecuente.

Re-indexado incremental: solo se procesan los documentos que han cambiado desde el último indexado. Requiere un mecanismo para detectar cambios (ver siguiente apartado), pero el coste es proporcional al volumen de cambios, no al volumen total. Es el enfoque correcto para producción con bases documentales que cambian con frecuencia.

La regla práctica: usa re-indexado completo para el setup inicial y para recuperación ante corrupción del índice. Usa re-indexado incremental para el mantenimiento continuo. Programa un re-indexado completo periódico (semanal o mensual según el volumen) como verificación de consistencia, aunque el incremental esté funcionando bien.

Cómo detectar cambios en la fuente documental y disparar re-indexado automático

El mecanismo depende de dónde viven los documentos:

Object storage (S3, GCS): los eventos de creación, modificación y eliminación de objetos se pueden enrutar a una cola (SQS, Pub/Sub) que dispara el pipeline de re-indexado. Es el mecanismo más limpio: event-driven, sin polling.
Base de datos documental: un campo updated_at con timestamp en cada documento permite hacer queries periódicas del tipo "dame todos los documentos modificados desde la última ejecución". Simple y fiable si el campo se actualiza correctamente en cada escritura.
Sistema de ficheros o repositorio Git: los webhooks de Git (push events) pueden disparar el pipeline cuando se hace commit de nuevos documentos. Para documentación que vive en un repo, esto es el enfoque natural.
CMS o sistema de gestión documental: la mayoría exponen webhooks o APIs de eventos. Si el sistema no tiene eventos, el fallback es polling periódico comparando hashes de contenido (MD5 o SHA-256 del documento completo) contra los hashes almacenados en el momento del último indexado.

Lo que no funciona: confiar en que alguien recuerde lanzar el re-indexado manualmente cuando actualiza un documento. En producción, los procesos manuales se olvidan. El re-indexado tiene que ser automático o no es fiable.

Gestión de versiones de documentos en el vector store

Cada chunk en el vector store debe llevar metadatos de versión: document_id, document_version, valid_from, valid_until (null si es la versión vigente) y status (active, superseded, retired).

Cuando se indexa una nueva versión de un documento, el proceso correcto es:

Indexar los chunks de la nueva versión con status: active y valid_from: timestamp_actual.
Actualizar los chunks de la versión anterior a status: superseded y valid_until: timestamp_actual.
No borrar los chunks de versiones anteriores si necesitas trazabilidad histórica (para auditorías o para responder preguntas sobre "qué decía la política en enero de 2025"). Borrarlos si el espacio o el coste lo requieren y no tienes requisitos de historial.

Cuando se retira un documento, los chunks pasan a status: retired y el filtro de retrieval los excluye. Si no necesitas historial, se borran directamente.

El retrieval por defecto solo busca en chunks con status: active. Las queries históricas (que deberían ser explícitas y restringidas por rol) pueden incluir status: superseded.

El orden de construcción en la práctica

Ocho capas es mucho si partes de cero con recursos limitados. La pregunta real es cuál es el orden que te permite tener algo en producción sin que explote, y cuáles son las capas que no puedes saltarte bajo ningún concepto.

Capas bloqueantes vs. mejoras incrementales

Hay capas sin las cuales el sistema directamente no funciona o no es seguro para producción. Y hay capas que mejoran la calidad o la operabilidad, pero cuya ausencia no te impide arrancar.

Capa	Qué resuelve	Coste de no tenerla
1. Chunking	Contexto coherente en el índice	El modelo alucina para rellenar huecos de contexto cortado. Bloqueante.
2. Embeddings y vector store	Recuperación semántica de información	Sin esto no hay RAG, solo búsqueda por palabras clave. Bloqueante.
3. Retrieval y reranking	Calidad de los chunks que llegan al modelo	Sin reranking, el modelo trabaja con resultados subóptimos. El retrieval básico es bloqueante; el reranking es mejora incremental.
4. Planner	Ejecución ordenada y auditable de tareas complejas	Sin planner, el agente improvisa. Aceptable para queries simples; bloqueante para flujos multi-paso.
5. Executor y self-critique	Ejecución de herramientas y corrección automática de errores	El executor es bloqueante si el agente usa herramientas. El self-critique es mejora incremental.
6. Sandboxing y sesión persistente	Aislamiento entre sesiones y supervivencia a reinicios	Sin persistencia, el agente pierde estado en cada reinicio. Sin sandboxing, hay riesgo de fuga de datos entre usuarios. Bloqueante en producción multiusuario.
7. Control de acceso y trazabilidad	Quién ve qué y registro auditable de todo	Sin control de acceso en el retrieval, cualquier usuario puede ver cualquier documento. Sin logs de auditoría, no puedes cumplir con compliance. Bloqueante si hay datos sensibles o requisitos regulatorios.
8. Actualización del índice	Índice que refleja la realidad documental actual	Sin esto, el agente responde con información obsoleta con plena confianza. Bloqueante para cualquier base documental que cambie.

El orden de construcción cuando partes de cero

Si tienes recursos limitados y necesitas priorizar, este es el orden que minimiza el riesgo de construir sobre cimientos que luego hay que tirar:

Chunking + embeddings + vector store (capas 1 y 2): sin esto no hay nada. Es el núcleo del sistema.
Retrieval básico (capa 3, sin reranking): que el sistema recupere información relevante. El reranking viene después.
Control de acceso en el retrieval (capa 7, solo la parte de permisos): si tienes datos sensibles, esto va antes que el planner. Un sistema que recupera información sin control de acceso no debería llegar a producción aunque sea un MVP.
Logs de auditoría mínimos (capa 7, campos básicos): session_id, user_id, query_text, chunks_retrieved. El resto de campos se añaden iterativamente.
Executor con herramientas básicas (capa 5): si el chatbot solo responde preguntas sin ejecutar acciones, puedes saltarte el planner inicialmente. Si ejecuta acciones, el planner (capa 4) va antes.
Sandboxing y persistencia (capa 6): antes del lanzamiento a múltiples usuarios reales.
Reranking (capa 3, segunda parte): mejora de calidad una vez el sistema base funciona.
Self-critique (capa 5, segunda parte): reducción de alucinaciones una vez tienes volumen suficiente para medir el impacto.
Actualización incremental del índice (capa 8): en el momento en que los documentos empiecen a cambiar con frecuencia. Si la base documental es estática al principio, puede esperar; en cuanto haya actualizaciones regulares, es bloqueante.

El planner (capa 4) va donde lo necesites según la complejidad de las tareas: antes del executor si el agente maneja flujos multi-paso desde el día uno, después si empiezas con queries simples de pregunta-respuesta.

Lo que no tiene sentido es construir un planner sofisticado antes de tener control de acceso en el retrieval. Un agente que planifica bien pero que puede filtrar documentos de cualquier usuario es un agente que no debería estar en producción.

Por qué el orden importa

Estas ocho capas no son independientes. Cada una alimenta a la siguiente y un fallo en cualquier punto se amplifica hacia arriba:

Un chunk mal cortado genera embeddings que no capturan el contexto correcto.
Embeddings malos hacen que el retrieval devuelva resultados irrelevantes.
Retrieval malo le da al planner información incorrecta para construir el plan.
Un plan defectuoso hace que el executor tome decisiones equivocadas.
Sin self-critique, esos errores llegan directamente al usuario.
Sin sandboxing y persistencia, todo lo anterior puede funcionar perfectamente en staging y romperse en producción bajo carga real.
Sin control de acceso en el retrieval, el sistema funciona técnicamente pero filtra datos que no debería filtrar.
Sin actualización del índice, el sistema responde con confianza sobre información que ya no es verdad.

La arquitectura que BerriAI publicó en mayo de 2026 no resuelve las capas 1-3 por ti: esas son decisiones de tu stack de datos. Lo que resuelve es el problema más difícil de operacionalizar: que el agente sea stateful de verdad, que el estado sobreviva a la infraestructura y que el aislamiento entre sesiones sea una garantía de la plataforma, no una promesa en el README.

Si estás construyendo esto desde cero, el patrón de pagos agénticos aplica aquí también: el control tiene que estar en la infraestructura, no en el prompt. Un agente que "promete" no acceder a datos de otro equipo porque su system prompt lo dice es un agente que fallará en el momento menos conveniente. Un sandbox de Kubernetes que hace físicamente imposible ese acceso es una garantía real.

El chatbot más sofisticado del mundo construido sobre capas mal apiladas sigue siendo un demo caro. La arquitectura no es el trabajo aburrido previo al producto: es el producto.