🚦 Revisa las tres señales antes de migrar
Hay exactamente tres señales que autorizan cambiar un loop por un grafo. Ningún otro motivo cuenta: ni "el grafo parece más avanzado" ni "todo el mundo lo está haciendo". Si tu caso no presenta ninguna de las tres, migrar solo te costará complejidad sin obtener nada a cambio.
Necesitas ejecutar partes al mismo tiempo
Buscar en tres fuentes, generar dos variaciones, verificar dos criterios independientes: trabajo que no depende entre sí y que un loop secuencial solo puede hacer de a uno.
Necesitas un revisor que NO vea cómo se hizo el trabajo
En un loop con un solo contexto, quien revisa carga el mismo razonamiento de quien escribió, y tiende a aprobar su propio trabajo. Una revisión ciega exige un contexto limpio: uno que solo recibe el resultado, nunca el camino hasta él.
El contexto se está convirtiendo en un pantano
Después de muchas vueltas en el mismo loop, el agente acumula tantas cosas en el contexto que pierde la instrucción original; empieza a «olvidar» el objetivo. Es señal de que una responsabilidad debe pasar a otro nodo, con su propio contexto.
🆕 ¿Nuevo aquí? Dos palabras antes de seguir
- Línea de base: los números de la versión actual (costo, tiempo, calidad) medidos ANTES de cualquier cambio; sin eso nunca sabrás si una migración valió la pena.
- Contexto limpio: un nodo que recibe solo lo que necesita para hacer su trabajo — nunca el razonamiento ni el borrador de quien hizo la etapa anterior.
✓ Señales que autorizan la migración
- ✓Hay trabajo independiente que hoy se ejecuta en fila
- ✓Necesitas un juicio que no vea el borrador
- ✓El agente pierde la instrucción original después de N vueltas
✗ Señales de que el problema es otro
- ✗"Está lento" — primero, depura: puede ser un prompt malo, no la arquitectura
- ✗"El verificador aprueba cualquier cosa" — cambia el verificador, no la estructura
- ✗"Parece más profesional tener varios agentes" — la moda no es ingeniería
Conceptos clave
Paralelismo, revisor ciego, pantano
La moda no autoriza migrar
Casi siempre es el verdadero culpable
La base de la revisión a ciegas
📏 Mide antes de cambiar
Antes de tocar cualquier código, anota tres números de la versión actual: costo por ejecución (tokens o dólares), tiempo total (de principio a fin) es una medida de calidad que puedas verificar por tu cuenta — por ejemplo, cuántas afirmaciones del resumen verificaste manualmente y eran correctas, de 10.
Migrar sin línea base es fe, no ingeniería. Sin estos tres números, nunca sabrás si el grafo aportó algo real o si solo cambió un problema por otro: más bonito, más caro.
📊 Los tres números que tienes que anotar
- Costo por ejecución — tokens consumidos o dólares gastados en una ronda típica
- Tiempo total — desde el disparador hasta el resultado final listo
- Calidad verificable — una muestra que tú mismo verificas (p. ej., 10 afirmaciones: cuántas coinciden)
🧪 Ejemplo práctico: la hoja de cálculo de referencia
Objetivo: registra los tres números de la versión actual (el loop) antes de migrar, y el mismo bloque después — para comparar de verdad en el tema 6.
// linha-de-base.json — preencha ANTES de migrar
{
"versao": "loop",
"data": "<aaaa-mm-dd>",
"custo_por_execucao_usd": <numero>,
"tempo_total_min": <numero>,
"qualidade": {
"amostra": 10,
"afirmacoes_corretas": <numero de 0 a 10>
},
"observacoes": "<o que voce notou rodando 3-5 vezes>"
}
// linha-de-base.json — preencha DEPOIS de migrar, MESMAS entradas
{
"versao": "grafo",
"data": "<aaaa-mm-dd>",
"custo_por_execucao_usd": <numero>,
"tempo_total_min": <numero>,
"qualidade": {
"amostra": 10,
"afirmacoes_corretas": <numero de 0 a 10>
},
"observacoes": "<o que mudou de verdade>"
}
Cómo verificar: ejecuta cada versión de 3 a 5 veces con las mismas entradas antes de anotar — un único número puede ser cuestión de suerte. Si ahora no puedes completar los tres campos de la versión actual, detente: mide primero, migra después.
💡 Consejo práctico
No existe una métrica de calidad perfecta. La regla es simple: elige algo que puedas comprobar por tu cuenta sin una herramienta nueva y usa el mismo criterio en ambas versiones. Cambiar de métrica a mitad del proceso invalida la comparación.
Conceptos clave
Números ANTES de migrar
Costo, tiempo, calidad
Sin herramientas nuevas
Un número por sí solo puede ser casualidad
✂️ Haz cortes en los puntos de cambio de contexto
Divide el loop donde cambia la responsabilidad, a herramienta o el contexto necesario. No dividas en puntos arbitrarios — cada corte tiene que corresponder a uno de estos tres cambios; de lo contrario, solo creaste más nodos sin aportar más claridad.
Para el resumen diario, esto da tres nodos naturales: quién búsqueda (necesita internet, produce notas), quien escribe (no necesita internet, solo necesita las notas), quien comprueba (necesita internet de nuevo para verificar datos, pero NO puede ver cómo se hace el borrador).
Qué observar: a la izquierda, todo apilado en un solo contexto: búsqueda, HTML sin procesar, borrador y revisión amontonados, girando en la misma flecha. A la derecha, tres cuadros separados: el investigador tiene un abanico de fuentes en cian (puede ejecutarse en paralelo), pasa notas para el escritor, que devuelve un borrador para el revisor. Solo la arista roja vuelve — y con un límite (max 2) y una etiqueta de lo que transporta.
⚠️ Corte incorrecto: dividir porque «queda bonito»
Si no puedes señalar cuál de las tres cosas cambió (responsabilidad, herramienta, contexto) en una división, es artificial. Un grafo con nodos artificiales es peor que el loop original: más prompts que escribir, más aristas que mantener y ninguna mejora real.
Conceptos clave
Responsabilidad, herramienta, contexto
Necesita internet, produce notas
Solo necesita las notas
Internet otra vez, pero con el contexto limpio
📜 Escribe el contrato entre los nodos
Antes de escribir cualquier código, define qué lleva cada arista: esto es el esquema de estado, el formato exacto del dato que pasa de un nodo al siguiente. Quien investiga entrega notas (no HTML sin procesar — ese pantano que vuelve por la puerta trasera); quien escribe entrega borrador; el revisor devuelve aprobado + críticas.
Escribe también lo que explícitamente NO pasa: el razonamiento del escritor no va al revisor. Eso no es un detalle — es la diferencia entre un revisor de verdad y uno que solo está de acuerdo con quien escribió.
🧪 Ejemplo práctico: el grafo.json del resumen diario migrado
Objetivo: ver el contrato completo: tres nodos con su propia configuración y las aristas con condición (quando), payload (passa) y límite de iteraciones (max_voltas).
// grafo.json — resumo diario migrado (loop -> grafo)
{
"nos": {
"pesquisador": {
"modelo": "<modelo-rapido>",
"ferramentas": ["busca_web", "leitor_rss"],
"contexto_limpo": false,
"produz": "notas"
},
"escritor": {
"modelo": "<modelo-de-escrita>",
"ferramentas": [],
"contexto_limpo": false,
"recebe": "notas",
"produz": "rascunho"
},
"revisor": {
"modelo": "<modelo-rapido>",
"ferramentas": ["busca_web"],
"contexto_limpo": true,
"recebe": "rascunho",
"produz": "aprovado_ou_criticas"
}
},
"arestas": [
{ "de": "pesquisador", "para": "escritor", "passa": "notas" },
{ "de": "escritor", "para": "revisor", "passa": "rascunho" },
{
"de": "revisor", "para": "escritor",
"quando": "aprovado == false",
"passa": "criticas",
"max_voltas": 2
}
]
}
Cómo verificar: si el revisor recibe algún campo
además del texto y el criterio (por ejemplo, las notas del investigador o el historial de intentos del escritor), el contexto
contexto_limpo no está cumpliendo lo que promete, y no vas a ganar nada con la migración,
porque el sesgo de «aprobar su propio trabajo» sigue ahí, solo que repartido entre dos nodos.
💡 El contrato es lo que queda cuando pasa el hype
Los frameworks de grafos van y vienen. Lo que queda es la disciplina de decir, por escrito, qué lleva cada arista y qué nunca debería llevar. Si escribes esto antes del código, la implementación se convierte en una traducción mecánica; si te saltas este paso, el código se convierte en el único lugar donde existe el contrato — y nadie revisa el código pensando en el contrato.
Conceptos clave
Formato exacto del dato en la arista
Demasiado bruto y vuelve el pantano
El razonamiento queda con quien lo generó
Escribe primero el contrato
🔁 Agrega la arista de vuelta con un límite
El revisor que rechaza devuelve el trabajo al escritor: esa es la arista de retorno, el ciclo dentro del grafo. Necesita en un máximo de N vueltas y es de un criterio de progreso: "dos vueltas sin mejorar = abandona y avísame" es un criterio; "intenta hasta que funcione" no lo es.
Sin límite, la factura es infinita: el mismo problema de cualquier ciclo sin condición de parada. Sin un criterio de progreso, pagas N vueltas incluso cuando dos ya bastaban para saber que eso no va a mejorar.
Qué observar: fíjate en que hay dos preguntas, no una. La primera filtra a quienes ni siquiera necesitaban cambiar nada (mejora el verificador). Solo si llegas a la segunda pregunta y respondes "sí" aparece la caja con brillo — "construye el grafo" — y la migración queda autorizada. Cualquier otro camino te lleva de vuelta al loop o a un problema que ningún grafo puede resolver.
⚠️ Sin límite, la factura es infinita
Toda arista de retorno que dibujes debe llevar al lado el número máximo de iteraciones y el criterio que la termina antes de llegar a ese máximo. Si no puedes escribir esas dos cosas en una frase, la arista todavía no está lista para producción.
Conceptos clave
Máximo N, nunca infinito
Cuándo desistir antes del límite
No se bloquea: notifica y se detiene
El loop vive dentro del grafo
⚖️ Compara y ten el valor de dar marcha atrás
Ejecuta ambos —bucle y grafo— en paralelo durante algunos días, con las las mismas entradas. Vuelve a completar la misma hoja de cálculo de línea de base del tema 2. Si el grafo no mejoró ninguno de los tres números, vuelve al bucle: compraste complejidad sin obtener nada a cambio.
Admitirlo es parte del trabajo, no un fracaso. Es lo que separa la ingeniería de la moda: la ingeniería mide y decide según el número; la moda decide por la apariencia y defiende la decisión después.
Verifica las tres señales
Paralelismo, revisor ciego o pantano de contexto: si falta uno de los tres, no migres.
Mide la línea base
Costo, tiempo y calidad verificable de la versión loop, repetidos 3-5x.
Corte en los puntos correctos
Responsabilidad, herramienta o contexto: nunca un corte arbitrario.
Escribe el contrato
Lo que lleva cada arista y lo que explícitamente no lleva.
Agrega la arista de vuelta con un límite
Máximo N vueltas + criterio de progreso, nunca «intenta hasta que funcione».
Compara y decide
Mismas entradas, misma hoja de cálculo. Si no hay mejoras en los tres números, vuelve al ciclo.
✓ Quédate con el grafo si
- ✓El tiempo total se redujo gracias al paralelismo real
- ✓La calidad subió porque el revisor de verdad no veía el borrador
- ✓El costo compensa el beneficio: comparaste ambas cifras lado a lado
✗ Vuelve al bucle si
- ✗El costo subió y ninguna de las otras dos cifras mejoró
- ✗La calidad es igual, solo que ahora hay más piezas que mantener
- ✗No sabes decir qué mejoró: señal de que no mediste bien
Verificación rápida (no bloquea nada): migraste un resumen diario al grafo de 3 nodos, pero el costo por ejecución se duplicó y la calidad quedó igual. ¿Qué hacer?
Conceptos clave
Una comparación justa exige esto
Costo, tiempo, calidad: otra vez
Y es parte del método
El número decide, no la apariencia
📌 Resumen del módulo
Próximo módulo:
5.2 — Grafos de negocio y de tareas: modelar el embudo multimétrica y el backlog con depende/bloquea.