harness de la ingeniería en la práctica: seis planes para transformar la intención en evidencia

Un agente recibe una tarea, abre archivos, utiliza herramientas, produce un cambio y anuncia que ha finalizado. El resultado puede ser correcto. El problema es que "podría tener razón" no es una propiedad operativa.

Para confiar en el trabajo, necesitamos saber qué se pidió, qué autoridad existía, qué entorno se utilizó, qué se verificó, qué evidencia se conservó y quién decidió aceptar. Esto es lo que organiza un harness de ingeniería.

Este artículo es un complemento técnico de “El modelo no es el sistema”. En lugar de discutir la tesis a un alto nivel, presenta un diseño mínimo en seis planes: Intención, política, ejecución, verificación, evidencia y retroalimentación..

Resumen ejecutivo

No es necesario que un harness sea una plataforma monolítica. Es un conjunto de límites explícitos alrededor de un ejecutor probabilístico.

Cada plan tiene un contrato, una falla típica y evidencia mínima:

Las fuentes examinadas por FORGE respaldan la separación entre historial de sesiones, orquestación y aislamiento de ejecución; También muestran que la complejidad adicional puede mejorar una tarea y aumentar materialmente el costo y la latencia. Estas conclusiones se limitan a las implementaciones estudiadas, no a una receta universal. [HARNESS31-C2] [HARNESS31-C3]

El contrato mínimo

Antes de pensar en agentes especializados, un flujo se puede describir así:

task:
  objective: "publicar o artigo aprovado"
  subject: "FORGE-ARTICLE-A09"
  out_of_scope:
    - "alterar o texto aprovado"
    - "expor conteúdo antes de publish_at"

authority:
  read: ["projecao-editorial"]
  write: ["artefato-estatico"]
  external_effects: ["deploy-pages"]
  requires_human_approval: ["aprovar-artigo", "alterar-agenda"]

verification:
  required: ["digest", "links", "a11y", "secrets", "clock-boundary"]

evidence:
  bind_to: ["article_digest", "commit_sha", "build_id", "deploy_id"]

El formato puede cambiar. Las responsabilidades no deberían desaparecer en un prompt.

Plan 1: intención

La intención convierte el lenguaje abierto en un problema ejecutable.

Contrato

• resultado y público afectado;
• activo o sistema que será modificado;
• entradas autorizadas;
• fuera de alcance;
• criterios de aceptación;
• efectos externos esperados;
• autoridad que aprueba la conclusión.

Fallo típico

El agente elige una interpretación plausible, optimiza una métrica local y ofrece algo técnicamente correcto para la pregunta equivocada.

Evidencia mínima

Una especificación versionada, vinculada al problema y la revisión producida. Si la intención cambia, el cambio debe manifestarse, no ser absorbido silenciosamente durante la ejecución.

Pregunta de diseño

¿Alguien más podría distinguir "hecho" de "luce bien" sin hablar con el ejecutor?

Plano 2 — política

La política define la autoridad antes de llamar a la herramienta.

Contrato

• recursos legibles y grabables;
• comandos, API y canales permitidos;
• clasificación de datos;
• presupuesto de costos, tiempo y juicio;
• acciones reversibles e irreversibles;
• condiciones de parada y ascenso;
• gates humanos.

Fallo típico

El modelo interpreta la disponibilidad de una herramienta como permiso para cualquier uso. El acceso conveniente se convierte en autoridad organizacional.

Evidencia mínima

Una política direccionable y un mecanismo que la aplica: lista de permitidos, token de alcance, entorno aislado, protección de sucursales, aprobación o denegación por defecto.

Las fuentes públicas examinadas describen capacidades compartidas y de alcance, pero no ofrecen un modelo de autorización universal. Cada producto aún necesita definir la revocación, el privilegio mínimo y las pruebas de límites. [HARNESS31-C4]

Plan 3: ejecución

La ejecución es donde la intención y la autoridad se encuentran con las herramientas y el estado.

Contrato

• identidad de sesión;
• revisión exclusiva o árbol de trabajo;
• runtime y dependencias;
• fuentes de contexto;
• estrategia de control y reanudación;
• límites de paralelismo;
• destino de salidas y registros.

Fallo típico

Dos tareas modifican el mismo alcance, una sesión hereda un contexto antiguo, una falla borra el progreso o un resultado no se puede atribuir al entorno que lo produjo.

Evidencia mínima

ID de sesión, commit base, revisión final, entorno, duración y resultado. Para tareas largas, los puntos de control deben ser artefactos, no sólo mensajes.

Sesión, modelo y rol separados

La sesión preserva la continuidad. El modelo ofrece capacidad. El rol define la responsabilidad. Mezclar los tres dificulta cambiar el modelo, reanudar el trabajo o auditar la autoridad.

Plan 4: verificación

Verifique las respuestas propiedades específicas. No es una votación entre agentes.

Contrato

Para cada control:

• subject y revisión precisos;
• propiedad observada;
• herramienta, versión y configuración;
• política de aprobación;
• independencia necesaria;
• límites conocidos y falsos negativos.

Fallo típico

El mismo ejecutor crea el cambio, escribe la prueba, interpreta el resultado y publica la conclusión. Un solo error de comprensión atraviesa todas las capas y recibe varios nombres “verdes”.

Evidencia mínima

Informe reproducible o resultado vinculado a revisión. Las pruebas unitarias, el contrato, el escáner secreto, la evaluación de comportamiento y la navegación real están separados porque prueban cosas diferentes.

La complejidad tiene un costo

En un experimento público sobre el desarrollo de aplicaciones a largo plazo, el planificador, el generador y el evaluador mejoraron los resultados observados, con un aumento material en coste y duración. Los datos respaldan la medición y la ablación; no admite la creación de tres agentes para cada tarea. [HARNESS31-C3]

Mantener un control porque reduce una clase de falla o riesgo medible. Elimínelo cuando una alternativa más simple demuestre la misma protección.

Plan 5: evidencia

La evidencia vincula la afirmación con lo que realmente se observó.

Contrato

• subject y digest;
• origen y versión;
• ejecutor y verificador;
• controles aplicados;
• receipts e informes;
• validez y límite de inferencia;
• aprobador;
• residual conocido.

Fallo típico

Una página dice "segura", "completa" o "aprobada", pero el informe pertenece a otra commit, otro entorno u otra fecha. La evidencia existe; la encuadernación no.

Evidencia mínima

Un manifiesto inmutable que le permite resolver claim → fuente → receipt → activo publicado. La ausencia de cualquier vínculo necesita fallar de forma cerrada.

El estado es parte del claim.

“Specified” dice que hay un dibujo. "Observado" dice que algo fue visto. "Aplicado" dice que un mecanismo hace cumplir una regla. "Calificado" requiere un límite de aceptación definido. Ningún Estado hereda al siguiente por proximidad o entusiasmo.

Plan 6: retroalimentación

La retroalimentación cierra la brecha entre corregir un incidente y mejorar el sistema.

Contrato

• evento que abrió el ciclo;
• causa e impacto;
• corrección inmediata;
• cambio duradero;
• regresión o control;
• propietario y plazo residual;
• Criterios de cierre.

Fallo típico

El agente vuelve a intentarlo hasta que se pone verde. La ejecución finaliza, pero la clase de fallo permanece intacta.

Evidencia mínima

Una prueba, patrón, decisión, actualización de contexto o política vinculada al evento original. Cerrar el tema sin un cambio duradero es simplemente cerrar la cola.

Ejemplo 1: cambio de software

Solicitud: agregar autenticación social.

• Intención: proveedores, viajes, errores y criterios de aceptación.
• Política: secreto del lado del servidor, devoluciones de llamadas incluidas en la lista permitida, datos mínimos y aprobación de seguridad.
• Ejecución: árbol de trabajo aislado, entorno de prueba e identidad de implementación.
• Verificación: Contratos OAuth, aislamiento de tenant, escáner, pruebas y flujo móvil real.
• Evidencia: informes e implementación vinculados al mismo commit.
• Comentarios: Los fracasos generan regresiones, documentación y ajustes de políticas.

Sin el harness, la demostración de inicio de sesión puede funcionar mientras el límite de identidad siga siendo incorrecto.

Ejemplo 2: publicación del artículo

Solicitud: publicar mañana a las 9 a.m.

• Intención: Texto aprobado, canónico, secuencia y tiempo.
• Política: la automatización puede diseñar y publicar; No puedes reescribir el contenido.
• Ejecución: construir tiempo con credenciales fuera del repositorio.
• Verificación: digest, fuentes, enlaces, accesibilidad, secretos y reloj.
• Evidencia: commit, construir, implementar y URL pública.
• Comentarios: la corrección conserva la fecha y registra la nota; El fracaso social no duplica publicaciones.

Este ejemplo muestra que el harness no es exclusivo del código. Organiza cualquier flujo en el que la IA produce artefactos y hay un efecto externo.

Métricas por plan

Evite un tablero enorme al principio. Elige señales que te ayuden a decidir:

Cruza estas señales con el resultado, el costo y el tiempo. Un sistema puede volverse más controlado y dejar de ser económicamente útil; o mantenerse rápido mientras aumenta el riesgo invisible.

Cómo empezar poco a poco

1. Elige un flujo con efecto real y reversible.
2. Escriba intención y fuera de alcance en una página.
3. Enumere las capacidades mínimas y niegue el resto.
4. Vincula dos o tres controles a diferentes propiedades.
5. Genere un manifiesto simple con revisión, informes y aprobador.
6. Haga que la primera solución produzca una regresión.
7. Mida el costo de cada plan y simplifique con evidencia.

Después de eso, decida si necesita un orquestador, varios agentes o una plataforma más grande. La arquitectura debe responder a la carga y al riesgo observados.

Conclusión

El harness de ingeniería es la disciplina de hacer gobernable el trabajo de agencia.

La intención evita acelerar en la dirección equivocada. La política impide que una herramienta se convierta en autoridad. La ejecución preserva la identidad y el estado. Verifique propiedades separadas. La evidencia vincula el resultado con la fuente. La retroalimentación convierte la corrección en capacidad permanente.

El objetivo es no rodear a la IA hasta que deje de ser útil. Se trata de crear suficiente confianza para delegar más y responsabilizar a los humanos por las decisiones que definen el propósito, el riesgo y el efecto en el mundo.

Lectura anterior: El modelo no es el sistema.. Próxima lectura: La IA amplifica el negocio que ya tienes.