Un agente de IA es un sistema que recibe un objetivo, decide qué acciones necesita para acercarse a él, puede ejecutar esas acciones mediante herramientas y usa los resultados para decidir el siguiente paso. El modelo de lenguaje puede proponer la acción, pero el agente completo incluye también el runtime, las tools, el estado, los permisos y la lógica que decide cuándo detenerse.
La diferencia esencial es esta: un chatbot genera una respuesta; un agente puede cambiar el estado de otro sistema.
La respuesta no es el sistema completo. El agente observa el estado, decide una acción, ejecuta una herramienta, comprueba el resultado y vuelve a decidir.
01Observarcontexto y estado
→
02Planearobjetivo y próximo paso
→
03Actuartool o entorno
→
04Verificarresultado y parada
↺ actualizar estado
La frontera práctica
La autonomía no elimina el control. Lo desplaza a las herramientas disponibles, los permisos, el presupuesto de pasos y la política de cierre.
objetivotoolsmemoriapolicy
Una tool call no concede autoridad por sí misma. Que el modelo genere send_email(...) no significa que el sistema deba ejecutarlo. El runtime debe validar argumentos, permisos, riesgo y estado antes de producir un efecto externo.
La diferencia está en quién decide el siguiente paso y quién puede ejecutar
Chatbot, workflow, copiloto y agente acotado pueden usar un LLM; cambia qué parte del recorrido fija el código, qué decisiones delega el sistema y dónde se mantiene la autorización.
RECORRIDO FIJADO EN CÓDIGOSECUENCIA DECIDIDA EN RUNTIME
01
CHATBOTGenera una respuesta
usuario→modelo→respuesta
QUIÉN ELIGE EL SIGUIENTE PASOflujo conversacional
EFECTO EXTERNOnormalmente ninguno
La salida termina en texto en este patrón.
02
WORKFLOWEjecuta una ruta conocida
paso A→paso B→paso C
QUIÉN ELIGE EL SIGUIENTE PASOcódigo determinista
EFECTO EXTERNOsí, si el flujo lo define
La ruta puede ser compleja sin ser agéntica.
03
COPILOTOEl modelo propone; una persona decide
modelo→propuesta→aprobación humana
QUIÉN ELIGE EL SIGUIENTE PASOmodelo + humano
EFECTO EXTERNOdespués de aprobación
La autoridad final permanece fuera del modelo.
04
AGENTE ACOTADOEl modelo selecciona entre acciones permitidas
modelo→acción→política del runtime
QUIÉN ELIGE EL SIGUIENTE PASOmodelo, dentro de límites
EFECTO EXTERNOsolo tras autorización
La agencia no concede permisos: el runtime conserva la frontera de autoridad.
NO ES UN RANKINGUn workflow determinista puede ser la arquitectura correcta si el recorrido ya se conoce.
SEÑAL DE AGENCIAEl sistema decide dinámicamente qué acción usar a partir del estado y de resultados intermedios.
SEÑAL DE SEGURIDADDecidir una acción y tener autoridad para ejecutarla son responsabilidades distintas.
Un workflow no es peor por ser determinista. Si los pasos ya se conocen, suele ser más fácil de probar, explicar y limitar. La agencia aporta valor cuando la secuencia depende del entorno y no merece la pena codificar todas las ramas por adelantado.
Un agente fiable necesita más que un prompt y varias funciones:
Objetivo — qué significa terminar correctamente.
Contexto — qué información puede usar en el turno actual.
Herramientas — qué acciones existen y con qué contratos.
Estado — qué operaciones están pendientes, ejecutadas o fallidas.
Memoria — qué información puede persistir entre sesiones y con qué procedencia.
Política — qué requiere autorización, qué está prohibido y qué presupuesto existe.
Verificación — cómo se demuestra que el resultado es correcto.
ARQUITECTURA DEL AGENTE
El modelo decide; el runtime convierte esa decisión en un sistema controlable
Un agente fiable separa razonamiento, autoridad, estado y efectos externos. El LLM propone el siguiente paso; el runtime conserva la fuente de verdad y aplica las reglas antes de actuar.
Un LLM puede producir argumentos estructurados para una función. Eso es tool calling. La agencia aparece cuando el sistema puede decidir cuándo usar una herramienta, interpretar el resultado y escoger qué hacer después.
La tool debe seguir siendo un contrato de software. El modelo propone una llamada; el runtime mantiene la frontera de autoridad y decide si puede ejecutarse.
FRONTERA DE AUTORIDAD
Una tool call es una propuesta, no un permiso
El modelo puede elegir una acción y construir argumentos. La autoridad para producir un efecto externo sigue en el runtime.
Las tres capas participan en la misma tarea, pero no responden a la misma pregunta: el contexto es la vista de trabajo del modelo, la memoria conserva información recuperable y el estado operativo describe la ejecución real que mantiene el runtime.
TRES CAPAS · TRES RESPONSABILIDADES
Contexto, memoria y estado responden a preguntas distintas
El modelo recibe una vista de trabajo; la memoria conserva información recuperable; el runtime mantiene el estado autoritativo de la ejecución.
01
CONTEXTO
¿Qué ve el modelo ahora?
Vista de trabajo limitada: instrucciones, mensajes, documentos recuperados y señales seleccionadas del runtime.
VISIBLE EN ESTE TURNOUsuario: «envía el informe»
La solicitud existe; el efecto externo todavía no.
PROYECCIÓN DEL RUNTIMEsolicitud aceptada · op_id=42
El contexto refleja el estado; no lo sustituye.
PROYECCIÓN DEL RUNTIMEoperación en curso · op_id=42
El modelo puede seguir conversando mientras la tarea continúa.
RESULTADO OBSERVABLEenvío completado · result_id=m_7f2
Solo ahora puede afirmar que la operación terminó.
ALCANCEefímero · acotado por la ventana de contexto
02
MEMORIA
¿Qué podrá recuperarse después?
Persistencia seleccionada: preferencias, hechos confirmados o resúmenes, con procedencia, alcance y reglas de borrado.
SIN ESCRITURA—
Una intención del usuario no es todavía un hecho ejecutado.
SIN ESCRITURA—
Aceptar trabajo no significa haberlo completado.
SIN ESCRITURA DE ÉXITO—
No persistas un resultado antes de verificarlo.
HECHO VERIFICADOinforme enviado · result_id=m_7f2
Puede persistirse si la política de memoria lo permite.
ALCANCEpersistente · recuperable · gobernado
03
Estado operativo
¿Qué está ocurriendo realmente?
Datos del runtime: estado de la operación, reintentos, bloqueos, idempotencia, errores y resultados observables.
FUENTE DE VERDADstatus=requested
Existe una petición, pero aún no hay ejecución aceptada.
FUENTE DE VERDADstatus=accepted · op_id=42
El runtime ha aceptado responsabilidad por la operación.
FUENTE DE VERDADstatus=running · retry=0 · lock=held
La tarea sigue viva aunque cambie el turno conversacional.
FUENTE DE VERDADstatus=succeeded · result_id=m_7f2
El efecto está confirmado por el sistema que lo ejecutó.
ALCANCEautoritativo · transaccional · propiedad del runtime
REGLA DE DISEÑONo derives el estado operativo de lo que dice la conversación.
Contexto = vista · memoria = persistencia · estado = verdad de ejecución.
La separación se vuelve crítica cuando una tool tarda. La conversación puede registrar que una acción fue solicitada mientras el runtime sabe que sigue ejecutándose. Por eso el estado operativo —no el texto del chat ni una memoria recuperada— debe gobernar qué ocurrió realmente y qué puede afirmarse al usuario.
En agentes de voz, ese runtime también tiene que cumplir restricciones físicas de conversación y operación. El explorador de latencia para agentes de voz descompone transporte, fin de turno, STT, modelo, TTS, buffering e interrupción; el planificador de coste y capacidad traduce llamadas, minutos, tokens y concurrencia en coste mensual, workers y límites de proveedor. Son restricciones distintas: una conversación puede ser rápida pero no escalar, o escalar con un presupuesto de latencia inaceptable.
Una respuesta final convincente no basta. Hay que medir la tarea completa: qué decidió el agente, qué pudo ejecutar, qué efecto produjo y si el sistema quedó en un estado correcto y recuperable.
EVALUACIÓN DE AGENTES · TRAZA COMPLETA
Evalúa el resultado y cada transición que lo produjo
Una respuesta final correcta no basta: hay que comprobar qué decidió el agente, qué pudo ejecutar, qué efecto ocurrió realmente y si el sistema quedó en un estado recuperable.
01
CONTRATOObjetivo
Define qué significa terminar correctamente antes de ejecutar.
REGISTRAcaso · criterio de éxito
FALLOobjetivo ambiguo
→
02
MODELODecisión
Selecciona una acción y propone argumentos a partir del contexto.
REGISTRAtool · argumentos · orden
FALLOtool o parámetros incorrectos
→
03
RUNTIMEAutorización
Valida esquema, permisos, riesgo y cualquier aprobación requerida.
REGISTRAgate · permiso · decisión
FALLOacción ejecutada sin autoridad
→
04
TOOLEjecución
Produce un resultado observable: éxito, error, timeout o reintento.
REGISTRAresultado · latencia · retry
FALLOerror oculto o reintento inseguro
→
05
FUENTE DE VERDADEstado
Comprueba el efecto real, la idempotencia y la posibilidad de recuperar.
REGISTRAestado final · efecto · rollback
FALLOduplicado o estado inconsistente
→
06
USUARIORespuesta
Comunica únicamente lo que está respaldado por el resultado observado.
REGISTRAmensaje · evidencia · abstención
FALLOafirmar un efecto que no ocurrió
01 · RESULTADO¿Alcanzó el objetivo?Corrección de la tarea completa, no solo del texto final.
02 · TRAYECTORIA¿Tomó buenas decisiones?Tool, argumentos, orden, pasos innecesarios y evidencia usada.
03 · SEGURIDAD¿Respetó la autoridad?Permisos, aprobaciones, límites y abstención cuando faltaban.
04 · ECONOMÍA¿Cuánto costó llegar?Pasos, tokens, latencia, reintentos y superficie de riesgo.
05 · RECUPERACIÓN¿Quedó un estado sano?Idempotencia, errores observables, rollback y continuación segura.
REGLA DE EVALUACIÓNUna respuesta correcta no compensa una acción prohibida, un efecto duplicado o un estado inconsistente.
La traza convierte el fallo en una transición concreta que puede reproducirse, medirse y corregirse.
La traza hace observables las transiciones que una puntuación final oculta. Permite separar un fallo de selección de tool de uno de autorización, ejecución, estado o comunicación al usuario, y convertir cada incidente en un caso reproducible. El evaluador de fiabilidad y evaluación de agentes permite trabajar con éxito final, primer intento, recuperación tras reintentos, decisiones de herramientas, timeouts y eficiencia de trayectoria como señales separadas.
Cómo evaluar un agente de IA desarrolla una arquitectura de gates para resultado, trayectoria, seguridad y economía operativa.
Por qué la seguridad cambia cuando el sistema puede actuar¶
Un chatbot que interpreta mal un documento puede producir una respuesta incorrecta. Un agente con permisos amplios puede convertir la misma interpretación en una acción.
Por eso la seguridad debe vivir también fuera del prompt: mínimo privilegio, autorización por operación, aislamiento, aprobación humana para acciones sensibles, observabilidad y una ruta externa para detener ejecuciones.
La serie Seguridad en IA cubre prompt injection, jailbreaks, memoria contaminada, red-teaming y controles de producción.
el objetivo está claro pero la secuencia cambia según lo que ocurra;
existen varias herramientas posibles;
los resultados intermedios determinan el siguiente paso;
el sistema puede verificar progreso y resultado;
los permisos y el coste pueden acotarse.
Puede ser mejor un workflow convencional cuando el recorrido es conocido, el margen de error es mínimo o una función determinista resuelve el problema con menos superficie de riesgo.
Depende de la capacidad concreta que se esté usando. Un chat que solo genera texto funciona como asistente conversacional. Un sistema que puede elegir herramientas, operar sobre recursos externos y continuar a partir de sus resultados incorpora comportamiento agéntico. La etiqueta debe describir el sistema real, no solo el modelo que utiliza.
No necesariamente. Recuperar documentos y enviarlos a un modelo puede ser un workflow determinista. Se vuelve parte de un agente cuando el sistema puede decidir cuándo buscar, qué fuente consultar y qué hacer después con el resultado.