LangChain anunció Managed Deep Agents v0.9 el 7 de octubre de 2026, con tareas programadas desde una conversación, configuración por ejecución y reacciones en Slack. La versión está en beta pública en LangSmith Cloud. Publicamos este análisis el 11 de octubre: no es un lanzamiento de hoy ni una nueva beta de LangSmith Cloud.
El cambio interesa a equipos que quieren que un agente retome una tarea más tarde. La cuestión práctica es quién autoriza ese trabajo y qué recursos podrá utilizar cuando llegue el momento.
Programar trabajo exige definir su propietario
La documentación de tareas programadas distingue declaraciones en schedules/, incorporadas al desplegar, de tareas creadas durante una ejecución. Esta segunda vía requiere managed-deepagents 0.9.0 o posterior y herramientas que el desarrollador exponga al agente.
Una tarea puede pertenecer al usuario autenticado o al agente, cuya identidad de servicio es diferente. Por eso no trataríamos «recuérdamelo mañana» como permiso para actuar con cualquier cuenta. Antes de habilitarla, definiríamos propietario, destino y acciones admitidas.
Hay también una diferencia operativa: mda dev no dispara los horarios. Verlos listados en el desarrollo local no acredita que funcionen. Al volver a desplegar se reconcilian las declaraciones estáticas; las tareas creadas durante una conversación no desaparecen por quitar un archivo de schedules/.
Un despliegue, distintas herramientas
La definición del agente puede ser una función que recibe el entorno de la ejecución y devuelve su configuración. Así se seleccionan modelo, instrucciones, skills —instrucciones reutilizables—, servidores MCP —conexiones con herramientas y datos— y entorno aislado de ejecución.
La advertencia decisiva de esa documentación es que el contexto enviado por la aplicación no es una identidad verificada. Un campo que diga «equipo financiero» no concede acceso a facturas. La autorización debe comprobarse dentro de las herramientas contra el usuario verificado. Reducir el conjunto de herramientas visibles resulta útil, pero no sustituye esa comprobación.
Es un producto distinto de Claude Managed Agents y sus workflows dinámicos: aquel artículo trata de coordinar lotes de trabajo, no de esta actualización de LangChain.
Ejemplo hipotético: revisar una incidencia mañana
Imaginemos que soporte pide comprobar mañana si una incidencia sigue abierta. Es una propuesta de diseño, no una prueba ejecutada por Puntoes. Nuestra herramienta confirmaría fecha, zona horaria, propietario y conversación de destino. Solo permitiría consultar el estado y redactar un aviso; cerrar la incidencia necesitaría otra autorización.
Probaríamos tres situaciones: el ticket existe, el acceso está denegado y la consulta falla. En las dos últimas, el agente debería indicar el problema sin inventar el estado ni buscar otra cuenta. Comprobaríamos también que cancelar la tarea impide la siguiente ejecución y que la zona horaria coincide con la solicitada.
El anuncio de v0.9 incorpora reacciones en Slack para acusar recibo. Esa señal no demuestra que el trabajo haya terminado correctamente. Revisaríamos resultados y acciones con los criterios de evaluación de un agente.
Puntoes no ha desplegado esta beta ni medido costes, latencia o fiabilidad. Para decidir una adopción faltaría validar esos puntos con tareas propias; las funciones anunciadas no acreditan por sí solas una operación segura.