Introducción
Las aplicaciones basadas en agentes de IA no siempre encajan bien en el patrón clásico de petición y respuesta inmediata. Una tarea de razonamiento complejo, investigación profunda, análisis en varios pasos o generación extensa de contenido puede tardar minutos. Si el cliente mantiene una conexión abierta durante todo ese tiempo, la experiencia de usuario y la resiliencia del sistema se vuelven más frágiles.
Microsoft ha descrito este problema en el contexto de Microsoft Agent Framework mediante el concepto de background responses o respuestas en segundo plano: iniciar una tarea de agente sin bloquear la conexión hasta que finalice, obtener un token de continuación y recuperar o reanudar el resultado posteriormente.
La idea principal es sencilla: separar el inicio de la operación de su finalización.
El problema del patrón solicitud-respuesta tradicional
En un flujo síncrono convencional, el cliente envía una solicitud y espera hasta que el servidor devuelve el resultado completo. Para operaciones breves, este modelo es simple y efectivo. Para tareas largas, introduce varios riesgos:
- Timeouts de cliente, proxy o servidor: la operación puede seguir siendo válida, pero la conexión expira antes de recibir la respuesta.
- Pérdida de contexto ante cortes de red: si la conexión se interrumpe, el cliente puede no saber si la operación terminó, falló o sigue en curso.
- Mala experiencia de usuario: la interfaz queda bloqueada o aparenta estar congelada.
- Reintentos peligrosos: si el cliente repite la solicitud sin un identificador estable de operación, puede duplicar trabajo o generar resultados inconsistentes.
- Acoplamiento excesivo: la duración de la tarea queda ligada a la duración de la conexión HTTP o del canal de comunicación utilizado.
Estos problemas son especialmente visibles en sistemas con agentes de IA, porque el tiempo de ejecución puede variar mucho según la complejidad de la tarea, el número de pasos intermedios y las llamadas a herramientas o servicios externos.
Qué son las respuestas en segundo plano
Las respuestas en segundo plano permiten iniciar una operación larga y devolver al cliente una referencia para continuar más adelante. En el caso descrito para Microsoft Agent Framework, el cliente inicia una tarea de agente y recibe un token de continuación en lugar de esperar bloqueado hasta que el agente termine.
Con ese token, la aplicación puede:
- Consultar el estado o resultado cuando lo considere oportuno.
- Reanudar una respuesta interrumpida.
- Evitar reiniciar desde cero una operación que ya estaba en progreso.
- Mantener la aplicación cliente disponible aunque el agente tarde más de lo previsto.
Este enfoque no elimina la complejidad de las operaciones largas, pero la desplaza hacia un modelo más controlable: el sistema ya no depende de una única conexión abierta de principio a fin.
Flujo conceptual
Un flujo típico con respuestas en segundo plano puede representarse así:
-
El cliente inicia la operación
Envía una solicitud al agente o al servicio que coordina la tarea. -
El servicio acepta la operación
En lugar de devolver el resultado final, responde con una referencia, como un token de continuación o un identificador de operación. -
La tarea continúa en segundo plano
El agente procesa la solicitud, ejecuta pasos intermedios y genera el resultado sin mantener bloqueado al cliente. -
El cliente consulta o reanuda
Usando el token recibido, el cliente puede comprobar el progreso, obtener el resultado final o reanudar un flujo que se había interrumpido. -
El resultado se entrega de forma controlada
La aplicación decide cuándo y cómo presentar el resultado al usuario: actualización periódica, botón de refresco, recuperación automática o reanudación de una sesión anterior.
Por qué es relevante para agentes de IA
Los agentes de IA suelen ejecutar procesos más largos que una llamada directa a un modelo. Por ejemplo:
- descomponer una tarea en subtareas;
- analizar varios documentos;
- consultar herramientas externas;
- generar contenido extenso;
- validar resultados parciales;
- iterar antes de producir una respuesta final.
En estos escenarios, bloquear la aplicación hasta que termine todo el proceso puede ser una mala decisión de arquitectura. El usuario necesita una confirmación rápida de que la tarea fue aceptada y el sistema necesita una forma fiable de continuar aunque haya cortes de red, cierres de pestaña o cambios de sesión.
Las respuestas en segundo plano encajan especialmente bien cuando la operación es importante, costosa o difícil de repetir.
Diferencia entre una respuesta en segundo plano y una cola genérica
El patrón puede recordar a una arquitectura basada en colas, pero no son exactamente lo mismo.
Una cola de mensajes permite desacoplar productores y consumidores. Es útil para ejecutar trabajo asíncrono, distribuir carga y absorber picos. Sin embargo, una respuesta en segundo plano para agentes añade una semántica más específica desde el punto de vista del cliente:
- existe una operación iniciada por el usuario;
- el cliente recibe una referencia para continuar;
- el resultado puede recuperarse posteriormente;
- si la respuesta estaba en streaming y se interrumpe, puede reanudarse desde el punto correspondiente, cuando la plataforma lo soporta;
- la aplicación puede gestionar el ciclo de vida de la tarea sin repetirla desde cero.
En una arquitectura real, ambos enfoques pueden coexistir. Una cola puede formar parte de la implementación interna, pero el contrato importante para el cliente es el token o identificador que permite continuar la operación.
Consideraciones de diseño
1. Identificador estable de operación
Toda operación larga debería tener una referencia estable. En Microsoft Agent Framework, el artículo de Microsoft habla de un token de continuación. En otros diseños, puede ser un identificador de operación gestionado por el backend.
Ese identificador debe permitir:
- consultar el estado;
- recuperar el resultado;
- correlacionar logs y métricas;
- evitar duplicidades;
- aplicar controles de acceso.
No conviene exponer detalles internos de infraestructura en ese identificador. Debe tratarse como un valor opaco para el cliente.
2. Estado de la operación
El cliente necesita saber en qué punto está la tarea. Un modelo de estados simple puede incluir:
accepted: la operación fue recibida;running: la operación está en curso;completed: la operación terminó correctamente;failed: la operación falló;cancelled: la operación fue cancelada;expired: el token o resultado ya no está disponible.
No todos los sistemas necesitan exponer todos estos estados, pero sí conviene distinguir entre una operación inexistente, una operación en curso y una operación fallida.
3. Reanudación
Uno de los puntos relevantes del enfoque descrito por Microsoft es la posibilidad de reanudar flujos interrumpidos usando el token de continuación. Esto es importante cuando la respuesta se entrega progresivamente y la conexión se corta antes de finalizar.
Desde el punto de vista de producto, la reanudación mejora mucho la experiencia: el usuario no debería perder una tarea larga solo porque cambió de red, cerró el navegador o el cliente tuvo un timeout.
Desde el punto de vista técnico, requiere que el backend conserve suficiente estado para continuar sin repetir todo el trabajo.
4. Idempotencia y reintentos
Las operaciones largas suelen necesitar reintentos. Para que sean seguros, el diseño debe contemplar idempotencia:
- si el cliente reenvía la misma solicitud, el sistema no debería duplicar innecesariamente la operación;
- si el cliente consulta varias veces, no debería alterar el estado;
- si hay un fallo temporal, el sistema debería poder continuar o marcar el error de forma explícita.
Un identificador de operación o token de continuación ayuda, pero no sustituye una estrategia de idempotencia bien definida.
5. Expiración y retención
No todos los resultados deben conservarse indefinidamente. Es recomendable definir:
- cuánto tiempo permanece activa una operación;
- durante cuánto tiempo se puede recuperar el resultado;
- cuándo expira el token;
- qué ocurre con operaciones abandonadas;
- qué datos deben eliminarse por cumplimiento o privacidad.
Esto es especialmente importante si las tareas procesan información sensible.
6. Seguridad
El token de continuación o identificador de operación debe protegerse adecuadamente. Si permite recuperar resultados, debe considerarse información sensible.
Buenas prácticas:
- asociar la operación al usuario, tenant o aplicación que la inició;
- validar autorización en cada consulta o reanudación;
- evitar tokens predecibles;
- limitar la vida útil de los tokens cuando sea apropiado;
- registrar accesos relevantes para auditoría;
- no incluir datos sensibles en URLs si pueden quedar en logs o historial del navegador.
En entornos empresariales, también conviene revisar cómo se almacenan los resultados intermedios y qué políticas de retención se aplican.
Patrones de experiencia de usuario
Una ventaja importante de este enfoque es que permite diseñar mejores interfaces para tareas largas. Algunas opciones habituales son:
- mostrar una confirmación inmediata de que la tarea ha comenzado;
- permitir al usuario cerrar la pantalla y volver después;
- mostrar un indicador de progreso si el backend puede estimarlo;
- ofrecer recuperación automática tras una desconexión;
- notificar cuando el resultado esté disponible, si la aplicación cuenta con un canal de notificación;
- permitir cancelar la operación si todavía está en curso.
La clave es no presentar la tarea como si fuera una llamada instantánea cuando no lo es. El diseño de la interfaz debe reflejar que se trata de una operación potencialmente larga.
Beneficios principales
Adoptar respuestas en segundo plano para operaciones largas aporta varias ventajas:
- Mayor resiliencia: una interrupción de red no implica necesariamente perder todo el trabajo.
- Mejor experiencia de usuario: el cliente no queda bloqueado esperando indefinidamente.
- Menor dependencia de timeouts: la operación deja de depender de una única conexión abierta.
- Reanudación más limpia: el cliente puede continuar usando el token recibido.
- Mejor control operativo: el backend puede registrar, supervisar y gestionar el ciclo de vida de cada tarea.
- Escalabilidad arquitectónica: el procesamiento puede desacoplarse del ciclo de vida de la solicitud inicial.
Riesgos y límites
Este patrón también introduce responsabilidades adicionales:
- hay que almacenar estado de operación;
- se deben proteger tokens y resultados;
- se necesita una política de expiración;
- la observabilidad se vuelve más importante;
- el cliente debe implementar lógica de consulta o reanudación;
- los errores deben modelarse de forma clara.
No es necesario aplicar respuestas en segundo plano a todo. Para operaciones rápidas y deterministas, una respuesta síncrona puede seguir siendo la opción más simple. El patrón tiene más sentido cuando la duración es variable, el coste de repetir la tarea es alto o la experiencia de usuario se degrada al mantener una espera bloqueante.
Relación con Microsoft Agent Framework
El artículo publicado en Microsoft Dev Blogs sobre Handling Long-Running Operations with Background Responses presenta este enfoque específicamente para Microsoft Agent Framework. Según Microsoft, las respuestas en segundo plano permiten iniciar una tarea de agente y recibir un token de continuación en lugar de bloquear la aplicación hasta que la tarea finalice.
El punto más relevante para arquitectos y equipos de desarrollo es que el framework aborda un problema práctico de las aplicaciones con agentes: las tareas de razonamiento pueden tardar lo suficiente como para que el patrón síncrono tradicional sea frágil.
Más que una simple optimización, es un cambio de contrato entre cliente y backend: el cliente no espera necesariamente el resultado completo en la primera respuesta, sino una forma segura de continuar.
Conclusión
Las operaciones de larga duración son cada vez más frecuentes en aplicaciones con agentes de IA. Mantener una conexión abierta hasta que finalice todo el razonamiento no siempre es robusto ni cómodo para el usuario.
Las respuestas en segundo plano ofrecen una alternativa más adecuada: iniciar la operación, devolver una referencia de continuación y permitir que el cliente consulte o reanude el resultado posteriormente. En Microsoft Agent Framework, este patrón se materializa mediante tokens de continuación y soporte para recuperar el trabajo sin reiniciarlo desde cero cuando se producen interrupciones.
Para equipos que diseñan sistemas de IA en producción, el mensaje es claro: las tareas largas deben tratarse como flujos con estado, observabilidad, seguridad y recuperación, no como simples llamadas síncronas que “ya terminarán”.