Las habilidades de LangChain Deep Agents ahora vinculan herramientas bajo demanda, pero la escala empresarial eleva las exigencias
LangChain ha rediseñado tres partes de su sistema de habilidades Deep Agents después de que las bibliotecas empresariales empezaran a crecer hasta miles de habilidades. La actualización de habilidades de LangChain Deep Agents vincula herramientas a habilidades individuales, fija los flujos de trabajo solicitados antes de la primera llamada al modelo y actualiza los metadatos de habilidades dentro de hilos existentes.
Estas incorporaciones convierten las habilidades de carpetas pasivas de instrucciones en superficies de control en tiempo de ejecución. Una aplicación puede decidir cuándo aparecen herramientas especializadas, qué flujo de trabajo comienza de inmediato y cuándo una conversación activa detecta que una biblioteca de habilidades ha cambiado.
El cambio también crea un problema de ingeniería más complejo. La divulgación progresiva mantiene el contexto bajo control, pero la carga diferida no puede sustituir los permisos, el control de versiones, las pruebas ni la observabilidad. La cuestión central ya no es usar prompts grandes frente a prompts pequeños. Es el descubrimiento automático frente al control explícito en tiempo de ejecución.
Qué cambió en las habilidades de LangChain Deep Agents
LangChain ha acercado la selección de habilidades al momento en que un agente recibe autoridad para actuar.
LangChain anunció los cambios el 7 de octubre de 2026. Su actualización de habilidades presenta tres capacidades relacionadas: herramientas vinculadas a habilidades, habilidades fijadas y recarga de habilidades dentro de un hilo.
Una habilidad es un directorio centrado en un archivo SKILL.md. El frontmatter YAML proporciona su nombre y descripción, mientras que el cuerpo contiene instrucciones operativas. El directorio también puede incluir scripts, referencias, plantillas u otros recursos.
Anteriormente, Deep Agents seguía un patrón de tres etapas. Durante el descubrimiento, el modelo veía el nombre y la descripción de cada habilidad. Durante la activación, leía el SKILL.md pertinente. Durante la ejecución, abría recursos de apoyo cuando las instrucciones lo requerían.
Esa secuencia implementa la divulgación progresiva, lo que significa que el agente carga material detallado solo cuando resulta relevante. Por tanto, una biblioteca grande aporta metadatos compactos al inicio en lugar de incluir cada instrucción y referencia en el prompt.
LangChain afirma que su agente de salida al mercado utiliza más de 50 habilidades para tareas comerciales recurrentes. Entre los ejemplos se incluyen la preparación de reuniones, la revisión de transcripciones de llamadas y la inteligencia competitiva. La empresa también afirma que los registros empresariales están alcanzando miles de habilidades repartidas entre equipos y agentes.
El primer cambio amplía la divulgación progresiva a las herramientas. Una habilidad puede declarar nombres de herramientas o una etiqueta de resolver mediante su frontmatter. Esas herramientas permanecen inaccesibles hasta que el agente lee esa habilidad.
Pensemos en una habilidad de revisión de llamadas con acceso a búsquedas de llamadas y recuperación de transcripciones. El agente no necesita esos esquemas mientras redacta un correo electrónico no relacionado. Una vez que activa la habilidad de llamadas, Deep Agents introduce las herramientas correspondientes.
Esto importa porque los esquemas de herramientas ocupan contexto e influyen en el comportamiento del modelo. Una lista de herramientas saturada puede aumentar el uso de tokens, complicar la selección y exponer operaciones irrelevantes para la solicitud actual.
El segundo cambio permite a las aplicaciones fijar una habilidad. Si un usuario introduce /meeting-prep, la aplicación puede pasar meeting-prep mediante pinned_skills. Deep Agents inserta entonces las instrucciones de la habilidad antes de la siguiente llamada al modelo.
Fijar una habilidad elimina el turno preliminar en el que el modelo identifica y lee la habilidad. También hace que la activación sea determinista porque la aplicación, en lugar del modelo, selecciona el flujo de trabajo solicitado.
El framework no analiza por sí mismo los comandos de barra. Los desarrolladores deben detectar el comando mediante su interfaz o la lógica de la aplicación. Esa separación mantiene las decisiones de sintaxis fuera del entorno de ejecución del agente.
Las habilidades fijadas también incorporan sus herramientas vinculadas. Un usuario que solicita explícitamente la preparación de una reunión puede empezar con las instrucciones del flujo de trabajo y las herramientas de reunión aprobadas ya disponibles.
El tercer cambio aborda los hilos de larga duración. Deep Agents almacena los metadatos de habilidades descubiertas en el estado del agente, de modo que los turnos posteriores reutilizan el mismo catálogo. Ese comportamiento ahorra escaneos repetidos, pero antes dejaba a los hilos activos sin conocimiento de incorporaciones, ediciones o eliminaciones.
Ahora las aplicaciones pueden establecer skills_metadata en None durante la invocación. La siguiente ejecución vuelve a escanear las fuentes configuradas y reemplaza el catálogo almacenado. JavaScript utiliza la forma correspondiente skillsMetadata: null.
El historial de versiones de Python registra la recarga a mitad de hilo en la versión 0.7.16, publicada el 21 de septiembre. La carga de herramientas al activar habilidades llegó después, en la versión 0.7.22 del 5 de octubre.
Son cambios acotados en tiempo de ejecución, no una nueva arquitectura de agentes. Su importancia proviene del punto en el que intervienen. Determinan qué instrucciones y herramientas entran en una conversación activa y cuándo se produce esa transición.
Por qué la vinculación de herramientas cambia la ecuación de escalabilidad
La actualización separa saber que una capacidad existe de recibir las herramientas necesarias para utilizarla.
Los sistemas tradicionales de llamadas a herramientas suelen declarar las funciones que un agente puede invocar con cada solicitud al modelo. Ese enfoque funciona cuando el conjunto es pequeño y estable. Resulta más difícil de gestionar cuando un agente empresarial abarca flujos de trabajo de ventas, soporte, finanzas, investigación e ingeniería.
Un catálogo amplio de herramientas genera varios costes. Los esquemas consumen tokens de entrada, las definiciones repetidas afectan a la latencia y las funciones similares pueden confundir la selección de herramientas. Más importante aún, cada operación expuesta amplía la superficie de capacidades que la aplicación debe gobernar.
Las herramientas vinculadas a habilidades reducen esa superficie durante el uso habitual. El modelo puede saber que existe una habilidad de análisis de transcripciones sin recibir inmediatamente todas las funciones de transcripción y búsqueda de llamadas.
Cuando el agente lee esa habilidad, Deep Agents introduce sus herramientas asociadas después del prefijo de conversación existente. Los proveedores de modelos compatibles pueden procesar esas incorporaciones sin reescribir los mensajes anteriores.
Este orden protege la caché de prompts. Las cachés de prompts reutilizan un prefijo sin cambios en lugar de procesarlo de nuevo. Si una aplicación editara la lista original de herramientas en cada transición, podría invalidar esa parte reutilizable.
OpenAI describe un mecanismo relacionado a nivel de proveedor en su documentación de búsqueda de herramientas. Las herramientas diferidas se cargan cuando son necesarias, mientras que additional_tools puede introducir capacidades en un punto concreto de la conversación.
La similitud revela un movimiento arquitectónico más amplio. Tanto los frameworks de agentes como los proveedores de modelos tratan las herramientas como recursos que pueden llegar de forma dinámica. Ya no asumen que toda función posible deba estar incluida en la solicitud inicial.
El enfoque de LangChain conecta esa incorporación con un flujo de trabajo de nivel superior. Una habilidad agrupa instrucciones operativas, material de apoyo y acceso a herramientas en una sola unidad. Activarla cambia tanto lo que el modelo sabe como lo que puede invocar.
Ese acoplamiento puede mejorar la coherencia. Una herramienta de transcripciones llega junto con instrucciones que describen cómo la organización revisa las llamadas. El agente recibe procedimiento y capacidad juntos, en lugar de tener que adivinar cómo encaja una función genérica en la tarea.
Las etiquetas de resolver amplían este mecanismo más allá de los nombres estáticos. Una aplicación puede asignar una etiqueta a un grupo de herramientas, incluido un servidor completo de Model Context Protocol. MCP es un protocolo para conectar modelos con datos y operaciones externos.
Un resolver también puede examinar el contexto de ejecución. El ejemplo de LangChain permite que una habilidad de pipeline de ventas reciba operaciones de lectura para usuarios habituales, mientras reserva las actualizaciones de previsiones para los responsables.
Esa es la parte más trascendental de la versión. La vinculación de habilidades se convierte en un punto donde la selección de flujos de trabajo y la autorización pueden confluir.
Sin embargo, la vinculación no debe convertirse en la única capa de seguridad. Un archivo de habilidad es contenido de instrucciones orientado al modelo, no un proveedor de identidad ni un motor de políticas. Los servicios de backend aún deben validar cada solicitud privilegiada.
Una habilidad maliciosa o mal redactada podría instruir a un agente para hacer un mal uso de una herramienta expuesta legítimamente. También podría solicitar entradas más amplias de lo que requiere la tarea. Por ello, la autorización en tiempo de ejecución debe aplicar la identidad del usuario, los límites de tenant, el tipo de operación y el alcance del recurso.
Los esquemas de herramientas también siguen siendo entradas no confiables desde la perspectiva de la aplicación. OpenAI recomienda a los desarrolladores validar los esquemas devueltos mediante la carga avanzada de herramientas ejecutada por el cliente. El mismo principio se aplica a las herramientas de habilidades resueltas dinámicamente.
Los equipos empresariales deben mantener listas de permitidos entre identificadores de habilidades y grupos de capacidades aprobadas. Un resolver debe rechazar etiquetas desconocidas en lugar de aceptar nombres arbitrarios procedentes de los metadatos de habilidades.
Los registros de auditoría deben capturar la habilidad que hizo aparecer cada herramienta. Sin ese vínculo, los investigadores podrían ver solo una llamada a una herramienta y pasar por alto la transición de flujo de trabajo que la autorizó.
La interfaz del agente también debe exponer esa transición. Los usuarios necesitan una señal clara cuando una conversación pasa del asesoramiento a la acción, especialmente para herramientas que modifican registros de clientes o sistemas internos.
Para los desarrolladores que crean flujos de trabajo similares y con mucha carga de conocimiento, una base de conocimiento con búsqueda ilustra el problema de contenido adyacente. El contexto útil debe poder descubrirse sin incluir cada documento en cada solicitud.
LangChain aplica ese mismo principio de recuperación a la capacidad operativa. El entorno de ejecución revela una herramienta especializada solo después de que la tarea llega a la habilidad correspondiente.
Eso no vuelve inocuo a un agente. Hace que el límite de capacidad sea más pequeño, más tardío y más fácil de observar.
Las habilidades fijadas sustituyen una conjetura por una solicitud explícita
Las habilidades fijadas ofrecen a las aplicaciones una ruta determinista cuando los usuarios ya conocen el flujo de trabajo que desean.
La selección automática de habilidades es práctica cuando una solicitud es ambigua. El modelo revisa las descripciones, identifica una coincidencia probable y lee el archivo seleccionado. Esa flexibilidad cuesta al menos una interacción adicional antes de que comience el trabajo especializado.
También introduce riesgo de selección. Dos habilidades pueden tener descripciones que se solapan, o las palabras del usuario pueden no coincidir con el activador previsto. Un catálogo amplio hace más probables esas colisiones.
Las habilidades fijadas abordan el caso en que el descubrimiento no aporta valor. Un vendedor que escribe /meeting-prep for my Acme call ya ha seleccionado el flujo de trabajo. Pedir al modelo que infiera la misma elección desperdicia tiempo y añade incertidumbre.
Deep Agents puede añadir la habilidad fijada como un mensaje etiquetado antes de la primera llamada al modelo. Según LangChain, el modelo comienza entonces la tarea solicitada en la primera llamada, en lugar de leer la habilidad en la primera llamada.
Esa diferencia puede mejorar la latencia percibida incluso si el recuento total de tokens apenas cambia. Los usuarios perciben la primera respuesta como trabajo productivo en lugar de configuración.
También puede respaldar el diseño de interfaces. Una aplicación de chat puede mostrar una etiqueta compacta de habilidad mientras mantiene las instrucciones subyacentes disponibles para el modelo. Los usuarios pueden ver qué flujo de trabajo rige la respuesta sin leer todo el SKILL.md.
La función no elimina la activación automática. Las aplicaciones pueden conservar el descubrimiento para solicitudes en lenguaje natural, al tiempo que ofrecen comandos explícitos para flujos de trabajo frecuentes o de alto riesgo.
Ese modelo híbrido crea una división útil del trabajo. El modelo gestiona la intención abierta, mientras que la interfaz gestiona la intención declarada.
La guía de skills de Anthropic destaca la importancia de descripciones precisas porque los modelos las utilizan para seleccionar entre las skills disponibles. Señala que los metadatos se cargan primero, mientras que las instrucciones completas solo se cargan cuando una skill se vuelve relevante.
La selección fijada reduce la dependencia de la calidad de las descripciones para solicitudes explícitas. No reduce la necesidad de contar con descripciones precisas en otros casos. Los usuarios no nombrarán todas las skills, y los agentes aún deben elegir entre las opciones automáticas.
Las aplicaciones también necesitan reglas de conflicto. Un usuario podría fijar una skill mientras su mensaje encaja naturalmente con otra. Dos flujos de trabajo fijados podrían ofrecer instrucciones contradictorias o herramientas superpuestas.
La opción predeterminada más segura es tratar la fijación como una solicitud explícita, no como una anulación incondicional de todas las reglas del sistema. Las políticas de la plataforma, los controles de acceso y las instrucciones de mayor prioridad deben seguir rigiendo la sesión.
Los equipos de producto deben definir si se permiten varias skills fijadas. Si es así, la interfaz debe explicar su orden y cualquier regla de precedencia.
También deben decidir cuánto tiempo permanece activa una fijación. LangChain añade cada skill fijada una vez y borra la solicitud de fijación pendiente. Sin embargo, sus instrucciones permanecen en el historial de la conversación después de insertarse.
Esa persistencia crea una sutil cuestión de ciclo de vida. Un flujo de trabajo de preparación de reuniones útil durante un turno podría influir en solicitudes posteriores del mismo hilo. La aplicación necesita una política para los límites de los flujos de trabajo, la bifurcación de conversaciones o la compactación de contexto.
La inyección de prompts sigue siendo otra preocupación. Las skills son instrucciones, y los archivos de apoyo pueden contener material adicional. Los equipos deben tratar cada fuente de skills como parte del límite de confianza del agente.
Anthropic explicita ese riesgo en su documentación sobre skills gestionadas. Advierte que los colaboradores de un repositorio pueden añadir o modificar instrucciones que más tarde se ejecuten junto a herramientas como acceso al shell o recuperación web.
La lección se aplica más allá de cualquier proveedor individual. Un registro de skills es conocimiento organizativo ejecutable, incluso cuando su archivo principal es Markdown.
Por ello, las empresas deben revisar las skills como si fueran código. Los cambios necesitan responsables, ramas protegidas, pruebas, historial de versiones y aprobación de despliegue proporcional a sus permisos.
Un comando fijado hace que la activación de skills sea más predecible. No demuestra que la skill activada sea correcta, esté actualizada o sea segura.
La recarga de hilos resuelve la desactualización, pero crea un límite de versiones
La recarga permite que un hilo activo vea una biblioteca de skills cambiante, pero también modifica las reglas que rigen esa conversación.
Los hilos de agentes de larga duración aportan continuidad. Conservan mensajes, estado y decisiones previas para que los usuarios no tengan que reiniciar trabajos complejos. Los metadatos de skills almacenados en caché respaldan esa continuidad al evitar descubrimientos repetidos.
La desventaja es la desactualización. Un equipo puede añadir una skill de inteligencia competitiva después de que comience un hilo. También puede reparar un flujo de trabajo existente o eliminar uno que ya no cumple la política.
Sin invalidación, el hilo continúa utilizando su catálogo original. Las conversaciones nuevas reciben la biblioteca revisada, mientras que las conversaciones antiguas operan con una instantánea anterior.
Establecer skills_metadata en None indica a Deep Agents que vuelva a explorar las fuentes de skills. La implementación en tiempo de ejecución del middleware documenta tanto los reinicios en el momento de invocación como las actualizaciones directas de estado.
Esto es invalidación, no sincronización automática. La aplicación decide cuándo solicitarla. Esa distinción evita explorar cada fuente en cada turno, pero deja la política de actualización en manos del desarrollador.
Una lista vacía no equivale a None. Una lista vacía representa un catálogo cargado correctamente que no contiene skills. None significa que el catálogo almacenado debe reconstruirse.
Esa diferencia importa para checkpoints antiguos, migraciones y middleware personalizado. Tratar ambos valores como intercambiables puede dejar un hilo permanentemente vacío o activar cargas innecesarias.
La implementación de JavaScript va más allá al recargar antes de la siguiente llamada al modelo. Un middleware puede invalidar después de una respuesta del modelo, permitiendo que una llamada posterior dentro de la misma ejecución vea una skill recién escrita.
La recarga puede invalidar el almacenamiento en caché de prompts cuando cambia el prompt del sistema resultante. LangChain sostiene que las conversaciones inactivas suelen volver después de que las cachés de los proveedores ya hayan expirado, lo que reduce el coste práctico.
La cuestión más amplia es la reproducibilidad. Una conversación puede empezar bajo una versión de skills y continuar bajo otra tras una recarga. Las salidas posteriores pueden reflejar reglas que no regían decisiones anteriores.
Esa transición debe registrarse. Un agente de producción necesita adjuntar a su traza de ejecución la revisión del catálogo de skills, los hashes de contenido, las ubicaciones de origen y la hora de recarga.
Los flujos de trabajo sensibles pueden requerir controles más sólidos. En lugar de aceptar siempre el catálogo más reciente, una aplicación podría fijar un hilo a una versión aprobada y recargar únicamente durante una migración gestionada.
Esa estrategia intercambia actualización por reproducibilidad. Es adecuada para revisiones reguladas, operaciones financieras o cualquier proceso en el que los auditores deban reconstruir las instrucciones exactas disponibles en cada paso.
Otros flujos de trabajo se benefician de actualizaciones inmediatas. Los agentes de soporte pueden necesitar un procedimiento de escalación recién aprobado sin abandonar conversaciones activas con clientes. Los equipos de seguridad pueden necesitar revocar rápidamente una skill peligrosa.
Por tanto, la política correcta depende del tipo de cambio. Las adiciones a menudo pueden esperar a un límite natural. Las correcciones y eliminaciones críticas pueden requerir invalidación inmediata.
Una recarga también necesita un comportamiento ante fallos. Una caída del almacenamiento, un frontmatter mal formado o un error de permisos no deberían producir silenciosamente un catálogo parcial.
Las aplicaciones deben decidir si conservan la última versión válida conocida, fallan de forma cerrada o continúan con advertencias. Esa elección debe variar según la autoridad de las skills afectadas.
El rastreador actual de incidencias de Deep Agents ilustra por qué las pruebas operativas son importantes. Los usuarios han informado de metadatos mal formados, errores en rutas de descubrimiento y archivos cuya codificación impide la carga.
Esos informes no invalidan la actualización. Muestran que la extensibilidad basada en el sistema de archivos hereda los problemas habituales de configuración de software.
Los equipos necesitan pruebas de contrato para cada paquete de skills. Las pruebas deben verificar los metadatos, los archivos referenciados, las etiquetas de los resolvers, los conjuntos de herramientas autorizadas y el comportamiento de activación.
También necesitan evaluaciones de comportamiento. Una skill sintácticamente válida aún puede ser imprecisa, entrar en conflicto con otro flujo de trabajo o hacer que el agente elija una secuencia insegura.
La recarga acelera el despliegue, pero un despliegue más rápido eleva el coste de una validación débil. Una instrucción defectuosa puede llegar a cada hilo actualizado sin necesidad de reiniciarlo.
El modelo operativo más útil se parece a la gestión de versiones de software. Los autores crean una skill versionada, las comprobaciones automatizadas la validan, los revisores la aprueban y el despliegue genera una revisión de catálogo rastreable.
Los hilos se recargan entonces conforme a una política documentada. Los operadores pueden identificar qué conversaciones adoptaron el cambio y revertirlo si las evaluaciones empeoran.
LangChain ha proporcionado el control de invalidación. Las empresas aún deben construir la disciplina de lanzamiento a su alrededor.
Lo que los desarrolladores deberían vigilar a continuación
El éxito de la actualización de skills de LangChain Deep Agents dependerá de un comportamiento medible, no de la elegancia de su modelo de carga.
La primera señal es la calidad de selección de herramientas a escala. Los equipos deberían comparar agentes con catálogos de herramientas completamente expuestos frente a agentes que utilizan herramientas vinculadas a skills.
Entre las medidas útiles se incluyen la selección de herramientas incorrectas, los tokens de entrada relacionados con esquemas, el tiempo hasta la primera acción útil y los intentos de autorización fallidos. Las mejoras en estas medidas respaldarían la tesis de carga progresiva de LangChain.
La comparación debe utilizar tareas reales. Una demostración con dos skills claramente diferenciadas no revelará colisiones entre cientos de flujos de trabajo empresariales similares.
La segunda señal es la gobernanza en torno a resolvers y registros. Las etiquetas de skills que desbloquean dinámicamente servidores MCP u operaciones de escritura requieren una política centralizada.
Esté atento a ejemplos más sólidos que cubran el aislamiento de tenants, las puertas de aprobación, las listas de permitidos de resolvers y los cambios de capacidades auditables. Esos patrones determinarán si la vinculación se convierte en un control empresarial o simplemente en una comodidad.
La tercera señal es el conjunto de herramientas de ciclo de vida para hilos activos. La recarga resulta más valiosa cuando los operadores pueden seleccionar versiones de catálogo, inspeccionar diferencias y migrar hilos de forma segura.
La actualización de LangChain proporciona actualmente el restablecimiento de estado necesario para actualizar los metadatos. Los equipos de producción aún necesitarán paneles de despliegue, puertas de evaluación y rutas de reversión.
La compatibilidad de los proveedores también influirá en la adopción. Añadir herramientas durante una conversación funciona mejor cuando los modelos aceptan definiciones de herramientas posteriores mientras preservan el contexto almacenado en caché.
La carga diferida de herramientas de OpenAI sugiere que este patrón está avanzando hacia las API de los proveedores. Un soporte similar entre modelos haría más portátiles las implementaciones a nivel de framework.
La competencia también llegará desde plataformas de agentes gestionados. Anthropic admite skills basadas en el sistema de archivos y configuraciones explícitas de sesión, mientras que otros sistemas exponen cada vez más instrucciones reutilizables, herramientas y conexiones MCP.
La ventaja de LangChain es la flexibilidad de orquestación. Los desarrolladores pueden conectar la activación de skills con sus propios backends, estado, interfaces y lógica de autorización. Esa libertad también transfiere una mayor responsabilidad operativa al propietario de la aplicación.
Los equipos que evalúen la versión deberían evitar reducir la decisión al ahorro de tokens. La pregunta más importante es si una skill crea un límite claro e inspeccionable alrededor de las instrucciones y la autoridad.
Una buena implementación debería responder cinco preguntas para cada acción. Qué skill se activó, quién la solicitó, qué herramientas aparecieron, qué política las permitió y qué versión de la skill rigió el resultado.
Si alguna respuesta no está disponible, la divulgación progresiva ha mejorado la composición del prompt sin completar el plano de control.
La palabra clave principal, skills de LangChain Deep Agents, describe una categoría de funcionalidades que se está convirtiendo en infraestructura. Las skills ahora se sitúan entre la intención del usuario, el procedimiento organizativo, el contexto del modelo y los permisos de herramientas.
Esa posición las hace útiles, pero también sensibles. Una descripción desactualizada puede bloquear el descubrimiento. Una skill comprometida puede redirigir el comportamiento. Un resolver demasiado amplio puede exponer capacidades que el usuario nunca necesitó.
Los tres cambios de LangChain abordan una presión de escalabilidad real. La vinculación de herramientas reduce el desorden inicial de capacidades, la fijación elimina turnos de selección evitables y la recarga mantiene actualizados los hilos de larga duración.
El trabajo restante corresponde a los implementadores. Deben hacer visible la activación, aplicar la autorización fuera del prompt, versionar cada skill y probar los cambios de catálogo antes del despliegue.
Para una evaluación informativa, comience con un flujo de trabajo que tenga herramientas diferenciadas y resultados medibles. Compare el descubrimiento automático con la fijación explícita y, después, inspeccione cada transición de capacidades en la traza.
Después de eso, pruebe una actualización controlada de una skill dentro de un hilo existente. Confirme que se carga la versión prevista, que se entiende el impacto en la caché y que la reversión restaura el comportamiento anterior.
La pregunta decisiva no es si miles de skills pueden caber detrás de metadatos compactos. Es si las organizaciones pueden gobernar miles de paquetes de instrucciones cambiantes sin perder el control de los agentes que los utilizan.
