Phase 14 - Lesson 31

Ingeniería de Bancada de Agente: Por Qué los Modelos Capaces Aún Fallan

Un modelo capaz no es suficiente. Los agentes confiables necesitan una bancada: instrucciones, estado, alcance, retroalimentación, verificación, revisión y transición. Quita eso y hasta un modelo de frontera producirá trabajo que no es seguro enviar a producción.

Tipo: Aprender + Construir Idiomas: Python (stdlib) Prerrequisitos: Fase 14 · 01 (Loop del Agente), Fase 14 · 26 (Modos de Fallo) Tiempo: ~45 minutos

Objetivos de Aprendizaje

  • Separar la capacidad del modelo de la confiabilidad de la ejecución.
  • Nombrar las siete superficies de la bancada que deciden si un agente se envía a producción.
  • Comparar una ejecución de solo prompt contra una ejecución guiada por la bancada en una tarea de repositorio pequeña.
  • Producir un informe de modos de fallo que mapee cada superficie omitida con el síntoma que causó.

El Problema

Inyectas un modelo de frontera en un repositorio real y le pides que agregue validación de entrada. Abre cuatro archivos, escribe código plausible, declara éxito y se detiene. Ejecutas las pruebas. Dos fallan. Se modifica un tercer archivo que no tenía nada que ver con la validación. No hay registro de lo que el agente asumió, lo que intentó primero o lo que queda por hacer.

El modelo no estaba equivocado sobre Python. Estaba equivocado sobre el trabajo. No tenía idea de qué se consideraba terminado, dónde se le permitía escribir, qué pruebas eran autoritativas o cómo debía continuar la siguiente sesión.

Esto no es un error del modelo. Es un error de la bancada. A la superficie alrededor del agente le faltan las partes que convierten una generación de un solo intento (one-shot) en ingeniería confiable y reanudable.

El Concepto

Una bancada es el entorno operativo que envuelve al modelo durante una tarea. Tiene siete superficies:

Superficie Lo que contiene Fallo cuando falta
Instrucciones Reglas de inicio, acciones prohibidas, definición de terminado El agente adivina qué significa enviar a producción
Estado Tarea actual, archivos modificados, bloqueadores, siguiente acción Cada sesión se reinicia desde cero
Alcance Archivos permitidos, archivos prohibidos, criterios de aceptación Las ediciones se filtran a código no relacionado
Retroalimentación Salida de comando real capturada en el loop El agente declara éxito en un error 400
Verificación Pruebas, linter, ejecución rápida (smoke test), verificación de alcance "Se ve bien" llega a main
Revisión Un segundo paso con un rol diferente El constructor califica su propia tarea
Transición Qué cambió, por qué, qué queda La siguiente sesión vuelve a descubrir todo 
flowchart LR
  Task[Tarea] --> Scope[Contrato de Alcance]
  Scope --> State[Memoria del Repositorio]
  State --> Agent[Loop del Agente]
  Agent --> Feedback[Retroalimentación de Ejecución]
  Feedback --> Verify[Puerta de Verificación]
  Verify --> Review[Revisor]
  Review --> Handoff[Transición]
  Handoff --> State

El loop se cierra en el archivo de estado, no en el historial del chat. El chat es volátil. El repositorio es el sistema de registro.

Bancada frente a ingeniería de prompts

El prompt le dice al modelo lo que quieres en este turno. Una bancada le dice al modelo cómo trabajar a través de turnos y sesiones. La mayoría de las historias de fallos de agentes son fallos de la bancada vestidos de ingeniería de prompts.

Bancada frente a framework

Un framework te brinda un entorno de ejecución (LangGraph, AutoGen, Agents SDK). Una bancada le da al agente un lugar para trabajar dentro de ese entorno de ejecución. Necesitas ambos. Esta mini-ruta es sobre el segundo.

Razonar a partir de primitivas, no de taxonomías de proveedores

Hay muchos textos sobre "ingeniería de harness" (harness engineering) en este momento. Addy Osmani, OpenAI, Anthropic, LangChain, Martin Fowler, MongoDB, HumanLayer, Augment Code, Thoughtworks, la lista awesome de walkinglabs y un flujo constante de artículos en Medium y Hacker News lo están abordando. No están de acuerdo sobre el límite de lo que es un harness, lo que está dentro del alcance y qué vocabulario usar. No necesitamos elegir un bando. Las siete superficies son una capa de UX; debajo de cada bancada se encuentra el mismo conjunto de primitivas de sistemas distribuidos que sostienen cualquier backend confiable.

Quita la etiqueta de agente por un momento. La ejecución de un agente es computación que cruza tiempo, procesos y máquinas. Para que sea confiable, necesitas las mismas primitivas que cualquier sistema de producción necesita.

Primitiva Qué es Qué transporta para un agente
Función Controlador tipado. Puro donde sea posible. Es dueño de sus entradas y salidas. Una llamada a herramienta, una verificación de regla, un paso de verificación, una invocación de modelo
Worker Proceso de larga duración que posee una o más funciones y un ciclo de vida El constructor, el revisor, el verificador, un servidor MCP
Gatillo Fuente de eventos que invoca una función Tick del loop del agente, solicitud HTTP, mensaje de cola, cron, cambio de archivo, hook
Entorno de ejecución El límite que decide qué se ejecuta dónde, con qué límites de tiempo y recursos El proceso de Claude Code, el entorno de ejecución de LangGraph, un contenedor de worker
HTTP / RPC El cable entre el llamador y el worker Protocolo de llamada a herramienta, solicitud MCP, API del modelo
Cola Buffer duradero entre el gatillo y el worker; contrapresión (back-pressure), reintento, idempotencia El tablero de tareas, el registro de retroalimentación, la bandeja de entrada de revisión
Persistencia de sesión Estado que sobrevive a caídos, reinicios y cambios de modelo agent_state.json, checkpoints, almacenes KV, el propio repositorio
Política de autorización Quién puede llamar a qué función con qué alcance Archivos permitidos/prohibidos, límites de aprobación, listas de capacidades MCP

Ahora mapea las siete superficies de la bancada en esas primitivas.

  • Instrucciones — política + metadatos de función. Las reglas son comprobaciones (funciones). El enrutador (AGENTS.md) es una política adjunta al inicio del entorno de ejecución.
  • Estado — persistencia de sesión. Un almacén con clave que el entorno de ejecución lee en cada paso. Archivo, KV o base de datos; la semántica de persistencia importa, el backend de almacenamiento no.
  • Alcance — política de autorización por tarea. Los globs permitidos/prohibidos son una ACL. Las aprobaciones requeridas son una red de permisos.
  • Retroalimentación — registro de invocación escrito en una cola. Cada llamada de shell es un registro duradero y reproducible.
  • Verificación — una función. Determinista sobre las entradas. Se activa al cerrar la tarea. Falla en modo seguro (fails closed).
  • Revisión — un worker separado con autorización de solo lectura en los artefactos del constructor y autorización de solo escritura en los informes de revisión.
  • Transición — un registro duradero emitido por un gatilho de fin de sesión. El gatilho de inicio de la siguiente sesión lo lee.

El loop del agente en sí es un worker que consume eventos (mensaje del usuario, resultado de la herramienta, tick del temporizador), llama a funciones (el modelo, luego las herramientas que el modelo elija), escribe registros (estado, retroalimentación) y emite gatillos (verificar, revisar, transición). No hay misterio; es el mismo formato que un procesador de trabajos.

Patrones en circulación, traducidos a primitivas

Cada patrón popular de harness se reduce a las ocho primitivas. Tabla de traducción.

Patrón de proveedor o comunidad Qué es en realidad
Ralph Loop (Claude Code, Codex, libro agentic_harness) — volver a inyectar la intención original en una ventana de contexto limpia cuando el agente intenta detenerse antes de tiempo Un gatillo que vuelve a encolar una tarea con un contexto limpio; la persistencia de sesión lleva el objetivo hacia adelante
Planificar / Ejecutar / Verificar (PEV) Tres workers, uno por rol, comunicándose a través de estado y una cola entre fases
Separación de harness y computación (OpenAI Agents SDK, abril de 2026) — dividir el plano de control del plano de ejecución Redefinición de plano de control / plano de datos. Precede a la etiqueta de agente por décadas
Open Agent Passport (OAP, marzo de 2026) — firmar y auditar cada llamada a herramienta contra una política declarativa antes de la ejecución Una política de autorización impuesta por un worker de pre-acción, con una cola de auditoría firmada
Guías y Sensores (Birgitta Böckeler / Thoughtworks) — reglas de alimentación directa (feedforward) + observabilidad de retroalimentación Política de autorización + funciones de verificación + trazas de observabilidad
Compactación progresiva de 5 etapas (ingeniería inversa de Claude Code, abril de 2026) Un worker de gestión de estado que se ejecuta como un cron sobre la persistencia de sesión para mantenerla dentro de un presupuesto
Hooks / middleware (LangChain, Claude Code) — interceptar llamadas de modelo y herramientas Gatillos + funciones envueltas alrededor de la ruta de invocación del entorno de ejecución
Habilidades como Markdown con divulgación progresiva (Anthropic, Flue) Un registro de funciones donde los metadados de la función se cargan en el contexto justo a tiempo
Agentes en Sandbox (Codex, Sandcastle, Vercel Sandbox) El plano de computación: un entorno de ejecución con sistema de archivos, red y ciclo de vida aislados
Servidores MCP Workers que exponen funciones a través de un RPC estable, con listas de capacidades como autorización

Every entry in that table is the agent community arriving at a primitive that already had a name in distributed systems and giving it a new one. Useful labels for marketing; not useful as engineering vocabulary.

Lo que las pruebas realmente dicen

La afirmación de que el harness es superior al modelo ahora tiene números detrás. Vale la pena saberlos, porque también son el único argumento honesto contra "solo espera a un modelo más inteligente".

  • Terminal Bench 2.0 — el mismo modelo, un cambio de harness llevó a un agente de programación desde fuera del top 30 al puesto cinco (LangChain, Anatomy of an Agent Harness).
  • Vercel — eliminó o borró el 80% de las herramientas de su agente; la tasa de éxito saltó del 80% al 100% (MongoDB).
  • Harvey — los agentes legales más que duplicaron su precisión solo a través de la optimización del harness (MongoDB).
  • El 88% de los proyectos de agentes de IA empresariales no logran llegar a producción. Los fallos se concentran en torno al entorno de ejecución, no al razonamiento (preprints.org, Harness Engineering for Language Agents, marzo de 2026).
  • Un estudio de benchmark de 2025 en tres frameworks populares de código abierto reportó ~50% de finalización de tareas; WebAgent de contexto largo colapsó de 40-50% a menos del 10% en condiciones de contexto largo, principalmente por loops infinitos y pérdida de objetivos (ampliamente cubierto en notas de principios de 2026).

La conclusión no es "el harness gana para siempre". Los modelos absorben trucos de harness con el tiempo. La conclusión es que hoy, la ingeniería de soporte está alrededor del modelo, no dentro de él, y las primitivas que soportan esa carga son las que todo sistema de producción siempre ha necesitado.

Dónde los artículos de los proveedores se quedan cortos

Esta es la parte con la que no necesitas ser educado.

  • Anatomy of an Agent Harness de LangChain enumera once componentes: prompts, herramientas, hooks, sandboxes, orquestación, memoria, habilidades, subagentes y un "loop simple" de entorno de ejecución. No menciona colas, workers como una unidad de despliegue, semántica de gatillos, persistencia de sesión como una preocupación separada o política de autorización. Trata al harness como un objeto que configuras, no como un sistema que despliegas.
  • Agent Harness Engineering de Addy Osmani plantea la estructura Agent = Model + Harness y el patrón ratchet, pero se queda corto al decir de qué está construido un harness. Se lee como una postura, no como una especificación.
  • Anthropic y OpenAI profundizan más en las superficies pero se quedan dentro de sus propios entornos de ejecución. El anuncio de "separación de harness y computación" en el SDK de agentes de abril de 2026 es la primera pieza de proveedor que respalda explícitamente la división de plano de control / plano de datos. Esa es una idea primitiva, no nueva.
  • El libro agentic_harness trata al harness como un objeto de configuración (capítulo 6 de Agentic Engineering de Jaymin West) y la línea más fuerte en él es "el harness es el límite de seguridad principal en un sistema agentivo". Eso es solo política de autorización, reformulada.
  • Los hilos de Hacker News siguen llegando al mismo lugar. El hilo de abril de 2026 The agent harness belongs outside the sandbox argumenta que el harness debería estar "más como un hipervisor que se ubica fuera de todo y autoriza el acceso según el contexto y el usuario". Eso es, de nuevo, la política de autorización como un plano separado.

No necesitas estar en desacuerdo con ninguna de estas piezas para notar la brecha. Están escribiendo descripciones de UX de un sistema que ya existe. Nosotros estamos escribiendo el sistema. Cuando el sistema está bien construido, las siete superficies surgen de las primitivas. Cuando está mal construido, ninguna cantidad de pulido de AGENTS.md soluciona la cola que falta.

Así que cuando escuches "ingeniería de harness" (harness engineering) en otro lugar, tradúcelo a primitivas. Los prompts y las reglas son políticas y funciones. El scaffolding es el entorno de ejecución. Las barreras de seguridad (guardrails) son autorización + verificación. Los hooks son gatillos. La memoria es persistencia de sesión. El Ralph Loop es reencolar. Los subagentes son workers. Los sandboxes son planos de computación. El vocabulario cambia; la ingeniería no. La bancada es la UX orientada al agente; el harness, en el sentido que sobrevive a la próxima reformulación de proveedores, son funciones, workers, gatillos, entornos de ejecución, colas, persistencia y políticas conectados correctamente.

Constrúyelo

code/main.py ejecuta una pequeña tarea de repositorio dos veces. Primero como solo prompt, luego con las siete superficies conectadas. El mismo modelo, la misma tarea. El script cuenta qué superficies faltaron en la ejecución fallida e imprime un informe de modos de fallo.

La tarea del repositorio es pequeña a propósito: agregar validación de entrada a un controlador estilo FastAPI de un solo archivo y escribir una prueba que pase.

Ejecútalo:

python3 code/main.py

Salida: un registro lado a lado de las dos ejecuciones, un failure_modes.json que resume la ejecución de solo prompt y un veredicto de una sola línea para la ejecución de la bancada.

El agente es un pequeño bosquejo basado en reglas; el punto son las superficies, no el modelo. A lo largo del resto de esta mini-ruta reconstruirás cada superficie como un artefacto real y reutilizable.

Úsalo

Tres lugares donde las superficies de la bancada ya existen en la práctica, incluso si nadie las llama así:

  • Claude Code, Codex, Cursor. AGENTS.md y CLAUDE.md son la superficie de instrucciones. Los comandos de barra son el alcance. Los hooks son la verificación.
  • LangGraph, OpenAI Agents SDK. Los checkpoints y los almacenes de sesión son la superficie de estado. Los traspasos son la superficie de transición.
  • CI en un repositorio real. Las pruebas, el linter y la verificación de tipos son la verificación. La plantilla de PR es la transición. CODEOWNERS es la revisión.

La ingeniería de bancadas es la disciplina de hacer que esas superficies sean explícitamente reutilizables, en lugar de dejar que cada equipo las vuelva a descubrir.

Envíalo

outputs/skill-workbench-audit.md es una habilidad portátil que audita un repositorio existente para las siete superficies de la bancada y reporta cuáles faltan, cuáles son parciales y cuáles están saludables. Colócalo junto a cualquier configuración de agente; te dice qué solucionar primero.

Ejercicios

  1. Elige un repositorio donde ya ejecutes un agente. Califica las siete superficies de 0 (ausente) a 2 (saludable). ¿Cuál es tu superficie más débil?
  2. Extiende main.py para que la ejecución de solo prompt también produzca una afirmación falsa de "éxito". Verifica que la puerta de verificación la habría atrapado.
  3. Agrega una octava superficie para tu propio producto. Justifique por que no se reduce a una de las siete existentes.
  4. Vuelve a ejecutar el script con un agente simulado diferente que alucine la escritura de un archivo adicional. ¿Qué superficie lo atrapa primero?
  5. Mapea los cinco modos de fallo recurrentes de la industria de la Fase 14 · 26 en las siete superficies. ¿Para absorber qué modo está diseñada cada superficie?

Términos Clave

Término Lo que dice la gente Lo que realmente significa
Bancada (Workbench) "La configuración" Superficies diseñadas alrededor del modelo que hacen que el trabajo sea confiable
Superficie "Un doc" o "un script" Una entrada nombrada, legible por máquina, que el agente lee o escribe en cada turno
Sistema de registro "Las notas" El archivo que el agente trata como verdad cuando el historial del chat desaparece
Definición de terminado "Aceptación" Una lista de verificación objetiva y respaldada por archivos que el agente no puede falsificar
Auditoría de bancada "Verificación de preparación del repositorio" Un paso sobre las siete superficies que señala las piezas que faltan antes de que comience el trabajo

Lecturas Adicionales

Léelas como puntos de datos, no como autoridades. Cada una es una taxonomía parcial. Traduce cada concepto a una primitiva (función, worker, gatillo, entorno de ejecución, HTTP/RPC, cola, persistencia, política) antes de decidir si adoptarlo.

Enfoques de proveedores:

Artículos de profesionales con detalles utilizables:

Libros, artículos académicos e implementaciones de referencia:

Hilos de Hacker News que vale la pena leer por los desacuerdos, no por el consenso:

Referencias cruzadas dentro de este plan de estudios:

  • Fase 14 · 23 — Convenciones de OpenTelemetry GenAI: la capa de observabilidad a la que apunta la literatura sobre sensores
  • Fase 14 · 26 — Catálogo de modos de fallo que las siete superficies están diseñadas para absorber
  • Fase 14 · 27 — Defensas de inyección de prompts que se ubican en la primitiva de política de autorización
  • Fase 14 · 29 — Entornos de ejecución de producción (cola, evento, cron): dónde viven en el despliegue las primitivas de esta lección
0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).