De qué hablamos cuando decimos «agente»
El vocabulario del sector no está asentado y sería deshonesto imponer una definición. Aquí llamamos sistema agéntico a un sistema capaz de usar un modelo para decidir u orquestar algunas de sus etapas a partir de un objetivo, apoyándose en herramientas y dentro de un marco de restricciones. Cuánta decisión se deja al modelo varía muchísimo entre sistemas: esa proporción es justamente lo que fija la dificultad.
Lo que sigue no defiende ni discute el interés de los agentes. El enfoque es profesional: ¿qué competencias separan a quien sabe diseñar un sistema agéntico utilizable de quien sabe enseñar uno en una demostración? La diferencia es clara y se nota en entrevista en cuanto se habla de fallos.
Flujo determinista y comportamiento agéntico
Muchos sistemas presentados como agénticos son secuencias fijas en las que un modelo interviene en puntos concretos: extraer información, redactar, clasificar. El recorrido lo decide el código. Suele ser la opción correcta, y decirlo no es falta de ambición: una secuencia fija se prueba, se repite, se corrige y se supervisa mucho más fácilmente.
El comportamiento agéntico empieza donde el modelo elige qué viene después: qué herramienta llamar, con qué argumentos, cuántas veces, cuándo parar. Se gana cobertura de casos no previstos y se pierde previsibilidad. Una competencia central consiste en colocar esa frontera de forma deliberada, etapa por etapa, en lugar de dejar que se instale por defecto.
Frontera por defecto
Todo se confía a un único agente con una lista de herramientas y una instrucción general. Funciona en la mayoría de los casos de demostración. Cuando se equivoca, nadie sabe decir por qué se tomó ese camino, y la corrección consiste en reescribir la instrucción esperando que el comportamiento cambie en el sentido correcto sin romper otra cosa.
Frontera diseñada
Las etapas previsibles están codificadas; el margen del modelo se limita a los puntos donde la variabilidad de los casos lo justifica de verdad. Cada llamada a una herramienta tiene un alcance definido, parámetros validados y una traza. Cuando el sistema se equivoca, se sabe en qué etapa y con qué entradas, y la corrección apunta a esa etapa.
No es un argumento contra la autonomía. Es una forma de gastarla donde aporta algo, porque se paga en imprevisibilidad, coste y dificultad de diagnóstico.
Tool calling: el contrato real entre modelo y sistema
Que un modelo llame a una función es sencillo. Diseñar una herramienta que siga siendo segura cuando se llama en mal momento, con argumentos aproximados, dos veces seguidas o en paralelo, lo es mucho menos. La calidad de un sistema agéntico depende en gran medida de la calidad de sus herramientas.
- Alcance: una herramienta que hace una cosa, con una descripción que también diga cuándo no usarla.
- Validación: los argumentos producidos por un modelo son entradas no fiables; se validan como cualquier entrada externa.
- Efectos: separar explícitamente las herramientas de lectura de las que modifican algo. Son dos regímenes de riesgo distintos.
- Respuestas: devolver errores que el modelo pueda aprovechar, no una excepción en bruto ni un mensaje vacío que lo deje en bucle.
- Presupuestos: acotar el número de llamadas, la profundidad y la duración total, con independencia de lo que decida el modelo.
Estado, contexto y orquestación
Un agente que encadena etapas acumula información, y la acumulación se convierte en un problema: contexto que crece, información obsoleta que permanece, decisiones tomadas al principio que ya no se ven al final. Hay que decidir qué se conserva, en qué forma resumida, qué se reinyecta en cada etapa y qué pertenece a un almacenamiento externo y no al contexto.
En orquestación las preguntas concretas son: ¿el recorrido es secuencial o paralelo?, ¿quién decide parar?, ¿qué ocurre cuando una etapa devuelve un resultado parcial? y ¿cómo se retoma una ejecución interrumpida sin empezar de cero? Un sistema que no sabe retomar es un sistema que se relanza entero en cada incidente, con el coste correspondiente.
Acciones con consecuencias, permisos y validación humana
Una respuesta errónea se corrige. Un correo enviado, un reembolso lanzado, un ticket cerrado o un registro modificado en un sistema de gestión no se corrigen igual. En cuanto el sistema actúa, el diseño cambia de naturaleza: ya no es solo una cuestión de calidad, es una cuestión de responsabilidad.
- Permisos: ¿con los derechos de quién actúa el agente? Deben ser los del usuario afectado, no los de una cuenta técnica con poderes amplios.
- Validación humana: colocada donde el coste de un error supera el coste de esperar. Validarlo todo acaba en aprobaciones sin lectura.
- Reversibilidad: preferir acciones que puedan deshacerse, o prever explícitamente cómo compensar una que no.
- Idempotencia: cuando una acción se repite tras un incidente de red o un reintento, el sistema debe reconocer que ya se ejecutó. Punto clásico de ingeniería, a menudo ausente en los prototipos.
- Registro: conservar quién pidió qué, qué acciones se ejecutaron, con qué argumentos y con qué resultado.
La validación humana solo sirve si la persona tiene con qué decidir: qué va a hacer el agente, en qué se apoya y qué pasa si lo rechaza. Un diálogo «¿Confirmar?» sin contexto no protege de nada.
Reintentos, timeouts, fallos parciales
Un sistema agéntico llama a varios servicios, al menos uno de ellos un modelo con tiempo de respuesta variable. Los fallos no son excepcionales, son habituales. Tres comportamientos separan de inmediato un prototipo de algo operable.
- 1
Acotar tiempo e intentos
1Timeout por llamada a herramienta y presupuesto global de ejecución. Un agente sin límites acaba en bucle, cuesta dinero y bloquea a un usuario que espera. El número de intentos depende del tipo de error: reintentar una caída temporal tiene sentido, reintentar un error de validación no.
- 2
Tratar el fallo parcial
2Tres etapas de cinco correctas y la cuarta falla: el sistema debe saber si continúa, si se detiene, si deshace lo hecho o si devuelve un resultado incompleto claramente señalado. Es tanto una decisión de producto como técnica, y es lo que más suele faltar.
- 3
Hacer legible el fallo
3Para el usuario: qué se hizo, qué no y qué puede hacer a continuación. Para el equipo: una traza completa que permita repetir el caso. Un sistema que falla limpiamente es más utilizable que uno que acierta algo más a menudo y falla en silencio.
Evaluación y observabilidad
Evaluar un agente es más difícil que evaluar una respuesta única, porque el resultado depende de un recorrido. Dos ejecuciones aparentemente idénticas pueden seguir caminos distintos. Por eso se evalúa el resultado final y también la trayectoria: ¿se llamaron las herramientas adecuadas, en un orden aceptable, sin llamadas innecesarias y caras?
- Conjuntos de casos repetibles, con casos de fallo conocidos y entradas ambiguas, no solo el escenario ideal.
- Trazas por ejecución: etapas, herramientas llamadas, argumentos, duraciones, costes, decisión de parada.
- Indicadores de explotación: tasa de ejecuciones completadas, tasa de intervención humana, coste medio y coste máximo por ejecución, distribución de duraciones.
- Detección de derivas tras cambiar de modelo, de versión de herramienta o de instrucción: sin repetición, esas regresiones se descubren en producción.
Demostración impresionante frente a sistema recuperable
La comparación siguiente no trata de dificultad técnica sino de explotabilidad. El segundo sistema es menos espectacular; es el que un equipo puede poner en manos de usuarios.
Demostración agéntica
Un agente recibe un objetivo amplio, elige libremente entre una decena de herramientas, encadena llamadas y produce un resultado completo de una vez. La demostración funciona. No hay traza aprovechable, ni techo de coste, ni forma de retomar, y la acción final se ejecuta sin confirmación. Preguntado por un fallo, el autor no sabe decir por qué se tomó ese camino.
Sistema operable
La misma necesidad se resuelve con un recorrido parcialmente restringido: las etapas estables están codificadas y dos etapas se dejan al modelo. Cada herramienta valida sus argumentos y registra su llamada. Un presupuesto de ejecución acota duración y coste. La acción irreversible final pasa por una confirmación que muestra lo que va a ocurrir. Ante un fallo parcial, el usuario ve lo completado y el trabajo puede retomarse. El equipo puede repetir cualquier ejecución.
La ambición no es menor: se coloca en la fiabilidad y no en la amplitud de la autonomía. Ese desplazamiento es lo que buscan la mayoría de los equipos que contratan en estos temas.
Los límites de la autonomía, y saber nombrarlos
Cuanto mayor es el margen del modelo, mayor es la varianza, más difícil es prever el coste por ejecución y más se complica el diagnóstico. No es motivo para renunciar, es motivo para dosificar. Poder decir «aquí no le habría dado esa libertad al modelo, porque el caso es estable y verificar cuesta más que programarlo» indica madurez profesional.
En seguridad, el punto propio de los agentes es que un texto no controlado — un documento recuperado, una página web, un mensaje de usuario — puede acabar leyéndose como una instrucción. Un sistema que actúa debe tratar todo contenido externo como dato, restringir lo que permiten las herramientas y no hacer depender nunca una autorización solo del criterio del modelo.
MCP puede servir para exponer herramientas de forma homogénea a un sistema agéntico. Es una pieza posible entre otras, útil de conocer, pero no sustituye ninguna de las preguntas anteriores: alcance de las herramientas, permisos, validación, reanudación y observabilidad siguen siendo tu responsabilidad.
Cómo se traduce en entrevista
Las preguntas que separan candidatos rara vez son «¿sabes hacer tool calling?». Se parecen más a: ¿qué pasa si la herramienta devuelve un error en la tercera llamada?, ¿cómo evitas que una acción se ejecute dos veces?, ¿cómo te enteras de que tu agente se equivocó sin que te lo diga un usuario?, ¿cuánto cuesta una ejecución en el peor caso?
Si tu experiencia se limita a un prototipo, preséntalo como tal y pasa a lo que añadirías antes de ponerlo en manos de usuarios. Es una respuesta sólida. Reclamar una experiencia de producción que no tienes se detecta en la segunda pregunta.
Antes de decir «sé diseñar sistemas agénticos»
Estos puntos hablan de lo que has construido, no de lo que has leído.
- Puedo explicar dónde dejé margen al modelo y por qué no en otros puntos.
- Mis herramientas validan sus argumentos y separan lectura de acción.
- Sé qué ocurre si una etapa falla a mitad de la ejecución.
- Una acción irreversible pasa por validación humana informada, o es reversible.
- Puedo repetir una ejecución pasada a partir de sus trazas.
- Conozco el coste y la duración de una ejecución, incluido el peor caso.
- He probado entradas ambiguas y casos de fallo, no solo el escenario ideal.
- Sé decir qué no debe hacer mi sistema y cómo se impide.
Para recordar
- El vocabulario no está asentado: describir con precisión qué hace tu sistema vale más que reclamar la palabra «agente».
- La competencia empieza por colocar de forma deliberada la frontera entre código determinista y decisión del modelo.
- Las herramientas son el contrato real: alcance, validación de argumentos, separación lectura/acción, errores aprovechables.
- Una acción con consecuencias exige permisos, reversibilidad o validación informada, e idempotencia ante repeticiones.
- Sin trazas repetibles y sin presupuesto de ejecución, un agente no se puede diagnosticar.
- Un sistema menos autónomo pero recuperable vale más que una demostración espectacular.
- Agentes
- Evaluación
- Producción