Introduction Introducción Vamos a ser honestos: el viaje parece casi el mismo para todos. Al principio, abre ChatGPT y piensa: Un par de líneas de texto y de repente tienes código, una confusión de marketing o incluso una sugerencia de receta. “¡Wow, eso es magia!” Luego viene la siguiente etapa.La magia se convierte lentamente en caos.Los rumores se prolongan, las rondas se acumulan, empiezas a hacer cadenas de llamadas y un día te das cuenta: “Bueno, estoy gastando más tiempo explicando al modelo lo que necesito que realmente haciendo la tarea misma”. La tercera etapa es donde las cosas finalmente se vuelven interesantes.Es cuando te das cuenta de que el caos necesita tamar, y empiezas a pensar como un ingeniero.No como alguien tinkering con un juguete, sino como un arquitecto que está construyendo un sistema. Así que déjame preguntarle: ¿Aún juega con las prompts? ¿Está atrapado en cadenas infinitas de espaguetes? o tal vez de pie en el borde de algo más grande? where are you right now on this maturity curve? En este artículo, quiero guiarle a través de un modelo de madurez simple para los sistemas LLM, un viaje desde experimentos rápidos a la arquitectura completa, donde los agentes trabajan juntos como un equipo bien oleado. -un enfoque que ayuda finalmente a liberarse del caos.Pero antes de llegar allí, echemos un vistazo honesto a cómo evolucionan la mayoría de los proyectos. AAC (Agent Action Chains) Why We Need a Maturity Model Por qué necesitamos un modelo de madurez En este momento, los sistemas LLM no tienen un camino de crecimiento estándar. Cada desarrollador o equipo toma su propio camino, probando hacks, inventando sus propios enfoques. En el papel, eso suena como libertad y creatividad. Mire a su alrededor: algunos proyectos se detienen en la etapa “sólo añade otro mensaje y funcionará”.Otros construyen largas cadenas de llamadas que parecen buenas en un diagrama pero se derrumban bajo la primera carga real.Y luego hay los mapas sin código que se despliegan en una pesadilla de cien bloques conectados en cada dirección.En el día de demostración, todavía parece vivo.Pero tan pronto como llega a la producción, nada se escala, nada se rastrea, y nadie puede incluso decir dónde se rompieron las cosas. Decenas de equipos y startups terminan perdiendo meses caminando por el mismo camino de ensayo y error, reinventando la misma rueda una y otra vez. Es ahí donde a Te da un mapa simple: dónde estás ahora, y qué necesita cambiar para avanzar.Otros campos han pasado por esto antes.Los modelos de madurez ágiles ayudaron a las empresas a determinar si eran realmente ágiles o simplemente renombraron tareas como "sprints". maturity model Los sistemas LLM están en el mismo punto de inflexión hoy en día. El hype es masivo, pero la madurez es casi cero. Sin un modelo compartido de progreso, simplemente continuaremos ahogándose en prompts caóticos y sistemas de spaghetti. Level 1 - The Script (Prompting Playground) Nivel 1 - El guión (Prompting Playground) Aquí es donde casi todo el mundo comienza. Una llamada en ChatGPT o una única API llamada y boom, usted tiene una respuesta. Funciona "en el momento", pero sólo mientras pueda mantener los detalles en su cabeza. Signs. Preguntas caóticas, sin repetibilidad, resultados impredecibles.Hoy funciona, mañana el modelo te da algo completamente diferente. Risks. Cero control. Nada aquí se puede integrar en un producto o proceso de negocio real. Todo depende de la suerte. When it makes sense. Experimentos rápidos, ideas de prototipos, o aquellos primeros "momentos de wow" cuando simplemente se está obteniendo una idea de lo que los LLMs pueden hacer. Level 2 - The Complex Prompt (Prompt Engineering 2.0) Nivel 2 - El Prompt Complejo (Ingeniería Prompt 2.0) En esta etapa, las personas comienzan a “cazar hechizos” con texto. Una única consulta ya no es suficiente, por lo que se obtienen longas prompts con instrucciones de rol, pasos detallados e incluso mini-escenarios cocidos en. Signs. Comienzas a sentir la “magia de la formulación”: cambia una frase y el modelo salta algo completamente diferente.Algunas personas incluso construyen bibliotecas rápidas, pero debajo, todavía es sólo un gran monolito. Risks. A medida que la complejidad crece, la prompt se convierte en un monstruo que no se puede mantener.Añadir un nuevo paso a menudo significa reescribir todo. When it makes sense. Las promesas complejas siguen siendo útiles en el contexto correcto: MVP rápidos, casos de uso de marketing o proyectos de investigación. A veces ofrecen un resultado impresionante “aquí y ahora”. Level 3 - The Linear Chain Nivel 3 - La cadena lineal Ahora el sistema no es un bloque masivo de texto, es una serie de pasos: extraer los datos, procesarlo, luego generar una respuesta basada en eso. Signs. En esta etapa, comienzan a aparecer los primeros flujos de trabajo, ya sea en LangChain, n8n o Make.com. Las personas comienzan a pensar en pasos, rompiendo los grandes problemas en sub-tareas. Ya es mucho mejor que un monolito gigante de un prompt, pero todavía es estrictamente lineal, sin ramificación ni flexibilidad. “Primero clasificar, luego buscar el contexto, luego generar la respuesta”. Risks. El mayor problema es la rigidez.Estas cadenas están talladas en piedra: cambia un paso, y a menudo terminas reescribiendo todo lo demás.Añadir nuevos escenarios es doloroso, y los errores tienden a romper toda la cadena a la vez.Es como los primeros días de microservicios sin un orquestador-técnicamente modular, pero todavía mantenido junto con cinta de tubo. When it makes sense. Este nivel funciona bien para pequeños bots o automatizaciones simples: analizar correos electrónicos, generar resúmenes, redactar respuestas rápidas.Es un buen punto de partida.Pero en cualquier producto real, rápidamente se convierte en una limitación. Level 4 - Spaghetti (Ad-hoc Systems) Nivel 4 - Spaghetti (sistemas ad hoc) Aquí es donde comienza el verdadero dolor.Cuando una sencilla cadena lineal ya no funciona, los desarrolladores comienzan a acumularse en las condiciones “branches” y “if-else”.La memoria temporal aparece –a veces es sólo una matriz en el código, a veces un hack de almacenamiento personalizado, a veces una variable pasada agotadamente entre nodos.La lógica se vuelve confusa y el sistema deja de ser lineal. Signs. Los flujos de trabajo en las plataformas sin código comienzan a parecerse a las redes de arañas: docenas de nodos, conexiones entrelazadas, loops por todas partes. Los proyectos basados en código no son mucho mejores: la lógica esparcida por las funciones de prompts y auxiliares, con condiciones críticas ocultas dentro del texto de las propias prompts. Risks. Estos sistemas son una pesadilla para mantener. Cuando algo se rompe, descubriendo Los errores están ocultos, el desmantelamiento no existe, y todo depende de esa persona que “sabe cómo funciona”. dónde When it makes sense. Los sistemas de espagueti suelen surgir como un subproducto de la experimentación, pero quedarse aquí mata el crecimiento.Muchos equipos alcanzan esta etapa y finalmente se dan cuenta de que la solución no es “sólo una vez más hackear”-es la verdadera arquitectura. Level 5 - Orchestrator + Roles (System Design Thinking) Nivel 5 - Orquestrador + roles (pensamiento de diseño de sistemas) Este es el estadio en el que el caos finalmente se convierte en un sistema. En lugar de una cadena interminable o un desorden de ramas de espagueti, se obtiene un Cada parte del sistema conoce su trabajo: structured design with clearly defined roles. - the brain that decides who does what and in what order. Orchestrator - narrow experts, each handling a specific task: classification, response generation, data retrieval. Specialists - makes sure the system isn’t living like a goldfish, giving it access to past context and knowledge. Memory - catches errors and ensures resilience, so one failure doesn’t bring everything down. Guard - monitors execution, collects logs, and provides visibility. Observer - polishes the final output and delivers it to the next stage. Egress Signs. En este nivel, puedes ver contratos formales (a menudo JSON) conectando roles.Puedes probar componentes individualmente, intercambiarlos o extenderlos sin romper todo el sistema.El prototipo frágil evoluciona en una arquitectura modular en la que realmente puedes construir. Risks. Usted tiene que pensar arquitectónicamente, funciones de diseño, y resistir el impulso de simplemente "tirar en otro prompt." pero esa inversión se paga rápidamente si su sistema está destinado a usuarios reales y escala. When it makes sense. Los entornos de producción, los procesos de negocio y los productos del mundo real. Cualquier cosa más allá de los experimentos necesitará eventualmente evolucionar a esta etapa. Es el único lugar donde la escalabilidad, el mantenimiento y la previsibilidad se convierten en posibles. Y esto es exactamente donde Viene en la arquitectura que desarrollé como un modelo de madurez práctico para los sistemas LLM. AAC formaliza los roles, agrega disciplina y permite ese salto crucial de "hacking rápido" a la verdadera ingeniería. AAC (Agent Action Chains) How to Use This Model Cómo utilizar este modelo El verdadero valor de un modelo de madurez es que funciona como un espejo.Le permite echar un vistazo honesto a su proyecto, ver dónde se encuentra y averiguar qué necesita cambiar para avanzar. For self-assessment. Si está construyendo algo solo o en un pequeño equipo, el modelo es básicamente una lista de verificación rápida. Esa imagen instantánea te ayuda a detectar los obstáculos de mañana hoy y prepararte para ellos con antelación. “¿Todavía vivimos en tierra rápida? ¿Hemos construido cadenas simples? o ya estamos ahogando en espaguetes?” For teams. Un gerente de producto, un ingeniero y un analista no necesitan perderse en los detalles técnicos, solo pueden nombrar el nivel. Todo el mundo sabe exactamente lo que significa: menos fricción, más conversaciones productivas. “Estamos en la etapa de la cadena, pero necesitamos pasar por encima de los espaguetes ASAP” For investors and partners. El modelo también actúa como una señal de madurez del equipo.Una startup que todavía trabaja con prompts crudos puede entregar demostraciones deslumbrantes, sin duda, pero es una apuesta arriesgada.Un equipo que ya piensa en términos de roles, orquestación y observabilidad, sin embargo? La evolución de los sistemas LLM sigue el mismo arco que cualquier tecnología: primero viene la magia, luego el caos, y finalmente-la ingeniería. Empezamos con scripts simples, nos atrapamos en prompts complejos, intentamos encadenar las cosas juntos, ahogamos en espagueti... y sólo entonces nos damos cuenta: es hora de construir la arquitectura. Un modelo de madurez nos ayuda a afrontar esa realidad: ver dónde estamos, y saber dónde necesitamos ir a continuación. Para algunos, significa dejar de lado los “monstruos-prompts”. Para otros, significa escapar de la trampa de cadenas caóticas. Eso es donde entra en la imagen-una arquitectura que formaliza este nivel superior de madurez. Pero AAC no es magia. Es el resultado de caminar el camino. AAC (Agent Action Chains) Aquí está el patrón de diseño del sistema AAC si desea sumergirse más profundamente. Aquí está el patrón de diseño del sistema AAC si desea sumergirse más profundamente.
