El surgimiento del Ingeniero de Agentes: la nueva profesión de la era de la IA

Un puesto que no existía

Hace dos años, "usar IA" en una empresa significaba poner un campo de chat en la pantalla y llamar a una API. El trabajo cabía en un sprint y el cargo era el de siempre: desarrollador.

Hoy existe una función que no cabe en ningún cargo antiguo. La persona que diseña cómo decide un agente: qué herramientas puede llamar, qué entra en la ventana de contexto, qué hace cuando una herramienta falla, hasta dónde puede llegar sin preguntar, y cómo demuestras después que hizo lo que debía. Eso no es integración. Es diseño de un sistema autónomo.

Esa persona es el Ingeniero de Agentes.

IA agéntica, en una frase honesta

La IA generativa produce contenido cuando se lo pides. La IA agéntica ejecuta un objetivo en varios pasos, eligiendo sola las acciones por el camino.

La diferencia práctica es el bucle. Un modelo generativo hace: entrada → salida. Un agente hace: objetivo → piensa → elige una herramienta → observa el resultado → decide el siguiente paso → repite hasta terminar o rendirse.

Ese bucle lo cambia todo. Introduce estado, costo variable, fallo parcial y efecto colateral en el mundo real — las cuatro cosas que convierten una función de producto en un problema de ingeniería.

Las herramientas son el cuerpo del agente

Un modelo sin herramientas solo sabe hablar. Las herramientas son lo que le da brazos: consultar una base, abrir un ticket, mandar un correo, leer un archivo, llamar a la API del ERP.

Diseñar herramientas es la mitad más subestimada del trabajo. Una herramienta bien hecha:

• Hace una cosa, y el nombre dice cuál. buscar_pedido_por_identificacion funciona; ejecutar_query es una invitación al desastre.
• Tiene entrada validada y error legible. El agente lee el mensaje de error e intenta corregirse — así que el mensaje es prompt, no registro.
• Devuelve poco. Retornar un JSON de doscientas líneas quema contexto y ahoga la decisión siguiente.
• Es reversible o pide confirmación. Una acción destructiva sin confirmación es un accidente esperando fecha.

MCP: el estándar que hizo que esto escalara

Hasta hace poco, cada agente tenía sus herramientas pegadas a mano dentro de su propio código. Eso no escala: diez agentes accediendo al mismo CRM significaban diez integraciones distintas.

MCP (Model Context Protocol) lo resolvió de la manera aburrida y correcta: se volvió un protocolo abierto para exponer herramientas, datos e instrucciones a cualquier modelo. Escribes un servidor MCP para tu CRM una vez, y cualquier agente compatible sabe usarlo — desde el asistente de tu editor hasta el agente que corre en el servidor a medianoche.

El efecto cultural es mayor que el técnico. MCP convirtió la "capacidad de IA" en algo que se publica, se versiona y se gobierna — como se hace con las API desde hace veinte años. Es la diferencia entre un apaño y una infraestructura.

Qué hace de verdad el Ingeniero de Agentes

El día a día es bastante menos glamoroso de lo que sugiere el título:

1. Recorta el objetivo. Un agente con un alcance demasiado amplio falla de formas creativas. El trabajo empieza cortando la tarea hasta que quepa en un bucle confiable.
2. Presupuesta el contexto. Decide qué entra en la ventana, qué va a memoria externa, qué se resume y qué se descarta. El contexto es un presupuesto, no un depósito.
3. Diseña el fracaso. ¿Qué pasa cuando la API se cae, cuando el modelo alucina un parámetro, cuando el bucle no converge? Tiempo límite, número máximo de pasos, salida de emergencia hacia el humano.
4. Lo instrumenta todo. Cada paso, cada llamada a herramienta, cada token gastado, rastreable. Sin rastro no hay depuración posible — y un agente sin depuración es una apuesta.
5. Mide. Un conjunto de casos de evaluación con respuesta esperada, ejecutado en cada cambio de prompt o de modelo. Sin eso, "mejoró" es una opinión.
6. Define la frontera de la autonomía. Qué hace solo, qué propone y espera aprobación, qué no hace nunca.

La mitad del trabajo de un ingeniero de agentes es decidir dónde termina la autonomía. Es la única mitad por la que la dirección va a preguntar de verdad.

De dónde viene esta gente

No de un curso. Las personas buenas en esto hoy llegaron por tres caminos: desarrollo backend (que ya entiende sistemas distribuidos, colas, idempotencia y fallo parcial), operación/SRE (que ya vive de observabilidad y postmortems) y automatización de procesos (que ya sabe modelar el trabajo de un área antes de automatizarlo).

Quien solo sabe escribir prompts no llega. El prompt es una de las capas — y la más fácil de cambiar.

Por qué esto se vuelve profesión y no moda

Porque el problema no es del modelo, es del sistema a su alrededor. Cada generación de modelos mejora y el trabajo de ingeniería sigue: alguien tiene que decidir límites, garantizar trazabilidad, controlar el costo y responder cuando el agente hace una tontería.

Modelos mejores hacen agentes más capaces — lo que aumenta, no reduce, la necesidad de alguien que sepa dónde poner la correa.