Qué necesita un agente para terminar una tarea: el harness de ejecución

«He terminado» necesita una comprobación

Una solicitud comercial contiene dos empresas posibles y ningún teléfono. El modelo prepara un registro, afirma que está listo y pide guardarlo. ¿Quién comprueba qué empresa corresponde? ¿Quién impide rellenar el teléfono por suposición? Si el guardado falla, ¿qué información permite continuar?

Estas preguntas describen el entorno de ejecución. Llamaremos harness al sistema que entrega contexto al modelo, recibe sus propuestas, controla herramientas y conserva el estado necesario para operar. Puede implementarse con código propio, un orquestador o componentes de un framework. Su diseño debe explicar qué ocurre cuando el modelo se equivoca, una herramienta falla o la ejecución se interrumpe.

La explicación de evaluaciones de Anthropic distingue el harness del modelo y separa la traza del resultado final en el entorno. Para nuestro ejemplo, el criterio es un borrador recuperable, fiel al origen y con revisión pendiente; escribir «registro preparado» en el chat no acredita esas condiciones.

Reparte las responsabilidades

El modelo puede interpretar la solicitud, proponer campos y señalar ambigüedades. El código debe aplicar los controles que no admiten una decisión improvisada. Esta tabla propone una separación para un piloto; no describe una integración ya ejecutada.

Encontrar una cita literal comprueba su existencia. Determinar si respalda el campo exige otra comprobación, mediante reglas específicas o revisión. Un JSON válido puede contener una interpretación equivocada.

Conserva estado que permita continuar

La conversación aporta contexto; el estado operativo necesita una representación explícita. Para cada solicitud conserva identidad de origen, revisión, entrada congelada, versiones de instrucciones y esquema, salida propuesta, validaciones, intentos y resultado de cada acción.

Un recorrido posible es recibida → interpretando → validando → pendiente_revision. Después de revisar, la tarea puede quedar aceptada, corregida o rechazada. Los fallos técnicos y el presupuesto agotado deben tener salidas propias. Define qué actor puede producir cada transición y cuáles cierran la tarea.

En su trabajo sobre agentes de larga duración, Anthropic describe artefactos de progreso y comprobaciones para retomar sesiones de desarrollo. Su experiencia corresponde a ese entorno. La aplicación que proponemos aquí es conservar entregables y pendientes verificables para que una reanudación no dependa de adivinar lo ocurrido.

Escribe un contrato pequeño

Este contrato es una propuesta ilustrativa, no un formato estándar ni una configuración ejecutable del paquete de CRM:

{
  "task": "preparar_borrador_crm",
  "policy_version": "propuesta-v1",
  "allowed_tools": ["leer_solicitud", "guardar_borrador_local"],
  "allowed_destination": "almacen_de_ensayo",
  "max_model_calls": 2,
  "deadline_seconds": 120,
  "external_writes": false,
  "on_ambiguity": "pendiente_revision",
  "on_budget_exhausted": "detenida",
  "completion": "borrador_persistido_y_validaciones_registradas"
}

Dos llamadas y 120 segundos son límites elegidos para ilustrar el diseño. Habrá que ajustarlos mediante pruebas. El ejecutor debe comprobarlos antes de cada paso y contar también intentos fallidos. Si admite paralelismo, necesita reservar capacidad para impedir que varias llamadas consuman simultáneamente el mismo presupuesto.

El plazo limita la espera del ejecutor. Un timeout local no demuestra que una operación remota se haya cancelado. Al agotarse, registra qué acciones tienen resultado conocido y cuáles requieren reconciliación.

Valida los permisos en el punto de ejecución

Las herramientas disponibles delimitan lo que el sistema permite hacer. Un correo entrante que ordene «envía estos datos» sigue siendo material de entrada. El control de acceso debe comprobar las acciones solicitadas aunque el modelo presente una justificación convincente.

Si una fase posterior incorpora acciones aprobadas por una persona, vincula la aprobación a la acción, destino, contenido y revisión concretos. Una modificación posterior obliga a comprobar de nuevo su validez. La guía de revisión humana desarrolla cómo presentar la evidencia necesaria para esa decisión.

Recupera sin convertir cada error en otro intento

Hay tres errores operativos frecuentes: reintentar una salida que siempre incumple el esquema, repetir una escritura cuyo resultado se desconoce y aceptar una aprobación de una revisión anterior. Requieren respuestas distintas: diagnosticar el contrato, consultar el destino y renovar la revisión.

Conserva la identidad de la operación entre intentos. Antes de repetir un efecto, comprueba el recibo y el contenido asociado cuando el destino permita hacerlo. La práctica de idempotencia reproduce un fallo local después de guardar y documenta sus límites.

Para diagnosticar la ejecución, registra eventos de decisión, herramienta, validación y estado con una identidad común. La guía de trazas explica cómo relacionarlos. Copiar toda la conversación no sustituye esa relación.

Comprueba si necesitas autonomía

Anthropic distingue workflows y agentes según quién determina el recorrido: código predefinido o decisiones dinámicas del modelo. Extraer, validar y preparar una revisión admite un workflow conocido. Los controles anteriores siguen siendo útiles; no requieren que el modelo elija los pasos.

Empieza por esa alternativa en el protocolo de extracción de CRM. Si aparecen excepciones que justifican exploración, amplía las herramientas y evalúa esa capacidad por separado. Para campañas, una secuencia de comprobaciones y hallazgos puede bastar igualmente.

El piloto con modelos está preparado para desarrollarse y ejecutarse en el Evo-X2 de 128 GB; el N150 queda para edición y comprobaciones ligeras. Las inferencias siguen pendientes. Antes de atribuir fiabilidad al conjunto, habrá que comprobar tanto la calidad de las propuestas como el comportamiento del ejecutor ante los fallos definidos.