Definir objetivo, entorno y criterios de terminación

Un agente con un objetivo ambiguo puede ejecutar muchas acciones razonables y aun así no completar la tarea correcta. Antes de diseñar tools necesitas definir qué significa «terminar», qué entorno puede observar y qué límites no puede superar.

El contrato del agente debe ser más preciso que un prompt de usuario.

Define el objetivo operativo

Evita:

«Investiga el problema del cliente.»

Prefiere:

«Identifica la causa más probable de la incidencia, reúne evidencia de los sistemas autorizados, propone una resolución y detente antes de ejecutar cualquier cambio.»

El objetivo contiene:

• resultado;
• evidencia;
• límites;
• efectos prohibidos.

Define el entorno

Anthropic señala que el comportamiento de un agente depende del modelo, el harness, las herramientas y el entorno. Ese entorno debe documentarse.

Incluye:

• archivos accesibles;
• repositorios;
• APIs;
• red;
• shell o sandbox;
• bases de datos;
• credenciales;
• tenant;
• recursos temporales;
• herramientas externas.

Dos agentes con el mismo prompt pueden tener riesgos muy distintos si uno solo lee documentación y otro dispone de terminal, email y CRM.

Define estados terminales

No uses únicamente «done».

Ejemplos:

SUCCEEDED Se cumplió el objetivo y la evidencia supera el criterio mínimo.

NEEDS_INPUT Falta información del usuario.

NEEDS_APPROVAL El siguiente paso tiene un efecto que requiere autorización.

BLOCKED No existe acceso o dependencia necesaria.

OUT_OF_SCOPE La tarea excede el contrato.

BUDGET_EXCEEDED Se alcanzó límite de coste, tiempo o pasos.

FAILED Existe un error que no puede recuperarse dentro del run.

La terminación explícita evita loops indefinidos.

Define condiciones de parada

Un agente debe detenerse cuando:

• objetivo completado;
• no existe siguiente acción útil;
• evidencia insuficiente;
• encuentra un conflicto que necesita una decisión humana;
• debe realizar una acción sensible;
• supera pasos;
• supera tiempo;
• supera coste;
• repite estados;
• detecta riesgo;
• pierde una dependencia.

No dependas de que el modelo «se dé cuenta».

El harness puede aplicar límites deterministas.

Define presupuestos

Ejemplo:

max_turns: 12
max_tool_calls: 20
max_write_actions: 1
max_elapsed_time: 5 min
max_cost: X

Los valores dependen del caso. Lo importante es tenerlos.

También puedes establecer presupuestos por tool: muchas lecturas, pocas escrituras.

Define invariantes

Las invariantes no cambian aunque el agente cambie de plan.

Ejemplos:

• nunca acceder a otro tenant;
• nunca enviar email sin aprobación;
• nunca borrar;
• nunca modificar datos históricos;
• nunca usar fuentes no autorizadas;
• nunca almacenar secretos en memoria persistente.

Estas reglas pertenecen al código y la política, no solo al prompt.

Define criterios de éxito

Un outcome verificable puede ser:

• existe un fichero válido;
• la tarea aparece en el CRM;
• una prueba pasa;
• una incidencia queda clasificada con evidencia;
• una reserva existe;
• un conjunto de campos está completo.

Evita usar como único criterio:

«El agente dice que terminó.»

La evaluación de agentes distingue precisamente entre transcript y outcome del entorno.

Diseña checkpoints

En tareas largas, divide:

1. comprender;
2. plan preliminar;
3. recopilar evidencia;
4. ejecutar cambios;
5. verificar;
6. cerrar.

Puedes persistir checkpoints para recuperación.

No necesitas mostrar cada plan al usuario. Pero el sistema debe saber en qué fase se encuentra.

Ejemplo

Agente de diagnóstico:

Objetivo:

• localizar causa de fallo;
• aportar evidencias;
• proponer arreglo.

Puede:

• leer logs;
• consultar base read-only;
• buscar documentación.

No puede:

• reiniciar producción;
• cambiar configuración;
• escribir en la BD.

Termina cuando:

• existe causa respaldada;
• no puede continuar;
• necesita aprobación.

Distingue objetivo, criterio y preferencia

No todas las instrucciones tienen la misma fuerza.

Objetivo: qué debe conseguir el sistema.

Restricción: qué no puede violar.

Criterio de éxito: cómo se comprueba.

Preferencia: qué opción es deseable si varias funcionan.

Ejemplo:

Objetivo: preparar un informe de causa raíz.
Restricción: no modificar producción.
Criterio: cada conclusión debe tener evidencia.
Preferencia: minimizar llamadas externas.

Si todo aparece mezclado en una frase, el modelo puede tratar una preferencia como requisito o ignorar una restricción al perseguir el objetivo.

Modela incertidumbre

Un agente no siempre debe seguir actuando hasta «resolver».

Define estados para:

• evidencia insuficiente;
• hipótesis en conflicto;
• dato ambiguo;
• recurso inaccesible;
• usuario que debe aclarar.

Pedir una aclaración puede ser una acción correcta.

El contrato debe indicar qué incertidumbre puede resolver el agente con herramientas y cuál exige intervención.

Separa progreso de actividad

Diez tool calls no significan progreso.

Define marcadores:

• nueva evidencia;
• hipótesis descartada;
• subtarea terminada;
• artifact actualizado;
• verificación completada.

El harness puede detectar actividad repetitiva sin mejora.

Diseña objetivos resistentes a reward hacking

Un agente puede encontrar una manera fácil de cumplir una métrica mal especificada.

Ejemplo:

Objetivo mal definido:

«Cierra todos los tickets.»

Podría cerrarlos sin resolver.

Mejor:

«Resuelve o escala cada ticket de acuerdo con criterios X, con evidencia y sin cerrar si falta validación.»

Piensa en cómo podría cumplir literalmente el objetivo de forma no deseada.

Versiona el contrato

Cuando cambies:

• tools;
• límites;
• objetivo;
• entorno;
• criterio de éxito;

incrementa la versión del contrato.

Las evaluaciones deben registrar qué contrato probaron.

Ejercicio

Escribe un contrato con:

• objetivo;
• inputs;
• entorno;
• tools;
• permisos;
• estados terminales;
• límites;
• invariantes;
• criterios de éxito;
• condiciones de escalado;
• checkpoints.

Después intenta encontrar tres maneras de que el agente «cumpla el prompt» pero viole la intención. Añade controles.

Entregable

El entregable de esta lección es un agente acotado por un contrato de ejecución. En la siguiente lección convertirás ese contrato en herramientas y observaciones que permitan actuar sin conceder capacidades generales.