🧱 Trata el nodo como unidad de trabajo
Un nodo puede ser un agente de IA, una llamada a un modelo, un fragmento de código común o incluso una decisión humana en medio del flujo. La pregunta que debes hacerte antes de diseñar cualquier nodo es sencilla: ¿esto necesita IA de verdad? La respuesta no siempre es sí.
Uno en el determinista — uno if, una consulta a una
base de datos, un script que solo da formato a los datos: es más barato, rápido y confiable que dejarle todo al modelo.
La regla en la que ha convergido la industria: el código controla el enrutamiento predecible; el modelo se encarga de lo que requiere
interpretación o criterio.
🆕 ¿Nuevo aquí? Dos palabras antes de seguir
- Nodo determinista: un paso que siempre produce el mismo resultado para la misma entrada — sin un modelo de IA en medio. Un
if valor > 100y es determinista. - Orquestador: el nodo (o agente) que decide a quién enviarle el siguiente trabajo: el «gerente» del grafo, no quien ejecuta la tarea en sí.
Qué observar: las cinco cajitas cian dentro del nodo. Cada una puede ser diferente en cada nodo de tu grafo — y por eso quedan dentro de la caja, no dispersas por el sistema. Las dos flechas de salida ya muestran lo que el tema 2 va a desglosar: es ahí, en la arista, donde reside la condición.
✓ Buen candidato para un nodo determinista
- ✓Validar el formato del correo electrónico: una expresión regular lo resuelve, sin necesidad de juzgar
- ✓Consultar el saldo en una API: llamada directa, respuesta exacta
- ✓Enrutar por categoría ya marcada en la base de datos: un
switch
✗ ¿De verdad necesitas un modelo?
- ✗Juzgar si un texto es ofensivo — requiere interpretar el contexto
- ✗Resumir un documento largo en lenguaje natural
- ✗Decidir cuál de las tres respuestas ambiguas quiso decir el cliente
Conceptos clave
Agente, código, humano o modelo
Más barato y más confiable
El modelo juzga
Regla práctica de la industria
🔀 Pon la decisión en la arista
Una arista condicional — la que lleva un «si» — y donde vive el enrutamiento: «si se aprueba, sigue; si se rechaza, vuelve». Eso es exactamente lo que distingue un grafo de una cola. Si todas tus aristas son incondicionales (siempre van al mismo lugar siguiente), no escribiste un grafo: escribiste un pipeline disfrazado.
💡 Prueba rápida: ¿tu flujo es un grafo o un pipeline?
Revisa cada arista de tu dibujo y pregúntate: «¿esta línea solo existe porque se cumplió una condición específica, o siempre se va a seguir?». Si la respuesta es «siempre se sigue», tienes una secuencia: útil, pero no es un grafo de verdad.
- •Pipeline: paso 1 → paso 2 → paso 3, siempre en ese orden, sin excepciones
- •Grafo: paso 1 → (si X) paso 2, (si Y) paso 3, (si no es ni X ni Y) vuelve al paso 1
Qué observar: las dos flechas que salen del validador van a lugares diferentes, según una condición. Y es esta bifurcación — no la cantidad de nodos — lo que hace que este dibujo sea un grafo. Si solo existiera la flecha verde, sería solo un pipeline de tres pasos.
Conceptos clave
Carga un «si»
Vive en la arista, no en el nodo
Secuencia sin condición
"¿Esta arista siempre se sigue?"
📦 Define el estado que viaja
¿Qué pasa exactamente de un nodo a otro? Esa pregunta parece pequeña, pero define la mitad del éxito de tu grafo. El esquema de estado — el formato acordado de lo que viaja por las aristas — es un contrato, y los contratos se escriben, no se improvisan.
Pasar toda la conversación de un nodo al otro parece seguro, pero anula la ganancia de contexto limpio: el siguiente nodo vuelve a ver cómo el trabajo se hizo, no solo qué se produjo — y eso llena su contexto de ruido. Pasar menos hace que el siguiente nodo trabaje a ciegas, sin el dato que necesitaba.
Pasar demasiado: toda la conversación
Historial completo de mensajes, razonamiento intermedio e intentos anteriores.
El siguiente nodo gasta tokens leyendo el "cómo" cuando solo necesitaba el "qué". Contexto sucio, mayor costo.
Pasar muy poco: solo un texto suelto
Un campo "resultado" sin estado, sin origen, sin metadatos de confianza.
El siguiente nodo no sabe si aquello pasó por una validación, quién lo generó ni si puede confiar en ello. Trabaja a ciegas.
El punto medio: esquema de estado explícito
Campos con nombre, tipo y responsable: resultado, status, origem.
Cada nodo lee solo los campos que necesita y escribe los campos que es responsable de completar. Eso es un contrato.
💡 Consejo práctico
Escribe el esquema de estado antes de escribir el primer nodo. Si no puedes enumerar los campos que van a circular, todavía no entiendes lo suficiente el flujo como para programarlo y acabarás volcando toda la conversación porque es más fácil que pensar.
Conceptos clave
Formato acordado del estado
Si se escribe, no se improvisa
Anula el contexto limpio
Trabaja a ciegas
⚙️ Configura cada nodo por separado
Modelo, herramientas, permisos, instrucciones y límite de costo (el límite máximo que ese nodo puede gastar antes de que lo interrumpan) pueden ser diferentes en cada nodo. Modelo potente en el paso difícil y barato en el fácil; herramienta de escritura solo en el nodo que escribe; acceso a internet solo para quien investiga.
Esta configuración por nodo es lo que le da valor económico real al grafo — y donde el costo realmente baja. Un sistema que usa el mismo modelo caro en cada paso, solo porque «es más sencillo configurarlo una vez», está quemando dinero en pasos que un modelo barato resolvería igual.
📊 Qué configurar, nodo por nodo
- Modelo — el modelo potente (más caro) solo donde la decisión es realmente difícil
- Herramientas — escritura, ejecución de código, internet: habilitados solo para quien los necesite
- Permisos — quién puede modificar datos sensibles y quién solo puede leerlos
- Límite de costo — límite de tokens/dólares por nodo, para que ningún paso exceda el presupuesto por sí solo
Conceptos clave
Límite máximo por nodo
No es una configuración global
Y donde baja el costo
Solo lo recibe quien lo necesita
🚫 Evita el grafo degenerado
Un grafo de un solo nodo, con todas las herramientas y todas las instrucciones, ejecutándose hasta agotarse: eso es un loop reinventado, y la estructura de grafo no está haciendo nada por ti. Pagaste la complejidad de "pensar en grafo" y no obtuviste ninguno de los beneficios — configuración por nodo, costo diferenciado, enrutamiento condicional.
Prueba práctica: si no puedes asignar configuraciones diferentes a dos nodos de tu diseño, probablemente no necesitabas dos nodos. Únelos. Un grafo degenerado de este tipo no está «mal»: simplemente no es un grafo, sino un loop con un diseño bonito encima.
Qué observar: la ecuación no tiene "menos loop" en ninguna parte: tiene loop más loop más un ingrediente nuevo: el estado explícito que viaja entre ellos (lo que viste en el tema 3). Un grafo de un solo nodo, sin esa composición, es solo un bucle que se hace pasar por un grafo.
⚠️ Atención: complejidad sin beneficio
Si diseñaste cinco nodos pero todos usan el mismo modelo, las mismas herramientas y ninguna arista tiene una condición, no ganaste nada con el diseño: solo pagaste el costo de mantener cinco archivos de configuración en vez de uno. Simplifícalo y vuelve a un loop, o agrega la diferenciación que faltaba.
Conceptos clave
Un nodo, todo permitido
Configuraciones diferentes o únelas
Grafo = loops + estado
El grafo no elimina el loop
📏 Elige la granularidad adecuada (y escribe tu grafo.json)
Demasiado grande y el grafo no ayuda en nada: volviste a la caja negra de un orquestador único que hace todo. Si es demasiado pequeño, pagas un costo de coordinación que supera el trabajo trivial: más aristas, más estado que pasar, más posibilidades de error, sin ninguna ganancia.
Regla práctica: un nodo por cambio de contexto, herramienta o responsabilidad. Si dos pasos usan el mismo contexto y las mismas herramientas, probablemente son un solo nodo. Si un paso cambia de «escribir» a «validar», es un cambio de responsabilidad: son dos nodos.
✓ Sepáralo en dos nodos cuando
- ✓Un paso escribe, el otro valida: son responsabilidades diferentes
- ✓Uno usa un modelo caro; el otro solo necesita un script
- ✓Uno necesita acceso a internet; el otro no puede tenerlo
✗ Júntalo en un solo nodo cuando
- ✗Los dos pasos usan exactamente el mismo modelo y las mismas herramientas
- ✗Solo separaste las partes para «mantenerlas organizadas», sin una diferencia real
- ✗La arista entre ellos nunca tuvo ninguna condición
🧪 Ejemplo práctico: grafo.json con configuración por nodo
Objetivo: evolucionar el esqueleto de grafo introducido en el módulo 1.3, ahora con config por nodo (modelo, herramientas, límite de costo) y aristas con condición quando. Copia y pega en un archivo grafo.json, y léelo con cualquier script.
{
"nos": {
"escritor": {
"modelo": "<modelo-medio>",
"ferramentas": ["escrever_arquivo"],
"teto_custo_usd": 0.05
},
"validador": {
"modelo": "<modelo-forte>",
"ferramentas": [],
"teto_custo_usd": 0.02
},
"formatador": {
"modelo": null,
"ferramentas": ["script_deterministico"],
"teto_custo_usd": 0.00
}
},
"arestas": [
{ "de": "escritor", "para": "validador", "quando": "sempre" },
{ "de": "validador", "para": "formatador", "quando": "resultado_valido == true" },
{ "de": "validador", "para": "escritor", "quando": "resultado_valido == false" }
]
}
Cómo verificar: comprueba que
escritor e validador hay modelos
diferentes ({'<'}modelo-medio{'>'} vs {'<'}modelo-fuerte{'>'}) y que formatador
ni siquiera usa un modelo; es un nodo determinista puro. Si dos de tus nodos tuvieran la misma configuración, se aplica la prueba del tema 5:
júntalos, no necesitabas dos.
Ahora cámbialo por el tuyo: reemplaza
<modelo-medio> e <modelo-forte>
por los nombres reales de tus modelos y las condiciones en quando por las reglas
de negocio de tu flujo. Si queda un nodo sin ninguna condición de salida distinta de las demás, revisa la granularidad.
Verificación rápida (no bloquea nada): tienes dos nodos que usan el mismo modelo, las mismas herramientas y la misma arista de salida incondicional. ¿Qué hacer?
Conceptos clave
Ni grande ni microscópico
Un nodo por cambio de contexto
Condición explícita en la arista
Modelo, herramientas, límite
📌 Resumen del módulo
Próximo módulo:
4.2 — Org graph x work graph: cómo el grafo de agentes refleja (o no) el grafo de personas de tu empresa.