El trabajo prolongado, los eventos, los checkpoints humanos y las evaluaciones revelan la forma real de una plataforma empresarial de agentes.
Un conjunto de demos de ingeniería publicado por Google Cloud en julio muestra hacia dónde avanza la categoría de plataformas de agentes. Los ejemplos relevantes no son los que redactan un texto brillante. Son los que se detienen para pedir aprobación, despiertan tras un evento, conservan estado durante semanas, ejecutan evaluaciones y conectan una acción con un resultado auditable.
Esa es la forma de un runtime, no de un constructor de chatbots.
El proceso empresarial rara vez es síncrono
Una conversación empieza y termina mientras el usuario está presente. Los procesos de negocio no funcionan así.
Un gasto espera a un responsable. Una incidencia espera documentación. Una compra espera presupuesto. Un caso de mantenimiento se reanuda cuando un sensor o un técnico cambia su estado. Algunas tareas duran minutos; otras, semanas.
Por eso un runtime empresarial necesita más que un bucle de petición y respuesta. Necesita:
- estado duradero que sobreviva reinicios y cambios de modelo;
- activadores basados en eventos;
- pausa, reanudación y cancelación;
- acciones idempotentes que no dupliquen efectos;
- plazos, reintentos y lógica de compensación;
- checkpoints humanos con responsabilidad explícita;
- historial inspeccionable de decisiones y herramientas.
Sin esas capacidades, un “agente de larga duración” suele ser un script frágil que llama a un modelo.
Revisión humana como primitiva de ejecución
Uno de los ejemplos de Google procesa gastos de bajo importe mediante umbrales deterministas, somete los casos de mayor riesgo a controles previos y análisis de cumplimiento, y se detiene para revisión humana antes de finalizar.
Lo importante no es el caso de gastos, sino el patrón.
La revisión humana no debe ser un salvavidas añadido después del lanzamiento. Debe ser un estado de primera clase. El sistema tiene que saber qué evidencia presentar, quién tiene autoridad, qué ocurre si nadie responde y si el proceso puede continuar después de una aprobación parcial.
Los checkpoints cumplen funciones distintas:
- aprobación antes de una acción relevante;
- verificación cuando la confianza queda bajo un umbral;
- gestión de excepciones cuando la política no resuelve el caso;
- muestreo de calidad para control continuo;
- recurso cuando una persona afectada cuestiona el resultado.
Convertirlos todos en “mandar a un humano” crea colas, no control.
Las evaluaciones pertenecen al flujo de release
Un agente puede llegar a una respuesta correcta recorriendo un camino incorrecto. Tal vez use una fuente no autorizada, invoque repetidamente una herramienta cara, exponga datos innecesarios o se salte una aprobación. Evaluar solo la respuesta final oculta el fallo.
Una evaluación de producción debería puntuar la traza:
- ¿Interpretó bien la intención?
- ¿Recuperó el contexto correcto?
- ¿Usó únicamente herramientas permitidas?
- ¿Los argumentos eran válidos?
- ¿Respetó las políticas?
- ¿Verificó el resultado?
- ¿Escaló en el momento adecuado?
- ¿Cumplió los presupuestos de coste y latencia?
Estas pruebas deben ejecutarse cuando cambian prompts, modelos, herramientas, políticas o código del flujo de trabajo. La calidad del agente es una propiedad de cada release, no un benchmark puntual.
Los runtimes crean apalancamiento organizativo
Un runtime compartido puede estandarizar identidad, secretos, trazas, aprobaciones, presupuestos y evaluación. Los equipos se concentran entonces en la lógica de atención, finanzas u operaciones en lugar de reconstruir los mismos controles.
Pero centralizar también tiene coste. Una plataforma puede convertirse en cuello de botella o imponer los supuestos de un proveedor a todos los procesos. Conviene mantener un contrato claro entre runtime y agente: estado, interfaz de herramientas, eventos, telemetría y política. Así se pueden soportar varios marcos sin crear un territorio sin gobierno.
Qué debería preguntar la dirección
Al evaluar una plataforma, hay que ir más allá de “¿en cuánto tiempo hacemos una demo?”:
- ¿Sobrevive una tarea a un despliegue o fallo regional?
- ¿Puede un operador inspeccionar y modificar su estado?
- ¿Las aprobaciones son nativas y están gobernadas por políticas?
- ¿Cómo se evitan efectos duplicados?
- ¿Pueden versionarse herramientas sin romper agentes silenciosamente?
- ¿Las trazas llegan a la arquitectura de observabilidad corporativa?
- ¿Una evaluación puede bloquear un release?
- ¿El runtime funciona bajo red privada e identidad empresarial?
- ¿Cómo se limita el gasto por tarea o unidad?
- ¿Cuál es la salida si la plataforma deja de encajar?
La visión de Lexdatum
La plataforma de agentes se está convirtiendo en el runtime del trabajo delegado.
Su misión no es hacer que un LLM parezca autónomo. Es conseguir que la automatización sea duradera, observable e interrumpible. Las empresas deberían seleccionar runtimes por su capacidad de gestionar estado y consecuencias, no por la belleza de su editor de prompts.
Fuentes
Nota de investigación: este análisis se basa en información pública disponible a 31 de agosto de 2026. Las capacidades, los precios y las interpretaciones regulatorias pueden cambiar. Las métricas comunicadas por proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad o inversión.