Introduction Hola a todos, soy Max Nechaev - gerente de ingeniería de Snoonu, fundador y entusiasta de la IA. He estado desarrollando software durante un tiempo. Cuando estaba construyendo aplicaciones para iOS, había toneladas de patrones arquitectónicos allí. Se sentían sólidos. Pensado a través. Testado en combate a lo largo de los años. En ese momento, nunca imaginé que sería el que crearía una nueva arquitectura - especialmente no para sistemas de IA. Pero antes de llegar a la solución, hablemos del problema. En este momento, la IA está pasando por un ciclo de hype loco. Las startups aparecen y mueren cada día. Cada vez más personas se están sumergiendo en herramientas de bajo código y sin código como Make, n8n y otros. Y ¿sabes qué? pienso que es increíble. Millones de personas están entrando en un nuevo tipo de realidad. Se siente como en los primeros días de Internet, cuando los sitios web pasaron de estáticos a interactivos, y de repente se sintió como si todo fuera posible. Más personas están construyendo agentes de IA. Y me encanta eso. Pero hay una captura. Todavía no hay una comprensión compartida de cómo arquitectar sistemas de IA flexibles y escalables. Sin patrones de diseño reales. Sin estructura ampliamente adoptada. Cuanto más miré alrededor, más lo vi. Los agentes construidos en n8n se parecen a espaguetes. Imposible leer, borrar o escalar. Tutoriales sobre los agentes de construcción en Python? La misma historia. Todo se desechó en un solo archivo, sin separación de preocupaciones. Por supuesto, los desarrolladores experimentados podrían saber que deben separar las cosas - pero los principiantes no. Y terminan construyendo sistemas que son completamente insostenibles. Así que hoy quiero compartir la solución en la que he llegado a confiar. así estructuro mis sistemas de IA. Cómo separo las responsabilidades. Cómo mantengo las cosas flexibles, escalables y realmente sanas. Déjame presentarte a mi marco, patrón de diseño o arquitectura - llámelo lo que quieras - Cadenas de acción de agentes. AAC Meet AAC (Agent Action Chains) En algún momento, me di cuenta de algo simple.Si el caos continúa sucediendo una y otra vez, tal vez no sea un accidente. Así que empecé a experimentar. Primero, con bloques dentro de n8n. Luego empecé a separar la lógica manualmente - aquí es donde manejo la entrada, aquí es donde hago el procesamiento, aquí es la lógica central. Finalmente, los roles comenzaron a surgir. Y luego me golpeó. Esto necesita estructura. Esto necesita arquitectura. Así nació AAC – Agent Action Chains. No es otro marco con mil páginas de documentos. Una forma de construir sistemas de IA como un ingeniero adulto, no como alguien que ajusta las cosas y espera lo mejor. ¿Cuál es la idea central? Dividí el sistema en agentes con roles claros. Cada agente hace exactamente una cosa. Todos hablan a través de contratos JSON - sin adivinación, sin magia, sin caos. Piensa en ello como un equipo. Una de las entradas. Otros procesos de datos. Un tercero decide qué hacer a continuación. Otro agente habla a la memoria. Uno de los fracasos. Otro observa y registra todo. Todo el mundo sabe su trabajo.Y juntos, el sistema funciona como un reloj suizo. La belleza de AAC es que es agnóstico a la plataforma. Puedes implementarlo en n8n, en , en Python usando FastAPI, incluso dentro de LangChain o LangGraph si se toma el tiempo para configurarlo correctamente. Maquillaje.com Here’s How It Works (In Plain English) Imagínese un equipo sólido.No un grupo caótico donde todo el mundo está haciendo todo a la vez, sino una tripulación donde cada persona conoce su trabajo, posee su espacio y entrega un resultado claro. Así es como funciona AAC. Cuando una entrada llega al sistema - ya sea de un usuario o de un servicio externo - primero pasa a través de un agente que simplemente abre la puerta y la apaga. Después viene el procesamiento básico. No nos apresuramos a conclusiones. Primero, estructuramos la entrada, limpiamos el ruido, la normalizamos. Luego viene el orquestrador. Es el cerebro del sistema. No ejecuta la tarea en sí. En lugar de eso, se da cuenta de quién debe hacer qué, en qué orden, con qué parámetros. El papel del orquestrador es planificar, dirigir y gestionar el flujo. Nada más, nada menos. Entonces los especialistas toman el control. Estos agentes se concentran. Uno clasifica, otro resume, un tercero recoge datos externos, y así sucesivamente. Cada uno tiene un propósito claro. No se superponen, no luchan por las responsabilidades, no reescriben las salidas de los demás. Puedes intercambiarlos, mejorarlos, reutilizarlos - al igual que los buenos módulos de software. Cuando el sistema necesita recordar algo, la memoria entra en juego. Eso es su propio agente. No almacena todo ciegamente. En cambio, sabe cómo recuperar las cosas correctas en el momento correcto - conversaciones anteriores, contexto de usuario, hechos internos. Así es como tu sistema deja de ser un pez dorado y comienza a actuar como un verdadero asistente. El manejo de errores es tratado con la misma seriedad. AAC incluye un agente dedicado para eso - el Guardia. Monitora fallos, captura excepciones, toma acción cuando algo se rompe. No es un parche, no es un intento aleatorio. Es una parte real de la arquitectura. Y es responsable de la resiliencia. Mientras todo esto está sucediendo, el Observador está viendo en silencio. sigue lo que hace cada agente, cuánto tiempo tardan las cosas, qué decisiones se toman. No sólo por diversión - esto le da visibilidad al sistema. que ha funcionado, funcionó, y donde podría fallar. Cómo por qué Y finalmente, cuando toda la cadena ha hecho su trabajo, el resultado se formata y se entrega -de vuelta al usuario, en una respuesta de API, o dondequiera que necesite ir. Un sistema construido no sólo para funcionar, sino para evolucionar, escalar y mantenerse bajo control. All AAC Roles: Who Does What and Why It Matters Cada agente no es sólo un bloque técnico, es una unidad lógica con un papel definido y un contrato de comunicación.Esta sección descompone qué son estos roles, cómo interactúan y por qué saltar incluso uno de ellos a menudo conduce a dolor arquitectónico más tarde. Ingress Agent: the Entry Point Gestionar la señal de entrada. Purpose: Esto podría ser un webhook, un envío de formulario, un mensaje de Telegram, un evento de Kafka - realmente no importa. Porque mezclar la lógica con las capas de integración es el primer paso hacia la construcción de un monolito. En n8n, esto suele ser sólo un nodo webhook. Recibe la solicitud, registra los datos y pasa una carga útil JSON limpia al sistema. Ejemplo de lo anterior (pseudocódigo): { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Convertir los ingresos en algo útil. Purpose: Este agente limpia el ruido. Fija el casco, tira símbolos extraños, valida la estructura y extrae campos clave. Asegura que todo lo que pasa al sistema es predecible y consistente. Muchas personas saltan el preprocesamiento. Gran error. No es solo un "buen-a-tener" - es la base. Especialmente cuando se trata de LLMs, la higiene del contexto es todo. Una entrada desordenada y toda la cadena de razonamiento puede desintegrarse. En n8n, esto es típicamente un nodo de función. En código, podría ser un intermediario, un manipulador o una clase de utilidad pequeña. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System Decidir lo que debe suceder. Purpose: El orquestrador no hace el trabajo por sí mismo. Su trabajo es planificar, delegar y monitorear.Toma la entrada limpiada, calcula la intención del usuario y activa a los agentes especializados adecuados. En casos simples, esto sólo podría ser un bloque si/else. En configuraciones más avanzadas, es un LLM completo que se ejecuta con prompts cuidadosamente diseñados. Por ejemplo, puede tener GPT-4 devolver un plan de ejecución estructurado en JSON: { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Incluso puede pasar una lista de agentes disponibles y dejar que elija el mejor camino hacia adelante. La idea clave es esta: el orquestrador no resuelve el problema, construye la ruta, decide quién debe hacer qué y en qué orden. Specialist Agents: Focused Experts (TOOLS) realizar una tarea única y bien definida. Purpose: Estos agentes no están aquí para resolver todo el problema - solo una pieza específica de ella, y lo hacen bien. Clasificar una solicitud Generar una respuesta Extracción de entidades Llamar a una API externa Traducción del texto Usted puede acabar con docenas de estas. Cada una es una función separada, un módulo limpio, o un subflujo en n8n. Y eso es exactamente lo que hace que el sistema sea flexible y escalable. ¿Quieres agregar una nueva capacidad? Solo tienes que crear un nuevo especialista y registrarlo. El orquestador no necesita ser reescrito - solo necesita saber que esta herramienta existe. Ejemplo de contrato entre el orquestador y un especialista: { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past proporcionar un contexto relevante. Purpose: Este agente recoge hechos. Eso es todo. Se consulta una base de datos, una tienda de vectores, una caché de Redis - cualquier cosa que tengas - y devuelve exactamente lo que se necesita. No toma decisiones, no adivina, no alucina. Puede usarlo para recuperar las órdenes pasadas de un usuario, combinar las incorporaciones vectoriales de una base de conocimientos o capturar interacciones anteriores. En AAC, la memoria es siempre su propia cosa. De esta manera, puede escalarla, cachéarla, o incluso conectarla a varios sistemas. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Capturar y manejar fracasos. Purpose: Si un especialista se colapsa o el orquestrador se rompe, el guardia entra. Logra el error, envía alertas y, opcionalmente, ejecuta la lógica de retroceso, como volver con otro agente o devolver una respuesta predeterminada segura. En la producción, esta función es no negociable. Se producen errores. El GPT puede devolver basura. Las APIs pueden estar fuera de tiempo. Necesitas una capa que sepa qué hacer cuando las cosas van de lado. Ejemplo: GPT devuelve JSON inválido. El guardia lo captura, registra el problema, notifica a Slack y envía un mensaje de retroalimentación. { "error": "Invalid JSON from Summarizer", "fallback_response": "Sorry, I couldn’t process your request. Forwarding it to a human operator." } Observer Agent: the System’s Black Box registrar, analizar y darle visibilidad a lo que realmente ocurrió. Purpose: Este agente no interfiere, sólo observa. ¿Quiere rastrear cuánto tiempo tomó cada agente para responder? ¿Qué datos sacó el agente de memoria? ¿Cuántas veces tuvo que desencadenar una caída? Observer registra todo a cualquier herramienta que utilice - Supabase, Amplitud, Segmento o algo personalizado. Piensa en ello como en la caja negra de un avión.Esperas que no lo necesites, pero cuando algo se rompe, es la única manera de entender lo que pasó mal. Sin un observador, estás volando ciego. Con él, obtienes una imagen completa. Egress Agent: the Final Touch Mantenga el proceso limpio. Purpose: Este agente toma la salida final, la formata y la entrega donde quiera que vaya: al usuario, a una API, a un webhook, a Slack, lo que sea. Uno de los errores más comunes es olvidar este paso. Sin un agente de egress dedicado, corre el riesgo de enviar datos rotos, registros crudos o respuestas al lugar equivocado. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Cada uno de estos agentes es un bloque de construcción. Puedes ejecutarlos en paralelo, reemplazarlos de forma independiente, reutilizarlos a través de cadenas. What’s Next? How to Start Using AAC in Your Projects Cómo comenzar a usar AAC en sus proyectos Si estás leyendo esto, es probable que ya hayas enfrentado los mismos problemas que yo. Su proyecto continúa creciendo. Casos de uso se multiplican. La lógica se extiende más. Los agentes se vuelven "inteligentes" - pero el sistema se vuelve más frágil. ¿Qué fue un MVP limpio ayer se ha convertido ahora en una confusión confusa. ¿Quiere agregar una nueva rama? ¿Es un problema. Tratando de descifrar por qué GPT devolvió algo extraño? ¿No tiene idea de dónde incluso ocurrió. Este es el momento en el que comienzas a preguntar: ¿hay otra manera? Existe el . Implementar AAC significa cambiar la forma en que piensas.Es un cambio de la magia a la ingeniería. Y el punto de partida no es el código. Está mirando a tu sistema de manera diferente. Claramente. Sin ilusiones. Trate de imaginar su lógica como una cadena de especialistas independientes. Uno toma la entrada. Otro prepara los datos. Un tercero decide qué hacer. Luego viene el ejecutor. Después de eso - memoria. Luego alguien captura fallos. Finalmente, alguien registra lo que sucedió. Eso es su futuro agente, estilo AAC. En este momento, sin embargo, todos esos roles son implícitos o entrelazados tanto que nadie sabe qué es qué. El primer paso real es hacer explícitos esos roles. Incluso sólo mentalmente. Esbozarlos. Dales nombres. Empezar a preguntar las preguntas correctas: ¿quién es responsable de la orquestación aquí? ¿Dónde está la memoria? ¿Cómo sé si las cosas realmente funcionaron? ¿Qué sucede si un bloque falla? Una vez que lo hagas, el valor de la modularidad se vuelve obvio. Cuando todo está unido en un lugar, un error rompe todo el sistema. Pero cuando las cosas están estructuradas como agentes alejados, los fallos se aislan - y el sistema continúa funcionando. Es por eso que en AAC, cada agente está aislado, comunica a través de contratos, y no tiene conciencia de los demás. Es como los microservicios dentro de una tubería. Sólo más simple. Y más rápido. Y entonces comienza la diversión. De repente te das cuenta de que puedes reutilizar piezas del sistema. El mismo agente de clasificación que maneja un flujo puede usarse en otro. El bloque de memoria puede ser compartido en varias cadenas. Incluso puedes hacer que el orquestrador sea más inteligente - deje que elija qué agentes para desencadenar. Esto no es fantasía. Esta es la madurez de la línea de base que trae AAC. En plataformas sin código como n8n, esto se convierte en una verdadera superpotencia. Comienzas a construir una biblioteca de agentes. Cada uno es un subflujo con un contrato definido. ¿Quieres construir un nuevo bot? Sólo llame a los agentes que necesitas, en el orden en que los necesitas. ¿Quieres reemplazar un bloque? ¿Hazlo sin miedo. ¿Quieres monitorear el rendimiento o rastrear dónde las cosas fallan más? ¿Ya lo tienes - Observer registra todo, Guard captura cada fracaso. Comienzas a ver el sistema como un ingeniero, no alguien que tenga miedo de tocar el código. Usted está diseñando.Usted está convirtiendo una cadena de llamadas GPT en una arquitectura real - algo que vive, escala, registra, evoluciona. Y si no tienes tiempo para reconstruir todo ahora mismo - eso está bien. Comience con un flujo. Un punto de entrada. Un momento honesto donde dices: "Bueno, déjame probar un nuevo enfoque aquí. Déjame separar los roles. agrega un poco de control". Es el momento en el que empiezas a construir con AAC. Y las posibilidades son - no querrás volver.
