Trabajar con un modelo empezó siendo escribir bien una pregunta. Hoy es construir un sistema alrededor del modelo. Entre una cosa y otra hay cinco capas, y cada una apareció cuando la anterior se quedó corta.

Las capas se acumulan, no se sustituyen. Un grafo está hecho de nodos, un nodo bueno es un bucle bien diseñado, y un bucle bueno necesita el harnés debajo haciendo su trabajo. Saltarse una capa de abajo no la elimina: hace que el fallo aparezca más arriba, más tarde y mucho más difícil de depurar.

Ese es también el orden en que conviene subir: no se pasa a la capa siguiente hasta que la anterior se queda corta de verdad.

Es la capa de un solo turno: qué palabras se mandan. Sigue siendo la base, porque las cuatro capas de encima acaban escribiendo prompts; lo que cambia es quién los escribe.

Un prompt sirve cuando lleva cuatro cosas:

• Objetivo concreto, no un tema.
• Restricciones: versión del lenguaje, librerías permitidas, ficheros que no se tocan.
• Formato de salida esperado.
• Criterio de terminado: cómo se sabe que está bien.

Malo:  arregla este código
Bueno: arregla el NullPointerException de PedidoService.calcularTotal,
       explica qué estaba mal, no cambies la firma pública del método
       y deja pasando los tests de PedidoServiceTest

El chain-of-thought —pedir que razone paso a paso— era la tercera de la lista, pero los modelos actuales razonan solos: hoy no hace falta pedirlo.

Cada conversación empieza de cero. Las reglas del proyecto hay que repetirlas cada vez, la información que cambia hay que pegarla a mano, y seis personas del equipo escriben seis versiones distintas del mismo prompt con seis calidades distintas de resultado.

Ya no es cómo se pregunta, sino qué información ve el modelo al responder. El cuello de botella casi nunca es la redacción: es que al modelo le falta el documento, la fila de la base de datos o la salida de la herramienta que necesitaba.

Las piezas con las que se construye el contexto:

Las dos últimas son el salto importante: con RAG se prepara el contexto por adelantado; con herramientas el modelo lo va pidiendo, que es lo que hace falta cuando no se puede saber de antemano qué información va a necesitar. MCP es el estándar que normaliza esa conexión a herramientas y datos (tema 2).

Un modelo perfectamente informado sigue siendo un modelo: no tiene criterio sobre si lo que va a hacer es peligroso, no duda antes de romper algo y no sabe cuándo parar. Una ventana de contexto más grande no convierte un agente inestable en un sistema fiable.

Harnés es el arnés del escalador: no hace el trabajo, pero si algo sale mal limita el daño. Aquí es el conjunto de reglas, comprobaciones y mecanismos de seguridad alrededor del modelo, para una ejecución.

El cambio de mentalidad es este:

La capa 1 va primera justamente porque no depende de que el modelo se porte bien. Una instrucción se puede ignorar; un contenedor sin permiso de escritura, no. Los hooks (tema 9) son la forma práctica de convertir las capas 1 y 3 en algo que el agente tiene que cumplir.

Un harnés decente usa los dos: lo determinista primero, porque es gratis, y el modelo juez solo para lo que no se puede expresar como regla.

• Proyecto personal: solo la capa 2. Un buen fichero de instrucciones, actualizado cada vez que el agente mete la pata.
• Flujo de un equipo: añadir la capa 3. Los mismos tests y linters que se le exigen al código humano, como puerta.
• El agente toca datos o servicios: añadir las capas 1 y 4.
• Sistema de cara al cliente o sensible: añadir la capa 5, con revisión humana final.

El harnés hace que una ejecución sea fiable, pero sigue dando por supuesto que hay una persona lanzándola, leyendo el resultado y decidiendo qué se hace después.

Aquí el humano deja de apretar el botón. En vez de escribir un prompt, leer la respuesta y escribir el siguiente, se construye un sistema pequeño que hace ese ciclo: mira qué queda pendiente, decide qué intentar, se lo pasa al agente, comprueba si el resultado cumple el objetivo, guarda lo aprendido y vuelve a empezar o para.

La versión mínima de esto es la técnica Ralph: un while de shell que arranca una instancia nueva del agente en cada vuelta con el mismo prompt contra una especificación escrita, que coge una tarea, la implementa y termina. Sin memoria entre vueltas salvo lo que quede escrito en disco. Parece demasiado simple para funcionar, y funciona.

1. El objetivo tiene que ser demostrable, no solo enunciado. «Mejora el proceso de compra» no le da al bucle nada contra lo que comprobarse, así que parará cuando le parezca. Hay que escribir el estado final esperado, la prueba de que se ha alcanzado y las reglas que no se pueden romper por el camino.
2. El verificador es el cuello de botella real, no el modelo. Un bucle vale exactamente lo que valga su capacidad de distinguir trabajo bueno de trabajo malo. Con una comprobación débil, marcará como hecho lo que está roto y seguirá adelante. La mayor parte del esfuerzo de ingeniería se va ahí, no al prompt.
3. Límites duros: número de vueltas, tope de gasto, tiempo máximo.

El bucle diseña el ciclo de un agente. El grafo diseña cómo se conectan varios. Tres piezas:

• Nodos — quien hace el trabajo: un agente especializado (investigador, redactor, revisor) o un paso determinista, como una llamada a una herramienta.
• Aristas — el encaminamiento: entrega directa, rama condicional, fan-out a varios nodos a la vez, fan-in que vuelve a juntar los resultados.
• Estado compartido — el objeto que viaja por las aristas. Es lo que convierte un montón de agentes en un sistema en vez de en un grupo de asistentes que se olvidan de todo al pasarse el trabajo.

No confundirlo con un knowledge graph ni con GraphRAG: aquellos modelan datos y sus relaciones para recuperarlos; esto modela la ejecución, qué nodo corre después y con qué estado.

La respuesta honesta por defecto es que no. Lo normal es que un agente bien acotado con un buen verificador baste, y adelantarse al grafo es cómo una tarea de dos horas se convierte en un proyecto de dos semanas de framework.

Si la mayoría de las respuestas sinceras caen en la columna de la izquierda, es un bucle al que alguien ha convencido de que necesitaba arquitectura.

Un grafo implícito sigue siendo un grafo: simplemente no se ve hasta que algo se rompe. Mejor un framework que obligue a hacerlo explícito que uno propio que lo esconda.

1. Intenta que siga siendo un bucle. Si un agente bien acotado con un verificador decente hace el trabajo, para ahí.
2. Un nodo solo se crea si es una especialidad de verdad, otro modelo, otras herramientas o un revisor de solo lectura. Un paso que podrías meter dentro de otro no es un nodo.
3. Dibuja las aristas antes de escribir código. Si no cabe en una servilleta, ya es demasiado complejo.
4. Diseña el estado compartido a propósito y decide quién puede escribir en él. La deriva del estado es la forma más rápida de pudrir un grafo.
5. Dale dientes al revisor: un agente distinto del que produjo el trabajo, no el mismo poniéndose la nota.
6. Aísla los fallos: un nodo malo reintenta sin corromper el estado ni contaminar el resto de la ejecución.

• Prompt: una petición bien hecha. Objetivo, restricciones, formato, criterio de terminado.
• Contexto: exactamente la información necesaria, ni más ni menos. Instrucciones del proyecto, recuperación y herramientas.
• Harnés: límites, instrucciones, comprobaciones, recuperación y revisión alrededor de una ejecución. Cuando falla algo, se cambia el sistema, no la salida.
• Bucle: el sistema decide el paso siguiente. Objetivo demostrable, verificador fuerte y presupuesto con tope.
• Grafo: varios nodos especializados con estado compartido. Solo cuando el trabajo lo pide.

Los patrones concretos para montar todo esto —pipeline, enrutador, planificador-ejecutor, orquestador, ejecutor-revisor, best-of-N, human-in-the-loop— son el tema 5.

• From Prompts to Harnesses: How AI Engineering Has Grown Up
• Loop Engineering: The Layer After Prompt, Context, and Harness Engineering
• Graph Engineering: The Layer After Loop Engineering
• Trust No Agent: Securing Autonomous AI Tools
• MCP vs Skills vs Agents With Scripts