Durante los últimos dos años, los consejos de carrera en torno a los agentes de IA se han centrado sobre todo en aprender a darles buenos prompts. Esa ya no es la habilidad escasa. La habilidad escasa es construir el andamiaje dentro del cual vive un agente —eso que cada vez más se llama harness— y es lo suficientemente específico, y lo suficientemente difícil, como para estar convirtiéndose en una descripción de puesto propia, en lugar de una responsabilidad secundaria de "la persona de IA" en un equipo.

El recorrido público más claro de lo que esto realmente implica viene de Lenny's Newsletter, que documenta cómo la herramienta de gestión de producto ChatPRD construyó un harness para depurar automáticamente errores de Sentry. Vale la pena leer la nota completa si estás evaluando si especializarte en esto, porque plantea un punto que es fácil pasar por alto: el modelo nunca fue el cuello de botella. El equipo usó el Claude Agent SDK como base y luego dedicó la mayor parte de su esfuerzo de ingeniería a una interfaz de terminal personalizada y a un conjunto de adaptadores que conectan al agente con Sentry, Linear, GitHub y Vercel. Ese es el trabajo, en miniatura. Cuatro sistemas, cuatro esquemas de autenticación distintos, cuatro formas de datos distintas, y una interfaz que le permite a un humano observar e intervenir sin tener que vigilar cada paso.

En qué se descompone realmente un "harness"

Si estás tratando de descifrar si esta es una habilidad que vale la pena desarrollar, ayuda separarla en piezas que se contratan por separado, o que al menos se evalúan por separado en una entrevista:

  • Diseño de permisos. Decidir qué puede hacer un agente sin supervisión (leer un ticket, redactar un PR) frente a lo que necesita un humano en el circuito (fusionar, desplegar, eliminar, gastar dinero) —y codificar eso como una política real dentro del código, no como una instrucción en el prompt que el modelo podría ignorar bajo presión. Esto se parece más a la ingeniería de control de acceso que a la escritura de prompts.
  • Adaptadores de herramientas. Envoltorios delgados y bien probados alrededor de cada sistema externo (Sentry, Linear, GitHub, Vercel, o lo que sea que use el stack de tu empresa) que traducen la intención del agente en una llamada a la API segura y validada, y traducen la respuesta de vuelta en algo sobre lo que el modelo pueda razonar. Esto es ingeniería de software común —manejo de errores, reintentos, validación de esquemas— aplicada a un nuevo consumidor.
  • Interfaz de terminal o consola. Una forma para que un humano vea lo que está haciendo el agente, apruebe o rechace acciones, e intervenga cuando se atasca. ChatPRD construyó una a medida; muchos equipos usarán en cambio consolas de agentes ya hechas, pero alguien igual tiene que decidir qué se muestra, qué se oculta y qué requiere un clic antes de que ocurra.
  • Selección de herramientas a escala. Un artículo de Machine Learning Mastery señala algo que vale la pena saber si estás construyendo algo más allá de una demo: la precisión de los agentes en las llamadas a herramientas tiende a degradarse una vez que el catálogo de herramientas supera aproximadamente una docena de opciones —el modelo empieza a llamar mal a las herramientas, a alucinar parámetros o a estancarse en llamadas fallidas. Las mitigaciones que enumera (limitar qué herramientas son siquiera visibles en un contexto dado, búsqueda de herramientas basada en recuperación, enrutamiento hacia subagentes especializados, pasos explícitos de planificación, lógica de respaldo, y harnesses de benchmark para detectar regresiones) son en sí mismas una lista de verificación de cosas que un ingeniero de harness necesita saber implementar, no solo conocer.
  • Ingeniería de contexto y de memoria. La misma fuente traza una distinción que vale la pena interiorizar: la ingeniería de contexto (qué entra en una sola llamada de inferencia, y dónde) y la ingeniería de memoria (qué persiste entre sesiones, cómo se almacena, cómo se recupera) son disciplinas distintas con distintos modos de falla. Su planteamiento es que la mayoría de los fallos en agentes de larga duración y de múltiples sesiones se remontan a confundir ambas cosas —tratar la memoria de sesión como si fuera simplemente más contexto, o viceversa— particularmente en el punto donde el sistema decide qué recuperar.

La evidencia de que este es un rol real y financiable —no solo un nicho de aficionados

Los escépticos preguntarán, con razón, si "ingeniero de harness" es un trabajo o simplemente una tarea dentro del trabajo de otra persona. Dos datos del resumen sugieren que se está moviendo hacia lo primero. Primero, el equipo Aspire de Microsoft —un grupo de 10 personas— usó los Agentic Workflows de GitHub para automatizar PRs de documentación entre repositorios, y a lo largo de dos versiones fusionó 82 PRs con una mediana de 44.8 horas después de que se publicara el PR de producto correspondiente, sin contratar personal nuevo ni volver a capacitar los procesos. Ese es un equipo pequeño obteniendo un apalancamiento desproporcionado precisamente porque alguien invirtió en el andamiaje (las definiciones de flujo de trabajo, el enrutamiento de revisiones, la lógica de disparo) en lugar de hacer que los ingenieros escribieran los PRs de documentación a mano. Segundo, el proyecto SkillOpt de Microsoft Research trata los archivos de "skill" de los agentes —las instrucciones y restricciones que moldean cómo se comporta un agente dentro de su harness— como algo que debe optimizarse sistemáticamente en lugar de editarse a mano, y reporta que fue el mejor o empató como el mejor en las 52 celdas de una cuadrícula de benchmark (seis benchmarks, siete modelos, tres modos de ejecución), con las skills optimizadas transfiriéndose entre distintos modelos y distintos harnesses. Sin importar si esa herramienta en particular se vuelve estándar, es una señal de que la industria está empezando a tratar la configuración del harness como un artefacto de ingeniería con sus propias herramientas y benchmarks —la misma trayectoria que convirtió al "DevOps" de un conjunto de scripts improvisados en una disciplina.

También se está construyendo ahora infraestructura pensada explícitamente para esta capa. Las capacidades recién anunciadas de "Managed Agents" de Google en la API de Gemini —ejecución en segundo plano y asíncrona, integración remota con servidores MCP, llamadas a funciones personalizadas, renovación de credenciales entre interacciones— son, en esencia, plomería prefabricada para exactamente los problemas que el equipo de ChatPRD resolvió a mano. Ese es un patrón normal: lo que un equipo construye a medida este año, un proveedor de plataforma lo convierte en producto el próximo. Esto no elimina el rol de la ingeniería de harness; eleva el piso y desplaza el trabajo hacia integrar y configurar primitivas gestionadas en lugar de escribir cada adaptador desde cero, de forma similar a como la infraestructura en la nube no eliminó a los ingenieros de operaciones, sino que cambió en qué invertían su tiempo.

Qué significa esto si apuntas a este rol

Algunas cosas concretas y verificables para incluir en un portafolio o currículum si quieres ser creíble para este trabajo: construye un adaptador de punta a punta contra una API real que no controlas (con autenticación, manejo de errores y límites de tasa incluidos, no una demo del camino feliz); diseña y documenta un modelo de permisos para un agente que distinga entre acciones de leer/proponer/actuar y muestre por qué cada límite está donde está; y construye o configura una interfaz de revisión donde un humano apruebe las acciones del agente antes de que se ejecuten, ya que esa es la pieza que la mayoría de las empresas exigirá antes de dejar que un agente toque producción. Si estás evaluando una oferta de trabajo de ingeniería de harness o delimitando tus propias responsabilidades, pregunta específicamente quién es dueño del modelo de permisos, quién es dueño de los adaptadores y quién es dueño de la superficie de revisión humana —en muchos equipos, en este momento, esas tres cosas no tienen un dueño claro, que es exactamente el vacío que este rol se está formando para llenar.

Una advertencia que vale la pena decir con claridad: ninguna de las fuentes anteriores establece una cifra del mercado laboral para este título específico, y "ingeniero de harness" todavía no es un título de puesto que vayas a ver en las ofertas de empleo —está apareciendo dentro de títulos como "ingeniero de infraestructura de IA", "ingeniero de plataforma de agentes", o simplemente "ingeniero backend senior, sistemas de IA". Trata esto como un conjunto de habilidades para desarrollar y describir con precisión, no como un título para buscar en LinkedIn.