Cómo construimos nuestro agente de diseño

Conclusiones clave

• El buen gusto proviene del contexto. Los modelos ya escriben buen código, pero necesitan los principios de tus diseñadores, barreras contra el slop de la IA y el razonamiento detrás de los comentarios para crear trabajo que se parezca al tuyo.
• Dale al agente la computadora de un diseñador. Cada hilo de Slack obtiene su propio sandbox donde el agente mantiene el proyecto entre turnos, trabaja con un motor de video, herramientas de imagen y un lienzo compartido, e inspecciona sus propios renderizados.
• Elimina las reglas cuando el modelo mejore. Las reglas que compensan las debilidades de un modelo caducan, así que conserva los principios de diseño y elimina las soluciones provisionales a medida que los modelos mejoran.
• Los agentes de larga duración necesitan UX multijugador. Los trabajos grandes se ejecutan durante horas en subagentes asíncronos, por lo que el hilo de Slack muestra el plan, el progreso en vivo y una aprobación antes de que algo se publique, y cualquier persona del equipo puede guiar al agente a mitad de la ejecución.
• Puedes hacerle un fork. El repositorio de código abierto tiene el harness completo, y Managed Deep Agents lo despliega en el Slack de tu equipo.

‍

La promoción de arriba fue creada por Content Studio, nuestro agente de diseño que puede crear videos, gráficos para redes sociales, imágenes de UI recreadas, presentaciones de diapositivas y más a partir de un solo prompt en Slack. Cada elemento que produce el agente está escrito en código.

Content Studio fue construido completamente internamente con Managed Deep Agents. Ahora es uno de los agentes GTM más utilizados dentro de nuestra empresa, pero no comenzó así. Los primeros comentarios fueron... nada buenos.

Entonces, ¿cómo pasamos de una calidad tan baja a esto?

Hemos pasado cuatro meses enseñándole a Content Studio nuestro gusto y principios de diseño, principalmente observándolo cometer errores frente a toda la empresa.

Esta publicación explica cómo nuestro equipo de GTM Engineering trabajó con nuestro equipo de diseño para construir Content Studio desde cero: qué significa el buen diseño para nosotros, cómo le enseñamos al agente nuestro gusto, y el harness que le permite crear cualquier cosa, desde una imagen fija hasta una película de lanzamiento.

Hemos abierto el código de nuestro agente de diseño. Haz un fork del repositorio de código abierto, añade tus tokens de marca, fuentes y skills, y despliegalo en el Slack de tu equipo con Managed Deep Agents.

Luego únete a nosotros en GTM Engineering Live el 28 de octubre. Nos adentraremos en las entrañas del harness y la UX, y mostraremos el trabajo que no cupo en esta publicación.

Construyendo un agente de diseño para escala

LangChain avanza rápido. Tenemos campañas constantes de lanzamiento de productos, webinars, blogs y eventos. Cada iniciativa necesita materiales, desde encabezados de blog y diagramas hasta presentaciones, videos y creatividades publicitarias. Nuestro equipo de diseño estaba desbordado, y las solicitudes repetitivas desplazaban el trabajo más estratégico e innovador. Como una startup reducida, necesitábamos una forma de baja fricción para que cualquier persona de la empresa pudiera crear trabajo de alta calidad y acorde a la marca.

Para abordar estas necesidades, construimos Content Studio, un agente de diseño que vive en Slack. Un miembro del equipo describe lo que quiere y adjunta el contenido o los briefs correspondientes, y el agente devuelve archivos terminados y acordes a la marca. Para construir Content Studio, necesitábamos tres cosas:

1. El criterio experto de nuestros diseñadores, escritas en las habilidades del agente y en las comprobaciones para que sepa cómo es un buen resultado.
2. Un entorno personalizado alrededor del modelo, incluyendo una computadora de edición de video con herramientas para cada capa del trabajo de diseño.
3. La UX adecuada, para que todo un equipo pueda colaborar en un proyecto que se ejecuta durante horas desde un solo hilo de Slack.

Managed Deep Agents nos dio todo lo que necesitábamos para llevar Content Studio a producción dentro de nuestra empresa: un LangSmith Sandboxadministrado, integración con Slack, herramientas administradas, memoria del agente con alcance y programación de ejecuciones del agente. Esto permite que un equipo pequeño dedique su tiempo al trabajo de diseño, a las habilidades, las herramientas y la experiencia de Slack, en lugar de a la fontanería.

Resultados clave

• Content Studio ha entregado más de 3,000 activos en toda la empresa, incluyendo más de 80 presentaciones de diapositivas. Una de sus presentaciones se usó incluso en nuestro video orgánico de YouTube más visto.
• Las publicaciones con su trabajo acumularon alrededor de 4.5M de vistas en X.
• En la cuenta de LangChain, las publicaciones con sus visuales han obtenido aproximadamente 2 veces más likes y 3.7 veces más marcadores que otras publicaciones.
• Tres de cada cuatro solicitudes ahora provienen de fuera de marketing, y el 75% de los usuarios son visitantes recurrentes que regresan cada semana.
• La solicitud mediana ahora cuesta alrededor de 50 centavos en gasto de modelo, frente a unos $8 a mediados de septiembre. Nuestro propio código se redujo en aproximadamente un 80% tras la migración a Managed Deep Agents.

¿Es la IA realmente buena en diseño?

Antes de entrar en la construcción, abordemos primero el debate del siglo: ¿puede la IA realmente producir un buen diseño?

El modelo ya era bueno en la ejecución y podía escribir HTML y CSS, especificaciones de gráficos y líneas de tiempo de animación. Sin embargo, no tenía nuestro contexto, por lo que recurría a patrones familiares, lo que Anthropic llama “convergencia distribucional”. El resultado podía verse pulido y aun así parecerse a otros cien, o estar bellamente animado y no transmitir nunca su mensaje. Lo familiar no siempre es malo, pero queríamos que nuestro agente tomara decisiones que siguieran su propósito.

Katie Dill, jefa de diseño en Stripe, hace una comparación útil. Bajo la presión de construir rápidamente después de la Segunda Guerra Mundial, los constructores copiaron una y otra vez las formas limpias y las superficies desnudas del modernismo. Las copias conservaban la apariencia mientras perdían el pensamiento y el carácter que había detrás. Su advertencia es que la IA puede hacerle lo mismo al software. Ella lo llama “zombie UI” y dice que necesitamos un punto de vista, porque “si no lo tienes, la IA te lo dará”.

No creemos que la IA sea mala en diseño. Simplemente no tiene un punto de vista a menos que se lo proporciones, y darle el nuestro significó enseñarle nuestro gusto.

Enseñarle gusto a un agente de diseño

El gusto es el criterio que separa el trabajo correcto del trabajo bueno. En diseño, dos maquetaciones pueden usar las fuentes, los colores y el espaciado correctos, y solo una de ellas transmite su mensaje. El gusto proviene de lo que Dill llama "volverse muy bueno en fijarse".

Ese fijarse es cómo aprendimos a detectar el slop de la IA, que aparece con mayor frecuencia cuando un brief deja una decisión al agente.

Por ejemplo, la imagen de abajo a la izquierda fue creada por un agente de codificación local con nuestro brand skill (que incluye colores, fuentes, logos, etc.). Pero el resultado final omitió componentes críticos, como el logotipo correcto, la alineación del texto y qué colores eran nuestros colores de marca primarios frente a los secundarios.

El mismo prompt produjo una imagen perfectamente alineada con la marca en Content Studio. Esto ocurrió porque el agente local completó cada decisión que el brief no cubría con lo que más había visto. Con esta metodología, Content Studio llenó los mismos vacíos con nuestras decisiones.

Las pautas que le dimos a Content Studio comenzaron con lo básico, incluyendo tokens de color, grosores de fuente, espaciado y alineación. Pero gran parte de la mejora provino de lo que añadimos encima. Introdujimos principios de diseño, como tener un punto focal por fotograma, barreras contra patrones comunes de diseño de IA, y el razonamiento detrás de cada comentario. Combinado con mejores modelos subyacentes, esto ayudó a Content Studio a aprender a pensar y comunicarse más como un diseñador.

No empezó así. En uno de nuestros primeros gráficos en movimiento, un pájaro sale volando de la pantalla con una cinta de luz que lo sigue durante menos de un segundo. Pedimos que no hubiera bordes afilados, pero la primera versión volvió torpe, con bordes duros y redondeados. Un diseñador habría entendido lo que queríamos decir. Los bordes debían suavizarse, mientras la cola se estrechaba y se desvanecía en la dirección opuesta al movimiento del pájaro.

En una iteración posterior, el agente evaluaba ese detalle con ojo de diseñador. Usando un boceto rápido para identificar dónde debía estar la cola del pájaro, construyó su propia verificación fotograma a fotograma para asegurar que la cinta permaneciera unida. La mayoría de los espectadores nunca notaría el detalle conscientemente, pero lo sentirían si algo estuviera mal.

Los problemas medibles fueron los más fáciles de resolver. El uso de mayúsculas por defecto solía surgir con frecuencia en las revisiones, pero ahora una verificación automatizada detecta cada instancia. Las decisiones más difíciles son más subjetivas, como si una idea de campaña es lo suficientemente sólida, si el mensaje se transmite con claridad o si la ejecución resuena con la audiencia. Cuando un diseñador toma una de esas decisiones, capturamos el razonamiento en un skill para que el agente pueda aplicarlo a borradores futuros.

Content Studio cambió quién puede hacer trabajo de diseño. Un PM, ingeniero o fundador puede encargar algo al agente en Slack y marcharse con algo alineado con la marca y listo para publicar. Tres de cada cuatro solicitudes ahora provienen de fuera del área de marketing. Para los diseñadores, el rol se ha acercado al de un director creativo, marcando la dirección y revisando el trabajo en lugar de producir cada recurso ellos mismos.

Acertar con el criterio de diseño fue una parte del proceso. También necesitábamos darle al agente las herramientas y el entorno para ejecutarlo.

Construyendo un media harness

Un diseñador trabaja con varias herramientas, desde Photoshop para imágenes fijas y un motor de video para movimiento, hasta un lienzo compartido para prototipar y colaborar. También dependen de pautas de marca, recursos de diseño y documentación de la empresa.

Un agente necesita una configuración similar, con una computadora en la que trabajar, herramientas para las distintas partes del proceso de diseño y el contexto que un diseñador aporta a su trabajo. El harness reúne estas piezas. Deep Agents proporciona el harnesssubyacente, incluyendo el bucle del agente, la planificación, los archivos, los subagentes y la gestión del contexto. Managed Deep Agents lo empaqueta y lo ejecuta en producción. Nosotros construimos el entorno a su alrededor, dándole al agente una computadora donde puede mantener un proyecto, trabajar con varias herramientas e inspeccionar los resultados.

harness_v1

Nuestra primera versión de ese harness intentaba hacer el diseño por el modelo. Los primeros modelos necesitaban mucha ayuda para crear un gráfico en movimiento o una película de lanzamiento que quisiéramos publicar. Para compensar lo que aún no podían resolver por sí mismos, nuestra intuición fue poner más de nuestro propio criterio de diseño en instrucciones y código.

Así que construimos un sistema de diseño con 115 componentes de UI reutilizables para títulos, maquetaciones y animaciones, junto con orientación sobre cuándo y cómo usarlos. Esto le dio al modelo un conjunto de diseños existentes en los que basarse, reduciendo la cantidad de decisiones creativas que tenía que tomar desde cero.

Eso le ayudó a mantenerse alineado con la marca, pero el agente simplemente repetía las mismas maquetaciones y animaciones en cada fotograma sin mucha variedad:

Sabíamos que los modelos eventualmente serían geniales en esta tarea, así que seguimos construyendo el entorno para ese momento, experimentando con las habilidades y las herramientas en el camino. A veces agregábamos más referencias o instrucciones más detalladas para ayudar al modelo. Otras veces las eliminábamos por completo y veíamos qué podía hacer por su cuenta.

Pero los resultados todavía no estaban donde queríamos, y cerrar la brecha requería cada vez más trabajo de ingeniería. Seguíamos agregando reglas a las habilidades, escribiendo más código de movimiento y construyendo más componentes para compensar lo que el modelo no podía hacer.

Luego llegó Opus 5.5, y vimos un salto inmediato en la calidad. Revisamos las habilidades y eliminamos la mayoría de las reglas codificadas de forma rígida, conservando los principios de diseño y la orientación de alto nivel. Los resultados mejoraron aún más, con más variedad y menos repetición. El modelo finalmente estaba tomando decisiones creativas que antes intentábamos preconstruir para él.

Esta fue nuestra Bitter Lesson. Las reglas diseñadas para compensar las debilidades de un modelo se vuelven menos útiles a medida que los modelos mejoran. Lo que perdura es el entorno alrededor del modelo, incluidas las herramientas que usa, el contexto del que parte y cómo las personas guían su trabajo. En lugar de preconstruir decisiones creativas, nos enfocamos en hacer que el harness fuera lo suficientemente flexible para aprovechar cada nueva generación de modelos.

Computadora del diseñador

Para mostrar el harness en acción, le pedimos a Content Studio que hiciera una película sobre cómo trabaja con un proyecto de video de principio a fin. El resultado protagoniza a un loro en una jungla de píxeles narrado al estilo de David Attenborough (con voz de ElevenLabs). Usemoslo para recorrer las capas del harness: computadora, herramientas y contexto detrás de su trabajo.

El diseño es iterativo. Haces algo, lo miras y lo cambias, a menudo muchas veces. Así que el agente necesita una computadora en la que pueda seguir trabajando a lo largo de toda una conversación. Cada hilo de Slack obtiene su propio LangSmith Sandbox, una máquina Linux aislada con un sistema de archivos y un shell, y el proyecto vive allí durante la vida del hilo.

Todo lo que el agente crea se construye con código, ya sea una página HTML para una diapositiva, una especificación de datos para un gráfico o una línea de tiempo de animación para un video. Esto facilita iterar sin empezar de cero. Si alguien pide que el loro aparezca antes, el agente puede cambiar un solo valor de tiempo y volver a renderizar sin afectar la obra gráfica ni el texto. Con una imagen plana o un clip de video generado, incluso una pequeña edición podría significar recrear todo el recurso.

El brief, el plan, el código de las escenas, el audio y los renders viven todos en una carpeta de proyecto de la que trabaja cada subagente del encargo.

Además, instalamos las herramientas que un diseñador usaría en cada capa del trabajo:

El movimiento es la capa más difícil. Funciona sobre dos motores:

1. HyperFrames para la edición: HyperFrames, el framework de video de código abierto de HeyGen, convierte un video en una página web. Los clips, las grabaciones de pantalla, los subtítulos y el texto son solo elementos en esa página, y una línea de tiempo de GSAP los mueve. Así que cuando alguien pide subtitular un webinar o cortar una demo de producto, el agente lo edita como una página web. Su CLI es básicamente la suite de edición del agente: validar la composición, extraer un fotograma para revisar, renderizar el corte. También instalamos las habilidades oficiales de HeyGen, para que el agente aprenda el formato de las personas que lo construyeron.
2. motion-studio para la animación: Una página web no puede desenfocar el movimiento rápido, hacer que las cosas brillen ni girar un logo en 3D, y ese era el acabado que queríamos para la animación original. Así que construimos nuestro propio motor de canvas. El agente escribe código que dibuja cada píxel de cada fotograma, y el motor mezcla hasta 16 momentos en cada uno, de la misma manera que el obturador de una cámara desenfoca el movimiento. La película del loro se hizo de esta manera.

Ambos motores renderizan cada fotograma según su marca de tiempo, por lo que un fotograma a los diez segundos se ve igual sin importar cuándo se renderice. Esto permite al agente inspeccionar momentos individuales sin renderizar toda la película, y también nos permite renderizar varios fotogramas en paralelo. El audio funciona en la misma línea de tiempo, manteniendo la narración, la música y los efectos de sonido sincronizados con las imágenes.

Con esta configuración, el agente puede crear casi cualquier cosa. Pero sin una guía adicional, recurre por defecto a las propias decisiones de diseño del modelo en lugar de las nuestras. El siguiente desafío fue enseñarle a trabajar dentro de nuestra marca y nuestros estándares de diseño.

Cerebro del diseñador

Organizamos el conocimiento del agente en torno a cuatro funciones distintas, cada una con un propósito claro. Las habilidades guían cómo realizar tareas específicas, mientras que la wiki proporciona contexto sobre nuestra empresa y cómo es el buen trabajo. Todo lo que es medible se maneja con un gate, una verificación determinista escrita en código. Una capa de memoria separada captura lo que las personas le enseñan al agente con el tiempo.

Habilidades

Lo primero que hace el agente con una solicitud es determinar qué tipo de trabajo es. Eso lo maneja nuestra media-production habilidad. La llamamos una habilidad de enrutamiento porque la mayor parte es una sola tabla. Cada fila asigna un tipo de solicitud (una campaña, un cambio de estilo, una miniatura, una publicación, un paquete de YouTube, una película de lanzamiento, una animación corta) a la ruta y a la habilidad especializada que la gestionan. El router también decide si el trabajo necesita un lienzo visual compartido, y mantiene las ediciones pequeñas fuera del proceso completo.

Para una película como la de arriba, el router elige la launch-film skill diseñada para dirigir una gran producción audiovisual. Cada una de nuestras 48 skills, cerca de 1,000 archivos en total, está acotada a un trabajo en lugar de a un tema, por lo que su descripción se lee como una regla de enrutamiento, incluido cuándo no usarla.

Las skills se componen entre sí en lugar de repetirse. launch-film dirige y motion-studio crea la imagen y el sonido, de modo que la artesanía de la animación se escribe una sola vez. launch-film también incluye briefs de roles para los subagentes que iniciará, y un estudio de caso de una película real de lanzamiento de 88 segundos que reconstruimos plano a plano en código. Ese estudio de caso es donde el agente aprendió a dividir una película entre subagentes. Corta en cambios de escena duros, mantiene un movimiento continuo de cámara con un solo subagente y congela el código compartido antes de que alguien trabaje en paralelo.

Las descripciones importan tanto para las herramientas como para las skills. Para reducir el uso de contexto, pusimos las herramientas MCP detrás de una búsqueda integrada. El agente comienza solo con nuestras propias herramientas y carga esquemas de herramientas adicionales según los necesita, mediante búsquedas por palabras clave en nombres y descripciones de herramientas.

Wiki

Las skills explican cómo hacer un trabajo, mientras que la wiki proporciona el contexto y el material de referencia necesarios para hacerlo bien. Cubre todo, desde los tokens de marca, el lenguaje gráfico y la voz hasta plataformas, campañas e información de producto. Una wiki de motion dedicada cubre dirección, artesanía, sonido y revisión, junto con desgloses de 70 películas de referencia.

En lugar de duplicar esta información en varias skills, enlazamos directamente a la wiki. Esto mantiene el conocimiento compartido en un solo lugar y facilita las actualizaciones. Cuando algo como una regla de tipografía cambia, solo necesitamos actualizarlo una vez, y cada skill puede hacer referencia a la última versión.

Saber cómo trabajamos no necesariamente hace que el motion design sea más barato. Una decisión creativa equivocada aún puede costar horas de renderizado.

Diseño basado en especificaciones

El motion es especialmente costoso cuando se equivoca, tanto en tiempo de renderizado como en tokens. Un fotograma de storyboard tarda unos 50 milisegundos en renderizarse, frente a entre 8 y 40 segundos para un solo segundo de película terminada. Con subagentes escribiendo, renderizando y revisando cada acto, esos costos se acumulan rápidamente. Así que el agente desarrolla las ideas primero en el storyboard, donde puede explorar diferentes direcciones de manera barata, antes de pasar a la producción completa una vez aprobada una dirección.

Para respaldar esa exploración, le dimos al agente una biblioteca de películas de referencia de las que inspirarse, como un diseñador que trabaja a partir de un mood board. Cuando no encuentra el look adecuado, usa un modelo de imágenes para generar nuevas referencias, comenzando con borradores rápidos antes de refinar las opciones más prometedoras. Estas imágenes ayudan a establecer la dirección visual, mientras que el storyboard y la película final se siguen construyendo en código con tipografía real y recursos de marca.

Una vez que elegimos una dirección, el storyboard aprobado se convierte en la especificación contra la que se construye el resto de la película. Entonces el proyecto pasa por tres etapas:

1. Un storyboard, para acordar la idea visual, el texto y los planos.
2. Un animatic, un montaje aproximado sincronizado con el audio, para verificar el ritmo que las imágenes fijas no pueden mostrar.
3. Producción, donde los subagentes construyen, verifican y renderizan los planos aprobados.

Primero describimos este orden en las instrucciones de la skill, y el agente a veces se saltaba una revisión para ahorrar tiempo. Ahora el pipeline lo impone en código, de modo que el ensamblaje espera hasta que cada acto pasa la revisión, mientras que las instrucciones siguen guiando las decisiones creativas. El orden que siempre debe cumplirse vive en el código, y el criterio permanece en el prompt.

Señala, no escribas prompts

Elegir entre esas direcciones es una decisión de equipo. Slack funciona bien para pedir trabajo y recibirlo, pero un hilo es texto lineal y un storyboard es espacial, por lo que los comentarios acaban describiendo dónde está algo en lugar de señalarlo, y cada cambio, incluso una corrección de una sola palabra, tiene que volver a pasar por el agente como un nuevo prompt.

Paper resolvió esto para nosotros. Es un lienzo de diseño pensado para trabajar con agentes, con un servidor MCP que le da al agente control directo sobre el archivo. Las personas pueden trabajar en ese mismo archivo, comparando direcciones lado a lado, dejando comentarios en fotogramas específicos o haciendo ediciones por sí mismas. Como el lienzo es compartido, el agente puede volver al archivo y usar esos comentarios y ediciones para guiar su siguiente iteración.

El desafío era que las herramientas de agente de Paper solo se ejecutan dentro de su aplicación de escritorio, mientras que nuestro agente opera en un sandbox en la nube. Para salvar esa distancia, ejecutamos Paper Desktop sin interfaz gráfica en un trabajador Linux siempre activo, usando una pantalla virtual y un puente autenticado para conectar ambos. Una sola configuración da servicio a todo el equipo.

Incluso después de la aprobación, convertir un storyboard en una película terminada puede llevar horas. Para ese momento, el trabajo se parece a un pequeño proyecto, con múltiples piezas construyéndose en paralelo que necesitan encajar juntas. Coordinar todo esto es más de lo que puede manejar un solo turno de agente.

El agente como jefe de personal

Considera la película del loro de antes, a mitad de la producción en Slack. Una persona comparte una referencia, otra sugiere una apertura diferente y una tercera deja un comentario sobre el fotograma cuatro, todo mientras el agente sigue construyendo. Es como una lluvia de ideas donde la persona que toma notas también es responsable de hacer la película. Los subagentes síncronos no funcionan bien aquí porque el agente principal tiene que esperar a que terminen, sin forma de que las personas interactúen con él mientras tanto.

Para resolver esto, hicimos que los subagentes fueran asíncronos y cambiamos el rol del agente principal de implementador a jefe de personal. Divide los proyectos complejos en tareas más pequeñas y aisladas, las asigna a subagentes y ejecuta el trabajo en paralelo. Mientras tanto, mantiene informado al equipo a medida que cambian las cosas, para que las personas puedan seguir dando retroalimentación y dirigiendo el proyecto.

Para cada tarea, el agente principal crea un perfil de subagente con un encargo claro que cubre su rol, el contexto relevante, la propiedad de los archivos y cómo validar el trabajo. También selecciona el modelo y el nivel de esfuerzo según la complejidad de la tarea.

También añadimos un pequeño conjunto de herramientas para que el agente principal coordine el trabajo:

• start_task entrega una parte a un subagente en segundo plano
• check_tasks muestra qué se está ejecutando y lee los informes terminados
• cancel_task y resume_task detiene el trabajo que ya no se ajusta al encargo, o lo retoma donde lo dejó
• report_progress permite que un subagente envíe actualizaciones a mitad del trabajo
• schedule_wakeup proporciona al agente principal un temporizador para activar otra ejecución y continuar el trabajo

Por debajo, cada subagente es la herramienta ordinaria Deep Agents task que se ejecuta como tarea en segundo plano. Cuando termina, nuestro código pone en cola una nueva ejecución del agente principal con el resultado. Las personas también pueden dirigir al agente principal durante la ejecución, ya que un mensaje que llega mientras trabaja se inserta antes de su siguiente llamada al modelo. Los subagentes se coordinan a través de la carpeta del proyecto, cada uno escribiendo solo los archivos que posee y guardando su progreso en disco.

Con el trabajo ejecutándose en segundo plano, el hilo tiene que mostrar lo que está sucediendo. El agente principal lo mantiene actualizado con un plan y un tiempo estimado, una línea de estado en vivo con los subagentes en ejecución, el progreso del render y el gasto, una confirmación de cada edición y una tarjeta de aprobación antes de que algo salga a la luz pública.

Una de las pruebas más claras de este enfoque vino de un trabajo nocturno para rediseñar la apariencia de una presentación de 52 diapositivas. El agente comenzó creando tres diapositivas de muestra y revisando su propio trabajo antes de avanzar por el resto de la presentación en lotes numerados para su aprobación. También añadió dos diapositivas nuevas por el camino. Durante la noche, el agente principal se ejecutó durante aproximadamente una hora mientras sus subagentes trabajaron colectivamente más de seis horas, todo sin bloquear la conversación.

El arnés de auto-mejora

Un diseñador que ha trabajado con un equipo durante meses aprende sus preferencias y no necesita escuchar la misma retroalimentación dos veces. Sin memoria, el agente comenzaría desde cero con cada hilo nuevo. Para evitar esto, construimos dos bucles de aprendizaje. El bucle rápido captura la retroalimentación a medida que las personas la dan, mientras que el bucle lento aprende de los proyectos completados en segundo plano.

El bucle rápido: Cuando alguien comparte una regla o preferencia, el agente la guarda en el mismo turno. Managed Deep Agents almacena la memoria como archivos planos en dos capas, una compartida por todo el equipo y otra específica para cada persona.

Las preferencias personales se trasladan entre hilos, pero los estándares compartidos tienen precedencia, y cualquier cosa creada para un canal de empresa sigue la voz de la empresa. Cada capa tiene un archivo AGENTS.md que se carga con cada llamada al modelo. Ahora limitamos estos archivos a un índice de 200 líneas después de que una versión temprana creciera hasta 500K tokens.

El bucle lento: Después de cada trabajo, nuestra herramienta learn_from_job lanza un subagente ligero que captura hasta cinco lecciones respaldadas por evidencia y las asocia con la habilidad utilizada. Los trabajos futuros leen y califican esas lecciones, y una vez a la semana, un agente en segundo plano incorpora las que resultan útiles a las habilidades y la wiki.

Qué viene después

¿Recuerdas esas primeras revisiones? La mayor mejora vino de capturar el criterio de nuestros diseñadores en un entorno compartido del que el agente pudiera aprender, en lugar de dejarlo disperso en hilos de revisión. En el proceso, hicimos el trabajo de diseño accesible para más personas.

A continuación, queremos que el agente gestione todo el ciclo de vida de la campaña, y una parte de eso ya está funcionando. Publica las publicaciones sociales de la empresa a través de Buffer una vez que un aprobador autorizado da el visto bueno, redacta publicaciones para que los empleados las compartan desde sus propias cuentas y ejecuta rutinas programadas, incluida una revisión diaria que sugiere publicaciones que vale la pena citar.

Nuestro objetivo es llevar esto más lejos, de modo que una única dirección creativa aprobada pueda sustentar toda una campaña desde un solo hilo. El agente escribiría el encargo, crearía los activos para cada canal, programaría las publicaciones, ayudaría al equipo a amplificarlas y usaría los datos de rendimiento para informar la siguiente campaña. Las personas seguirían revisando y aprobando todo antes de que salga a la luz pública.

Construye tu propio agente de diseño: El repositorio de código abierto tiene el arnés de esta publicación: la computadora sandbox, las habilidades, la wiki y la memoria, los subagentes asíncronos y la experiencia de usuario de Slack. Hazle un fork, añade los tokens de tu marca, tus fuentes y habilidades, y despliégalo en el Slack de tu equipo con Agentes profundos gestionados.

Entonces únete a nosotros en GTM Engineering Live el 28 de octubre. Analizaremos a fondo el harness y la UX, y mostraremos el trabajo que no cupo en esta publicación.