Ya sabes qué son un nodo, una arista, un estado, un verificador y un límite de costo; fue todo el curso. Este módulo no enseña conceptos nuevos. Lo empaqueta todo en seis prompts de copiar y ejecutar, cada uno resuelve una parte concreta del trabajo de ingeniería de grafos. Usa la tabla de abajo para encontrar rápidamente qué prompt sirve para lo que tienes entre manos ahora.
| Prompt | Úsalo cuando | Lo que devuelve |
|---|---|---|
| 1. Diseña el grafo | Tienes un proceso descrito en texto corrido, sin estructura | JSON con nodos, aristas y preguntas sobre ambigüedades |
| 2. El grafo se convierte en script | Ya tienes un grafo.json y quieres el código que lo ejecuta | Script que recorre el grafo con un límite de costo y de vueltas |
| 3. Audita el grafo | Quieres encontrar defectos antes de ejecutar en producción | Lista de los cinco defectos estructurales, uno por uno |
| 4. Colisión entre loops | Tienes varios objetivos automatizados ejecutándose al mismo tiempo | Pares en tensión, métrica-efecto secundario, restricción faltante |
| 5. Esquema de estado | Dos nodos vecinos y no sabes qué pasa entre ellos | Contrato de la arista en JSON Schema, con lo que NO debe pasar |
| 6. Primero el verificador | Un agente que entrega algo malo y tú no sabes cómo medirlo | Verificador + caso de prueba fallido; solo después, el prompt del agente |
Qué observar: el cuadro de arriba solo tiene cinco salidas: siempre partes de lo que tienes (texto, grafo.json, lista de objetivos, dos nodos o una salida mala), no de lo que quieres producir. Fíjate también en que dos ramas (grafo.json) llevan a prompts diferentes: una audita y la otra ejecuta. Son etapas distintas.
Contenido detallado
🗺️ Diseña el grafo de mi proceso
Objetivo: describes un proceso a tu manera, en texto corrido, como se lo explicarías a un colega nuevo. El agente devuelve la primera versión estructurada: nodos, aristas y una lista de lo que quedó ambiguo. Úsalo cuando todavía no existe ningún grafo, solo el desorden en tu cabeza.
Voce e um engenheiro de grafos. Vou colar a descricao de um processo em texto
corrido. Sua tarefa:
1. Identifique os NOS — cada unidade de trabalho, decisao ou papel envolvido.
2. Identifique as ARESTAS — o que liga um no a outro, e QUANDO essa aresta e
seguida (nunca escreva uma aresta sem a condicao "quando").
3. Devolva SOMENTE um JSON no formato abaixo, sem comentario fora do JSON:
{
"nos": [
{ "id": "<nome-curto>", "papel": "<o que esse no faz>",
"modelo_sugerido": "<ex: gpt-4o-mini, claude-haiku, humano>",
"ferramentas": ["<ferramenta 1>", "<ferramenta 2>"] }
],
"arestas": [
{ "de": "<id do no de origem>", "para": "<id do no de destino>",
"quando": "<condicao exata, nunca 'sempre' se houver alternativa>",
"passa": "<o que atravessa essa aresta — que dado>" }
],
"perguntas": [
"<o que ficou ambiguo na minha descricao e precisa de resposta minha>"
]
}
Processo: <cole aqui a descricao em texto corrido do seu processo>
arestas y mira el valor de
quando en cada una. Si TODAS dicen "siempre", el agente dibujó un pipeline
lineal, no tu proceso real — casi todo proceso de más de tres pasos tiene al menos una decisión.
Pídele que vuelva a intentarlo: "identifica dónde hay una decisión real — dónde el camino cambia según alguna condición".
🆕 ¿Nuevo aquí? Dos palabras antes de seguir
- Entrada huérfana: una situación posible que ninguna arista cubre: el flujo llega ahí y no sabe adónde ir. Vuelve a aparecer en el prompt 3.
- Cardinalidad: cuántas cosas deben llegar (o salir) de un nodo para que avance — «todas», «cualquiera» o «al menos N». Aparece en el prompt 3.
Conceptos clave
Texto corrido, sin estructura
JSON: nodos, aristas, preguntas
Todo «cuando» = siempre
Se convierte en grafo.json para el prompt 2/3
⚙️ Convierte el grafo en un script
Objetivo: este es el segundo paso del método de dos etapas — primero tú
dibujas el grafo (prompt 1), después tú generas el código que lo ejecuta de verdad. Usa este cuando ya tienes un
grafo.json aprobado y quiere salir del papel para ponerse en marcha.
Aqui esta o grafo.json de um processo (colado abaixo). Escreva um script em <Python ou Node, escolha> que: 1. Carregue esse grafo.json. 2. Percorra os nos a partir de "<no-inicial>", respeitando a condicao "quando" de cada aresta antes de segui-la. 3. Para cada no, execute a acao descrita em "papel" (pode ser uma chamada de LLM, uma funcao, ou um print de placeholder se ainda nao tiver a implementacao real). 4. Aplique um TETO DE CUSTO total (em <tokens ou dolares>, defina um valor) — se ultrapassar, pare e reporte onde parou. 5. Para toda aresta de volta (uma aresta cujo destino ja foi visitado antes no mesmo caminho), exija um campo "max_voltas" no grafo.json e FALHE explicitamente se esse campo nao existir naquela aresta. 6. Logue cada no executado com: nome do no, duracao em ms, custo estimado, timestamp. grafo.json: <cole aqui o conteudo do seu grafo.json>
max_voltas
de una sola arista de vuelta y vuelve a ejecutar el script. TIENE que fallar a propósito, con un mensaje claro
que señale qué arista no tiene límite. Si se ejecuta igual (o entra en un loop silencioso), el script no
implementó el bloqueo: pídele explícitamente que agregue esa verificación.
💡 Consejo práctico
Pide siempre el log estructurado (nombre, duración, costo, timestamp), incluso en un borrador. Es el embrión de tu observabilidad (módulo 4.3): sin log por nodo, nunca sabrás qué paso consumió el presupuesto cuando el grafo crezca.
Conceptos clave
Diseña y luego ejecuta
Se detiene y avisa cuando se excede el límite
Obligatorio en una arista de retorno
Duración, costo, marca de tiempo
🔍 Audita mi grafo
Objetivo: busca cinco defectos estructurales específicos en un grafo.json antes de que pase a producción. Usa este prompt antes de ejecutar cualquier cosa con un costo real y antes de mostrarle el grafo al equipo como si estuviera listo.
Audite o grafo.json abaixo. Procure especificamente estes cinco defeitos — nao pule nenhum, mesmo que o grafo pareca limpo: 1. CICLO SEM TETO DE VOLTAS — alguma aresta de volta (destino ja visitado) sem campo "max_voltas"? 2. ARESTA CONDICIONAL SEM "QUANDO" — alguma aresta com valor generico tipo "sempre" ou "quando" ausente, saindo de um no que tem mais de uma aresta de saida? 3. ENTRADA ORFA — existe alguma combinacao de condicoes que NENHUMA aresta cobre? (ex: no de decisao com "aprovado"/"reprovado" mas falta o caso "sem resposta") 4. JUNCAO SEM CHECAGEM DE CARDINALIDADE — algum no recebe de multiplas arestas (fan-in) sem dizer se precisa de TODAS chegarem, QUALQUER UMA, ou um numero minimo? 5. NO SEM TETO DE CUSTO — algum no (principalmente os que chamam LLM ou ferramenta externa) sem limite de custo/tokens/tempo definido? Para cada defeito encontrado, aponte: o id do no/aresta exato, por que e um problema, e uma correcao sugerida em uma frase. Se nao encontrar nenhum defeito de um tipo, diga explicitamente "nao encontrado" para aquele tipo — nao pule a categoria. grafo.json: <cole aqui o conteudo do seu grafo.json>
✓ Auditoría bien aplicada
- ✓Ejecutarlo antes de cada cambio grande en el grafo, no solo en la primera versión
- ✓Probar periódicamente el prompt con un grafo roto a propósito
- ✓Guardar explícitamente el «no encontrado»: se convierte en un historial de lo que ya se verificó
✗ Auditoría mal aplicada
- ✗Ejecutarlo una vez y nunca más, aunque el grafo cambie cada semana
- ✗Aceptar «parece que todo está bien» sin pasar por las cinco categorías
- ✗Ejecutarlo solo en el propio grafo: nunca probarlo con un caso roto conocido
Conceptos clave
Ciclo, condición, nodo huérfano, cardinalidad, costo
Caso que ninguna arista cubre
Todas × cualquiera × mínimo N
Contra un grafo roto a propósito
💥 Encuentra la colisión entre bucles
Objetivo: enumeras los objetivos automatizados (loops o agentes) que ya se ejecutan en tu operación, y el agente señala cuáles se presionan mutuamente, qué métrica de uno es un efecto colateral del otro y qué restricción entre métricas falta. Úsalo cuando hay más de un loop ejecutándose al mismo tiempo: el escenario del módulo 2.3, pero aplicado a tu caso.
Aqui esta a lista de objetivos automatizados (loops ou agentes) que rodam na minha operacao hoje: 1. <objetivo 1 — ex: "loop de suporte: fecha ticket em menos de 2h"> 2. <objetivo 2 — ex: "loop de vendas: maximiza conversao do funil"> 3. <objetivo 3 — ex: "loop de qualidade: reduz taxa de reembolso"> Para cada PAR desses objetivos, responda: 1. Eles se PRESSIONAM MUTUAMENTE? Ou seja, otimizar um piora o outro? 2. Existe alguma METRICA que e efeito colateral direto de outro loop? (ex: "tempo de fechamento" cai, mas "reincidencia" sobe) 3. Que RESTRICAO entre metricas esta faltando no meu sistema hoje? (ex: "fechar rapido, MAS reincidencia abaixo de X%") Nao me diga que nao ha colisao nenhuma sem antes checar cada par explicitamente, um por um, e escrever o resultado do par.
⚠️ El agente está de acuerdo contigo por defecto
Esta es la razón por la que existe cada sección de «cómo verificar» en este módulo: un modelo de lenguaje tiende a validar tu pregunta, no a cuestionarla. Si preguntas «¿hay una colisión?» de una forma que suena como si ya esperaras un «no», es probable que responda «no» incluso cuando sí la hay. Formula el prompt para exigir una comprobación explícita — como hicimos aquí, pidiendo comparar cada par — en vez de aceptar un veredicto general.
Conceptos clave
Verificación explícita, no veredicto general
Métrica de uno que reacciona al otro
El «pero» que le falta a tu sistema
Siempre hay tensión en algún par
📐 Escribe el state schema entre dos nodos
Objetivo: dados dos nodos vecinos, este prompt define el contrato exacto de la arista entre ellos: nombres de los campos, formato, qué es obligatorio y qué explícitamente NO debe pasar. Úsalo cuando dos nodos «no se entienden»: uno envía demasiados datos, muy pocos o en el formato equivocado.
🆕 ¿Nuevo aquí? Una palabra antes de seguir
- State schema: la definición formal de lo que pasa por una arista: como un contrato entre dos nodos que dice exactamente qué campos, en qué formato y qué queda fuera. Sin eso, cada nodo interpreta los datos de manera diferente.
Dados estes dois nos vizinhos do meu grafo: NO A (origem): <nome e o que ele faz> NO B (destino): <nome e o que ele faz> Escreva o STATE SCHEMA da aresta entre eles — o contrato exato do que atravessa essa ligacao. Devolva: 1. CAMPOS — nome de cada campo que passa de A para B. 2. FORMATO — tipo de cada campo (string, numero, enum, lista, objeto) e um exemplo de valor. 3. OBRIGATORIO x OPCIONAL — quais campos B nao funciona sem, quais sao so contexto extra. 4. O QUE EXPLICITAMENTE NAO DEVE PASSAR — liste pelo menos 3 coisas que A NAO deve mandar pra B (ex: raciocinio bruto do modelo, saida crua de ferramenta, historico completo da conversa) e por que cada uma incharia ou confundiria o no B. Devolva em JSON Schema simplificado, pronto pra colar como validacao.
Conceptos clave
Lo que atraviesa, formato y obligatoriedad
Siempre hay algo: nunca una lista vacía
Formato listo para validar en código
Un par a la vez, no todo el grafo
✅ Escribe el verificador antes del prompt
Objetivo: invierte el orden normal de trabajo. En vez de escribir el prompt del agente y solo después pensar cómo evaluar el resultado, primero escribes cómo vas a saber que funcionó — con un caso de prueba negativo incluido — y solo entonces pide el prompt del agente. Usa este cuando un agente ya está entregando resultados deficientes y te das cuenta de que nunca definiste realmente qué significa «bueno» en ese caso.
🆕 ¿Nuevo aquí? Una palabra antes de seguir
- Caso de prueba incorrecto: un ejemplo de salida que parece buena a primera vista, pero está mal — la verdadera prueba de un verificador no es aprobar el caso bueno, sino rechazar el caso engañoso.
Antes de escrever o prompt do agente, quero o VERIFICADOR primeiro. O no vai fazer: <descreva a tarefa do no, ex: "resumir um ticket de suporte em ate 3 frases">. 1. Escreva uma funcao ou checklist de verificacao que recebe a SAIDA do no e devolve aprovado/reprovado com o motivo. 2. Inclua pelo menos um CASO RUIM DE TESTE — um exemplo de saida que PARECE boa a primeira vista mas esta errada (ex: resumo de 3 frases que omite a informacao mais importante do ticket), e o verificador tem que reprovar esse caso. 3. SO DEPOIS escreva o prompt do agente que gera essa saida. Devolva nesta ordem: (a) verificador, (b) caso ruim de teste + resultado esperado do verificador nesse caso, (c) prompt do agente.
⚠️ Este es el prompt más importante de la biblioteca
Todos los «cómo verificar» de este módulo existen porque un agente tiende a darte la razón cuando el prompt es impreciso, y un verificador escrito después del agente, sin un caso desfavorable, hereda esa misma imprecisión. Escribir el verificador primero, con un caso que engañe, es la única forma de saber si realmente está midiendo algo o solo validando lo que ya esperabas ver.
Verificación rápida (no bloquea nada): escribiste un verificador, lo probaste con el caso malo y, aun así, aprobó el caso malo. ¿Qué significa eso?
Conceptos clave
Verificador antes del prompt
Parece bueno, está mal
Aprueba el caso malo = falla
El loop no pasa del verificador
📌 Resumen del módulo
🎯 Fin del curso — lo que queda
Uno loop ya es un grafo — un grafo cuyo camino vuelve a un nodo anterior. No pasas de ciclos a grafos como si fuera una graduación; tú compone bucles en grafos cuando un bucle deja de ser suficiente, y eso se paga con nuevos prompts, esquemas de estado y modos de falla. Ajusta primero el bucle. Solo entonces vale la pena componer.
Y el mensaje final del curso: quien sabe qué son un nodo y una arista asimila el próximo término de moda en cinco minutos: lee el anuncio, encuentra el nodo y la arista debajo del nombre nuevo y sigue trabajando. Quien no lo sabe deja todo para volver a estudiar cada semana. La IA es una palanca de lo que ya sabes, no un sustituto de conocer los fundamentos.