Hace un año todo el mundo hablaba de prompt engineering.
Hace seis meses, la conversación pasó a los AI Agents.
Y durante las últimas semanas hay un nuevo término apareciendo en todos lados:
Graph Engineering.
No es una nueva librería.
No es un nuevo framework.
Y tampoco es una palabra de moda inventada por alguna startup para vender consultoría.
Es un cambio de mentalidad sobre cómo diseñamos sistemas de agentes.
Y creo que va a ser una de las habilidades más importantes de los próximos años.
La mayoría de agentes que veo construidos hoy siguen exactamente el mismo patrón.
Leer información
↓
Pensar
↓
Escribir respuesta
↓
Revisar
↓
Terminar
Es cómodo.
Es fácil de entender.
Y funciona.
Pero tiene un problema enorme.
Todo ocurre de forma secuencial.
Cada paso espera al anterior, incluso cuando realmente no existe ninguna dependencia.
Imagina que quieres revisar un repositorio con 200 archivos.
La forma tradicional sería:
Archivo 1
Archivo 2
Archivo 3
...
Archivo 200
Un agente.
Una tarea.
Un contexto.
Mucho tiempo esperando.
Cuando empiezas a analizar los problemas reales descubres algo curioso.
La mayoría de tareas son independientes.
Revisar el archivo auth.py no necesita esperar a que termine database.py.
Buscar vulnerabilidades en una carpeta no depende de analizar otra.
Resumir cinco documentos distintos tampoco requiere hacerlo uno detrás de otro.
Entonces...
¿Por qué seguimos diseñando agentes como si todo fuera una cadena?
La respuesta es sencilla.
Porque pensamos en prompts.
No pensamos en grafos.
Graph Engineering consiste en diseñar el trabajo como un grafo de dependencias.
Cada nodo representa una tarea.
Cada arista representa una dependencia real.
Si dos nodos no necesitan compartir información...
...pueden ejecutarse al mismo tiempo.
Eso cambia completamente la escala.
En lugar de esto:
A → B → C → D
empiezas a construir algo así:
A
/ | \
B C D
\ | /
E
Ahora tienes múltiples agentes trabajando en paralelo y únicamente sincronizando cuando realmente hace falta.
No estás optimizando el prompt.
Estás optimizando la arquitectura.
Hay una pregunta que me parece brillante.
Cada vez que escribas:
“Y después...”
pregúntate:
¿El siguiente paso necesita realmente el resultado del anterior?
Si la respuesta es no...
...esa dependencia sobra.
Y probablemente puedas ejecutar ambos pasos simultáneamente.
Es una forma extremadamente sencilla de descubrir paralelismo que normalmente pasa desapercibido.
Mucha gente piensa que Graph Engineering sirve para hacer las cosas más rápidas.
Sí.
Pero eso es casi un efecto secundario.
Lo realmente importante es la escala.
Imagina un agente encargado de revisar un monorepo enorme.
En lugar de analizar un archivo tras otro...
puede lanzar decenas de agentes especializados.
Uno revisa autenticación.
Otro busca secretos expuestos.
Otro analiza calidad del código.
Otro ejecuta pruebas.
Otro verifica los resultados de todos los anteriores.
Cada uno trabaja con su propio contexto.
Cada uno toma decisiones independientes.
Y al final existe un nodo que sintetiza todo.
Eso sería prácticamente imposible dentro de una única conversación con un LLM.
Aquí aparece otro concepto interesante.
Muchos sistemas crean varios agentes...
...pero todos comparten exactamente el mismo historial.
Eso no son varios agentes.
Es el mismo agente con varias pestañas abiertas.
Si un agente revisa su propio trabajo usando exactamente el mismo contexto...
no está verificando nada.
Simplemente está reafirmando su respuesta anterior.
Los buenos sistemas aíslan el contexto.
Cada nodo recibe únicamente la información que necesita.
Y eso hace que las verificaciones sean mucho más fiables.
Uno de los errores más comunes es pensar:
“Si un agente funciona bien...
diez funcionarán diez veces mejor.”
No.
Un mal diseño con cien agentes sigue siendo un mal diseño.
De hecho será más caro.
Más lento de depurar.
Y muchísimo más difícil de mantener.
La clave nunca es el número de agentes.
La clave es diseñar correctamente las dependencias entre ellos.
Durante mucho tiempo los agentes fueron simplemente una secuencia de llamadas al modelo.
Ahora herramientas como Claude Code, OpenAI Codex, LangGraph o los sistemas internos de muchas empresas empiezan a construir flujos mucho más parecidos a grafos que a conversaciones.
La conversación está dejando paso a la orquestación.
Y creo que esa diferencia será enorme.
Dentro de unos años probablemente dejaremos de preguntar:
“¿Qué prompt utilizaste?”
Para empezar a preguntar:
“¿Cómo diseñaste el grafo?”
Porque el valor ya no estará únicamente en escribir mejores instrucciones.
Estará en saber dividir un problema complejo en cientos de tareas independientes que colaboran entre sí.
Creo que estamos viviendo exactamente el mismo cambio que ocurrió hace años con los sistemas distribuidos.
Al principio escribíamos programas secuenciales.
Después aprendimos concurrencia.
Más tarde llegaron los sistemas distribuidos.
Y finalmente apareció toda una disciplina dedicada únicamente a diseñar arquitecturas escalables.
Con los agentes está ocurriendo lo mismo.
El prompt fue el primer paso.
Los agentes fueron el segundo.
El siguiente paso es aprender a diseñar el sistema completo.
No importa si utilizas Claude Code, Codex, LangGraph o cualquier otra plataforma.
Lo importante es dejar de pensar en una conversación...
...y empezar a pensar en un grafo.
En este artículo hemos hablado de cómo conectar agentes.
Pero hay una pregunta que hemos dado por hecha:
¿Qué hace exactamente cada nodo del grafo?
La respuesta son las Skills.
Una Skill encapsula conocimiento, procesos y buenas prácticas para una tarea concreta. Cuando empiezas a construir sistemas complejos, descubres que el verdadero trabajo no está en escribir un prompt gigantesco, sino en reutilizar pequeñas capacidades especializadas que puedes combinar una y otra vez.
Hace unas semanas escribí una guía completa sobre este tema que puedes leer aquí:
Después vuelve a este artículo. Verás Graph Engineering con otros ojos.
Si prefieres no construir todas esas Skills desde cero, la Claude OS Collection reúne las mismas arquitecturas y componentes reutilizables que utilizo en mis proyectos para acelerar el desarrollo de sistemas agénticos.
Sin posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.