Contratación · July 29, 2026 · 9 min de lectura

Cómo contratar a un ingeniero de agentes de IA: qué evaluar

Cómo contratar a un ingeniero de agentes de IA: qué hace el puesto, cuándo lo necesitas realmente, los impostores a filtrar y una muestra de trabajo de depuración de trazas que lo predice.

← Parte de The five pillars of hiring: what assessments measure

Este artículo es para el líder de ingeniería que observó cómo un agente de demo hacía algo mágico, le dio luz verde para producción, y luego se encontró con el aviso a las 2 de la madrugada: el agente entró en bucle con una llamada de herramienta malformada, reintentó en círculos y quemó el presupuesto de tokens de un mes antes de que nadie lo notara. El ingeniero de agentes de IA es la persona que contratas para que eso deje de pasar. Construyen sistemas donde un modelo actúa durante muchos pasos —planificando, llamando a herramientas, transfiriendo el control, recuperándose de sus propios errores— y son dueños de los modos de fallo que vienen con la autonomía. Este es el más nuevo de los puestos de la era de la IA, y existe ahora por una razón específica: el cambio de 2025-26 de funcionalidades de llamada única al modelo a agentes que actúan durante decenas de pasos creó modos de fallo que la ingeniería de backend ordinaria, e incluso la ingeniería de IA ordinaria, simplemente no cubre. El puesto se asienta dentro de tu organización de ingeniería, cerca de quien sea propietario de la fiabilidad, porque eso es lo que un agente en producción es principalmente —un problema de fiabilidad con un sombrero ingenioso—. Si te equivocas en la contratación, no obtienes una funcionalidad lenta; obtienes un sistema que falla de formas que nadie puede reproducir, a un coste que nadie predijo. Esta guía muestra cómo distinguir lo real de los muchos que se postularán como tal.

¿Qué hace realmente un ingeniero de agentes de IA?

Un ingeniero de agentes de IA construye y opera sistemas donde un modelo se ejecuta en un bucle —decidiendo, actuando mediante herramientas, comprobando el resultado y decidiendo de nuevo— en lugar de responder una vez y detenerse. El oficio es todo lo que rodea a ese bucle: mantenerlo acotado, observable, recuperable y asequible. Una semana en la vida se parece menos a escribir prompts que a gestionar un pequeño sistema distribuido impredecible.

• Diseñar el bucle de control del agente —cómo planifica, cuándo llama a una herramienta, cómo decide que ha terminado y qué impide que funcione indefinidamente.
• Acotar el radio de explosión —permisos y sandboxing para que un agente confundido pueda leer un ticket pero no pueda eliminar una tabla, enviar un correo a un cliente o gastar sin un límite.
• Construir transferencias de control —entre el agente y sub-agentes, o el agente y un humano, con un contrato claro sobre de qué es responsable cada parte.
• Conectar la recuperación de fallos —reintentos con retroceso exponencial en lugar de martillear, puntos de control para que un paso fallido no reinicie toda la ejecución, callejones sin salida que fallan de forma ruidosa en lugar de silenciosa.
• Instrumentar todo el sistema —trazas de cada paso, llamada a herramienta y decisión, porque cuando una ejecución sale mal la causa raramente está donde aparece el síntoma.
• Controlar el coste —presupuestos de tokens, límites de pasos y detección de bucles, porque un agente que reintenta una llamada incorrecta está quemando dinero silenciosamente.
• Escribir evaluaciones para tareas de múltiples pasos —¿llegó el agente al resultado correcto, y lo hizo de forma sensata, no solo por suerte en esta ejecución?

¿Lo necesitas realmente?

Sé honesto antes de abrir la solicitud. Solo necesitas un ingeniero de agentes de IA si estás lanzando agentes que actúan de forma autónoma durante muchos pasos con efectos secundarios reales. Si tu producto hace una llamada al modelo y devuelve texto —un resumidor, un clasificador, un buscador inteligente—, no tienes un problema de agentes; tienes un problema de ingeniería de IA, y contratar para agentes es prematuro.

A menor escala, un ingeniero de IA cubre este terreno cómodamente, y a menudo un buen ingeniero de backend con buen juicio lleva tu primera funcionalidad agéntica a producción. El detonante honesto para una contratación dedicada son los modos de fallo, no la ambición: cuando estás viendo bucles descontrolados, llamadas a herramientas que se disparan en el orden equivocado, errores no deterministas que desaparecen cuando los miras, o una curva de costes que se dispara cada vez que el agente toca un caso límite. Si nada de eso está pasando todavía, el puesto es una contratación que te estás convenciendo de hacer. Vendemos evaluación de candidatos para ganarnos la vida, así que descuéntalo como quieras —pero la forma más rápida de desperdiciar un ingeniero de agentes es contratar uno antes de tener un agente que merezca ser ingeniado—.

¿Qué distingue a un buen ingeniero de agentes de alguien que solo menciona nombres de frameworks?

Cada nuevo título atrae CVs rebautizados, y este atrae a un impostor específico: el que menciona nombres de frameworks. Han construido una demo con la biblioteca de agentes popular del mes, pueden enumerar cinco frameworks de orquestación y hablan con fluidez sobre planificadores y herramientas. Nada de eso es la señal. La fluidez en frameworks es lo básico; te dice que alguien leyó la documentación, no que puede mantener un sistema autónomo sin que te dañe. La habilidad real aparece en tres lugares que el constructor de demos nunca ha tenido que visitar.

• Cómo acotan el radio de explosión de un agente. Pregunta qué se le permite hacer a un agente cuando está seguro y se equivoca. Un buen ingeniero habla en términos concretos: acceso de herramientas con mínimos privilegios, ejecución en sandbox, límites de gasto, una lista de acciones irreversibles que siempre enruta a un humano. El que menciona nombres de frameworks habla de la seguridad integrada del framework y se detiene ahí.
• Cómo diseñan evaluaciones para tareas de múltiples pasos. Juzgar una única llamada es una respuesta calificada; juzgar un bucle significa preguntar si el agente llegó al resultado y llegó allí por las razones correctas, en muchas ejecuciones, sin que tú compruebes cada una manualmente. Si alguien nunca ha construido esto, nunca ha ejecutado realmente un agente en serio —ha ejecutado una demo que funcionó el día de la grabación.
• Cómo depuran una traza donde el fallo ocurrió cuatro pasos antes del síntoma. Este es todo el trabajo en una pregunta. El agente dio error en el paso 14, pero la causa raíz fue un resultado de herramienta malformado que se tragó en el paso 10 y alrededor del cual razonó desde entonces. El ingeniero que lee instintivamente hacia atrás por la traza —quien trata el síntoma como un indicador rezagado— es el que quieres. El que parchea el paso 14 y lo llama arreglado volverá a las 2 de la madrugada.

Hay una capa de juicio por encima de todas las herramientas, y es la señal más rara de todas: saber cuándo un agente es la respuesta equivocada. Un genuinamente buen ingeniero de agentes te dirá, sin que se lo pidas, que la mitad de las cosas que la gente quiere hacer agénticas deberían ser un flujo de trabajo determinista sencillo con una llamada al modelo en un paso —más barato, comprobable y aburrido de la manera en que los sistemas de producción deberían ser aburridos—. Alguien que quiere hacer todo un agente te está diciendo que todavía no ha sido dañado por uno.

La clave no es si un candidato puede construir un agente. Casi cualquiera puede hacerlo ahora. La clave es si puede mirar un problema y decir, con calma, que no debería ser un agente en absoluto —y luego explicar lo que un agente te costaría aquí que un flujo de trabajo sencillo no costaría.

¿Cómo se ponen a prueba esas habilidades?

No puedes llegar a esta señal solo con preguntas, porque los que mencionan nombres de frameworks son entrevistados de manera excelente. Tienes que observarlos trabajar. El ejercicio más predictivo es una tarea de depuración con forma de trabajo real: dale al candidato una traza de agente con mal comportamiento —una real, ligeramente saneada, donde el fallo apareció varios pasos después de su causa real— y haz que encuentren la causa raíz con herramientas de IA disponibles y el trabajo observado. Ese es el trabajo. También es lo único que un constructor de demos no puede falsificar, porque la lectura fluida de trazas solo viene de haber recibido avisos de tus propios agentes.

Ejecútalo de la manera en que ejecutarías cualquier prueba de muestra de trabajo: la misma tarea, los mismos materiales, la misma rúbrica para cada candidato, puntuado en comportamiento observable en lugar de cuán seguro sonaron. Lo que observas es si leen la traza hacia atrás desde el síntoma, si forman una hipótesis sobre dónde salió mal el bucle antes de empezar a cambiar cosas, y si notan el error tragado en el paso 10 en lugar de parchear el fallo en el paso 14. Y porque el trabajo es intensamente AI-native —estos ingenieros se apoyan en la IA constantemente para moverse por trazas desconocidas—, deberías observar cómo trabajan con IA mientras lo hacen, no prohibirlo y medir un trabajo que ya no existe.

Esa capa de uso observado de IA es donde aterriza la perspectiva de nuestra plataforma. El AI Sandbox ejecuta este tipo de tarea como una sesión realista y relevante para el puesto con herramientas de IA genuinamente disponibles, para que veas no solo la corrección sino cómo delegan al modelo y dónde lo detectan equivocándose con seguridad. La rúbrica que merece usarse es el Marco 4D de fluidez en IA —Delegation, Description, Discernment, Diligence— y para la mecánica de leer esas señales con claridad, escribimos un método completo en cómo evaluar la fluidez en IA. Para los ingenieros de agentes, Discernment tiene más peso: todo el puesto consiste en detectar el momento en que un resultado que parece plausible es incorrecto antes de que se acumule cuatro pasos más adelante.

Combina la muestra de trabajo con preguntas de juicio estructuradas —las mismas preguntas, el mismo orden, la misma puntuación para cada candidato— dirigidas al razonamiento que una traza sola no revelará. Pídeles que diseñen el límite del radio de explosión para un agente con acceso a tus herramientas de producción. Pregúntales cómo evaluarían una tarea de múltiples pasos donde la respuesta correcta varía. Pídeles, de forma más reveladora, un caso en que argumentaron en contra de hacer algo un agente, y lo que les costó perder o ganar ese argumento. Este es el juicio situacional aplicado a un puesto cuyos peores fallos son fallos de juicio, no de código.

¿Cómo es el proceso de entrevistas?

Mantenlo ajustado —los buenos ingenieros de agentes son escasos y muy cortejados, así que un proceso inflado simplemente los pierde ante un competidor más rápido—. Cuatro etapas son suficientes, y una de ellas debería ser la muestra de trabajo, no una quinta conversación.

• Una prueba de habilidades que cada candidato realiza en las mismas condiciones —una tarea corta y relevante para el puesto que reemplaza la selección por currículum, ampliando el grupo más allá del pedigree habitual y reduciendo el sesgo. Consulta la guía de contratación basada en habilidades para la filosofía.
• La muestra de trabajo de depuración de trazas en el AI Sandbox, con herramientas de IA disponibles y el proceso observado —tu etapa de mayor señal, gestionada por un ingeniero que realmente ha operado agentes en producción.
• Una entrevista estructurada sobre orquestación, sandboxing, evaluaciones y el juicio de cuándo no usar un agente, ejecutada por quien sea propietario de la fiabilidad de tus agentes, con una rúbrica fija.
• Una breve conversación de diseño de sistemas: pídeles que esbocen un agente acotado, observable y recuperable para un problema real que enfrentas, y sondea las decisiones —coste, latencia y dónde se mantiene un humano en el bucle—.

Puntúa cada etapa con una rúbrica escrita antes de que nadie compare notas, para que estés agregando evidencias en lugar de legitimar la opinión más ruidosa de la sala. Si quieres el andamiaje completo —quién gestiona qué, cómo se construye la tarjeta de puntuación, por qué importa el orden—, las entrevistas estructuradas son la referencia, y aplican aquí sin cambios.

Seniority y los primeros 90 días

Sobre la compensación y el nivel, resiste el impulso de inventar un número. Este es un título nuevo en un mercado que se mueve rápido, y cualquier rango impreso hoy es obsoleto en la próxima ronda de financiación. Lo que es seguro decir cualitativamente: porque el puesto fusiona la ingeniería de sistemas sénior con una disciplina genuinamente nueva en la que pocas personas tienen experiencia real en producción, los candidatos fuertes se sitúan alto en tu banda de ingeniería y lo saben. Nivelarlos en juicio demostrado bajo ambigüedad —la traza que realmente depuraron, el agente que realmente acotaron— no en años ni en los frameworks que pueden nombrar. Compara con tu propio mercado y contrata en base a evidencias, no en el ancla salarial que el candidato lanza primero.

Lo que tiene buen aspecto en los primeros 90 días es sin glamour, y ese es el punto. Una buena contratación no lanza tres nuevos agentes en el primer mes. Instrumentan los que ya ejecutas para que los fallos sean visibles, ponen límites de gasto y de pasos en los bucles que no los tienen, y construyen la primera suite de evaluación real para una tarea de múltiples pasos para que el próximo cambio pueda confiarse. En algún momento de ese proceso, silenciosamente convertirán un agente demasiado ambicioso de vuelta a un flujo de trabajo sencillo y te ahorrarán una factura recurrente. Si, a los tres meses, tus agentes fallan de forma ruidosa en lugar de silenciosa y puedes ver por qué cuando lo hacen, contrataste a la persona correcta. Ese instinto de fiabilidad primero es todo el puesto —y es exactamente la calidad de la contratación por la que estabas pagando—.

Si te llevas una sola cosa de esto: un ingeniero de agentes es juzgado por lo que sucede cuando el bucle sale mal, no por lo buena que parecía la demo cuando salió bien. Evalúalos de la misma manera —una traza real para depurar, IA a mano, el proceso observado— y contratarás a la persona que lee el fallo cuatro pasos antes, en lugar de la que parchea el síntoma y espera el aviso. Para el puesto hermano un paso antes en el mismo cambio, la persona que conecta modelos a productos antes de que alguna vez hagan bucles, lee cómo contratar a un ingeniero de IA.