Arquitectura de Sistemas Conversacionales

Cómo se diseña un chatbot serio: gestión de memoria y contexto, streaming, manejo de errores y separación de capas.

todas arquitectura-de-software fundamentos diseno trade-offs rol-del-arquitecto liderazgo-tecnico toma-de-decisiones radar-framework atributos-de-calidad ilities cap-theorem requerimientos rf-rnf smart especificacion entrevistas event-storming discovery restricciones compliance ddd bounded-context lenguaje-ubicuo context-mapping estilos-arquitectonicos microservicios eda serverless monolito-modular stack-tecnologico bases-de-datos adr modelo-c4 diagramas diagramas-de-secuencia documentacion clean-architecture hexagonal ports-and-adapters inversion-de-dependencias screaming-architecture estructura-de-carpetas organizacion-por-feature rest graphql grpc mensajeria comunicacion-entre-servicios walking-skeleton scaffolding integracion-continua mvp-tecnico developer-experience docker eslint-prettier git-hooks testing piramide-de-pruebas unit-tests e2e cicd github-actions pipeline deployment decisiones-arquitectonicas deuda-tecnica tech-debt metricas-de-codigo refactoring strangler-fig migracion-legacy evolucion-de-sistemas agentes-de-ia tool-use claude-api react-pattern razonamiento-explicito debugging-de-agentes json-schema diseno-de-herramientas function-calling llamadas-paralelas structured-outputs pydantic validacion

Lecciones

ReAct Pattern: Razonamiento Explícito para Agentes Confiables

El patrón ReAct (Thought-Action-Observation) para hacer explícito y auditable el razonamiento de un agente, con sus trade-offs frente a un agente de caja negra.

react-pattern
agentes-de-ia
razonamiento-explicito
debugging-de-agentes

Ejercicios

Sin ejercicios con este filtro.

Notas

La columna invisible de todo trade-off (sesión 2026-08-30): el coste operativo. Al sacar el historial a Postgres vi la latencia enseguida, pero no que acababa de contratar una pieza encendida todo el rato con datos de clientes dentro — backups, monitorización, actualizaciones, alguien de guardia, un componente más que puede caerse. No aparece en ningún diagrama de arquitectura y es lo que más quema equipos. Regla: cuando evalúe una opción, preguntar siempre «¿quién la mantiene encendida?». Matiz técnico a no olvidar: el LLM no consulta mi base de datos — la consulta mi backend y le pasa el historial dentro del prompt. Otra de la misma sesión: se cachea lo que es igual para todos; en cuanto la respuesta depende de quién pregunta («¿cuánto debo?»), la caché deja de ser optimización y es una fuga de datos entre clientes esperando fecha.
La Ley de los Trade-offs30 ago
Tema a trabajar en el futuro (sesión 2026-08-30): el reflejo defensivo. Ante una propuesta discutible del CTO fui tres veces al "no, porque" — objeciones con signo de interrogación, y después un "muy buena idea, no obstante" que seguía siendo un no. El riesgo del rol no es equivocarse técnicamente, es convertirse en el que siempre frena: a ese dejan de consultarlo y se entera de las decisiones cuando ya están tomadas. Contrapeso: preguntar por el problema sin nombrar la solución propuesta ("¿qué querrías que fuese verdad dentro de seis semanas que hoy no lo es?" en vez de "¿qué objetivos buscas CON el multiagente?" — nombrar la solución en la pregunta ya la acepta). Nota positiva del mismo ejercicio: identifiqué solo el coste no lineal por tokens de orquestador + subagentes, que casi nadie menciona en esa reunión.
El Rol del Arquitecto de Software30 ago
Fallo propio (sesión 2026-08-30): clasifiqué el objeto `Message` como decisión de diseño mirando DÓNDE VIVE ("solo es un objeto, un solo componente") en vez de QUIÉN LO CONSUME. Un tipo de dato que cruza fronteras (se serializa al LLM, se guarda en Postgres, se manda al frontend) deja de ser estructura interna y pasa a ser contrato publicado. Regla que me llevo: antes de cambiar un nombre o una forma de dato, preguntar «¿esto está escrito en algún sitio que yo no pueda editar?». Si sí, no es refactor, es migración. Y las filas ya escritas no se pueden avisar. El patrón adulto para hacerlo es expand and contract: escribir las dos claves, migrar los datos, esperar a que todos los consumidores pasen a la nueva, y solo entonces retirar la vieja — cuatro despliegues para cambiar una palabra.
Arquitectura vs. Diseño de software30 ago

03Arquitectura de Sistemas Conversacionales

Lecciones

ReAct Pattern: Razonamiento Explícito para Agentes Confiables

Ejercicios

Arquitectura de Sistemas Conversacionales