Cómo un BDR de Anthropic en Japón gestiona su día con Agentes gestionados de Claude

Como representante de desarrollo empresarial del equipo de Anthropic en Japón, mi trabajo es mostrar a las empresas japonesas cómo Claude puede simplificar y automatizar sus flujos de trabajo, pero hasta principios de este año, la mayoría de los míos seguían siendo manuales. Pasaba un par de horas cada mañana derivando y cualificando clientes potenciales, y luego escribía correos electrónicos en japonés o inglés. En el tiempo que me quedaba, actualizaba nuestro CRM, a menudo con un día o más de retraso. Ahora, mis agentes preparan la mayor parte de ese trabajo antes de que empiece mi día, y yo lo reviso.

El primer flujo de trabajo basado en Claude que creé era bastante rudimentario, pero cumplió su cometido. Entregaba a Claude una parte de mi trabajo cada vez, corregía sus errores y guardaba esas correcciones. Con el tiempo, eso se convirtió en un puñado de agentes, cada uno de los cuales cubría una rutina diferente.

La voz se corrió rápidamente y mis compañeros de equipo empezaron a pedirme mis prompts y skills para poder crear los suyos propios. Todo lo que podía enviarles era un archivo zip con mis skills y algunos archivos de Markdown de la base de conocimiento, que debían cargar en Claude y, luego, responder a una serie de preguntas de configuración para que funcionara. Mi propia configuración también era cada vez más difícil de controlar. Cada agente era una skill, una tarea programada y una carpeta compartida, y los modificaba mediante peticiones a Claude en cualquier chat que tuviera abierto, de modo que la misma skill se editaba desde muchas conversaciones diferentes.

Quería definir cada agente una vez, en un solo lugar, y poder ver cada cambio que le hubiera hecho. Por eso, decidí probar Agentes gestionados de Claude (opens in new tab) (beta), la infraestructura de agentes gestionados que tenemos en Claude Platform.

Al principio dudé en probarlo. La documentación habla de programaciones, herramientas y almacenes de credenciales, y yo soy representante de ventas, así que supuse que Agentes gestionados era para desarrolladores que pudieran crear y mantener la infraestructura necesaria. De todos modos, lo probé porque mis agentes ya existían y solo tenía que migrarlos.

Resultó que no necesitaba ser desarrollador. Describí el trabajo de cada agente en lenguaje sencillo, Claude escribió algunos scripts de configuración breves y los ejecuté desde el terminal de mi ordenador portátil. (Si empiezas desde cero, la consola también ofrece una guía de inicio rápido con plantillas de agentes listas para usar). Desde entonces, no he tenido que ocuparme de ninguna infraestructura.

En esta publicación, explicaré cómo diseñé y creé un prototipo de la flota de agentes, por qué la pasé a Agentes gestionados, cómo Claude Tag se encarga de lo que queda fuera de la rutina, cómo cambió todo esto mi semana y qué les diría a los vendedores que quieran crear sus propios agentes para automatizar los flujos de trabajo manuales y repetitivos.

Diseñar mi flota de agentes

Dividí mi flujo de trabajo entre varios agentes y asigné a cada agente una tarea clara. El que tengan una sola responsabilidad hace que cada uno sea más fácil de entender y de seguir, especialmente cuando hay algún fallo. También di a cada agente un nombre japonés, porque trabajan principalmente en japonés. Su nombre de grupo es Nakama, "la tripulación" o, más literalmente, los compañeros con los que trabajas:

• Furiwake ("clasificación") se activa primero: lee la cola diaria de entrada y asigna cada cliente potencial al representante adecuado del equipo, ajustando el número de clientes potenciales y la prioridad de cada uno, y verificando quién está presente ese día, para que cada uno de ellos tenga un responsable antes de que cualquiera de nosotros empiece su jornada. Al final de cada ejecución, publica un informe en un canal de Slack específico (todos los contactos recibidos y todos los contactos asignados) para que pueda hacer un seguimiento del traspaso.
• Sabaki ("gestión") prioriza los clientes potenciales que se me asignan: cualifica cada uno de ellos, lo clasifica según criterios preestablecidos, da el siguiente paso definido para esa categoría (redactar una respuesta que los remita al autoservicio o elaborar un primer correo electrónico personalizado), actualiza su registro en Salesforce y redacta el correo electrónico de primer contacto. Obtiene el contenido del borrador de la base de conocimiento compartida de los Nakama, un almacén de memoria (opens in new tab) en el que todos los agentes leen y escriben (más información al respecto a continuación).
• Henji ("respuesta") revisa mi bandeja de entrada cada hora en busca de correos electrónicos de clientes que necesiten alguna respuesta y prepara un borrador en japonés o inglés, según el hilo, utilizando la misma base de conocimiento que Sabaki. Puedo revisar, editar y enviar el borrador.
• Shoudan ("oportunidad") lee las interacciones recientes con los clientes y transmite las actualizaciones a Salesforce, por lo que los registros de oportunidades se mantienen actualizados sin necesidad de introducir datos manualmente.
• Nokori ("lo que queda") se ejecuta al final del día: analiza mi calendario, lee las transcripciones de las reuniones adjuntas, resume cada reunión y redacta los informes de seguimiento, siempre a partir de la misma base de conocimiento.

Cada agente se ejecuta según un horario. Un sexto agente, el coordinador de Nakama, es el responsable de las operaciones de la flota. Actualiza las instrucciones de los agentes y la base de conocimiento compartida entre cada ejecución. Cuando quiero cambiar la forma en que funciona un agente, escribo lo que quiero en lenguaje sencillo en el canal de Slack de Nakama. Solo yo puedo publicar solicitudes de cambio en las instrucciones de los agentes y en los prompts del sistema. El coordinador comprueba ese canal más o menos cada 15 minutos, recibe la solicitud y realiza la actualización.

Crear prototipos de la flota en Claude

No necesitas Agentes gestionados para empezar. Primero creé un prototipo de toda la flota en Claude con los siguientes elementos:

• Una skill por agente: las instrucciones para un trabajo.
• Una tarea programada para cada skill, para no tener que ejecutarla manualmente.
• Una carpeta compartida en mi ordenador portátil, que sirve como base de conocimiento en la que cada skill escribe lo que ha aprendido: la diferencia entre lo que redactó y lo que envié, además de cualquier cosa nueva que vaya descubriendo a lo largo del camino.

En Agentes gestionados, la skill se convirtió en el prompt del sistema del agente, la tarea programada se convirtió en un cronograma de la implementación del agente (opens in new tab) y la carpeta compartida se convirtió en un almacén de memoria. Todavía pido los cambios en lenguaje sencillo, pero ahora lo hago todo en un solo canal de Slack, y cada cambio en las instrucciones de un agente se guarda como una nueva versión, por lo que cada agente mantiene un historial con números de sus instrucciones. Te sugeriría empezar por Claude y pasar a Agentes gestionados cuando tengas más agentes de lo que puedas gestionar cómodamente.

Ejecutar la flota de agentes con Agentes gestionados de Claude

Tres cosas que aprendí sobre Agentes gestionados y que más me han servido para mi flujo de trabajo:

Los agentes pueden ejecutarse en segundo plano

Los agentes se ejecutan según su programación, independientemente de que mi ordenador portátil esté abierto o no, incluso cuando está sin conexión. La programación forma parte de la implementación de cada agente. También podía programar skills en Claude, pero cada una de esas programaciones sería una tarea configurada en mi propia aplicación. En Agentes gestionados, configuro la cadencia y la zona horaria en la consola, junto a las instrucciones y herramientas del agente implementado, y no tengo que mantener trabajos de cron adicionales. Si una ejecución sale mal, puedo abrirla en la consola y ver cada uno de los pasos que el agente ejecutó. Y mientras pruebo un cambio en un agente, las ejecuciones programadas siguen utilizando la versión implementada, por lo que una edición a medio terminar no acaba en la ejecución de mañana.

El Nakama comparte una sola memoria y aprende de mis ediciones

Cada agente lee y escribe en el mismo almacén de memoria (opens in new tab), por lo que cualquier agente puede usar lo que han aprendido los demás. Los agentes comparan los borradores que escribieron con los correos electrónicos que envié y guardan cada diferencia como una nota sobre cómo lo escribiría yo. También conservan la información nueva que encuentren en nuestra documentación interna y en nuestros sitios web oficiales mientras investigan una pregunta. Corrijo una frase una vez en los borradores de Henji, y Sabaki y Nokori no vuelven a cometer el mismo error.

Las credenciales se almacenan en una bóveda gestionada con permisos definidos

Mis agentes tienen acceso a mi correo electrónico y a nuestros registros de Salesforce, pero como se trata de conversaciones con clientes y registros de la empresa, quería tener ese acceso bajo control. Las credenciales se almacenan en bóvedas gestionadas (opens in new tab), que protegen las credenciales que los agentes usan para iniciar sesión en servicios externos, como tokens de acceso y actualización de OAuth, claves de API y tokens de acceso personal. Cada agente utiliza solo las bóvedas que necesita para su tarea, nunca ve las credenciales y puedo revocar el acceso con un solo paso.

Delegar los siguientes pasos a Claude Tag

Para la mayor parte de lo que produce el Nakama, solo necesito leer un borrador en mi bandeja de entrada y enviarlo, o echar un vistazo a un registro actualizado de Salesforce. Pero, para algunos elementos, necesito un paso de seguimiento, como determinar una ruta de actualización o una vía de compra, o derivar un problema a otro equipo.

En esos casos, los agentes no me esperan. Entregan el elemento a Claude Tag (opens in new tab) (en versión beta). Claude Tag es Claude configurado como miembro de nuestro espacio de trabajo de Slack: cualquiera que esté en un canal al que Claude se haya unido, ya sea una persona o uno de mis agentes, puede etiquetar a @Claude con una solicitud, y Claude la asume y trabaja en ella en el hilo. Una vez que está configurado en tu espacio de trabajo, no tienes que aprender nada nuevo. Mencionas a Claude como harías con un compañero de trabajo.

En mi configuración, funciona de la siguiente manera. Un agente publica la tarea pendiente en el canal de Slack de Nakama y etiqueta a Claude. Claude lee el hilo, comprueba nuestras reglas y las condiciones aplicables, expone las opciones y redacta lo necesario. Me etiqueta cuando un paso necesita mi revisión o mi aprobación. Cuando un cliente u otro equipo tiene que contestar antes, Claude crea un recordatorio para volver a revisarlo en un fecha concreta. En el siguiente hilo, Claude programó un recordatorio para el martes para comprobar si el cliente había respondido y si el equipo de ofertas había respondido al ticket. Cuando llega el momento del recordatorio, Claude revisa ambos aspectos y publica en el mismo hilo el estado de la situación. Si alguien necesita un empujón, redacta el mensaje y me etiqueta para que lo envíe.

Claude también publica cada mañana un resumen de las actualizaciones de productos y precios. El coordinador de Nakama recibe ese resumen y escribe los cambios necesarios en la base de conocimiento compartida.

Qué cambió en mi semana

Ahora que Claude prepara las respuestas a los mensajes entrantes y mantiene actualizados los registros del CRM (en su mayor parte) sin mi intervención manual, mi función es revisar todo lo que necesita una decisión humana. Un reglamento escrito define el ámbito de cada agente, y asuntos como las preguntas sobre precios, las cuentas confidenciales o las solicitudes ambiguas que se me derivan. Cada borrador de correo electrónico de Henji, Sabaki o Nokori llega con un breve resumen al principio de lo que está sucediendo, así que no tengo que repasar todo el hilo para comprender el contexto: leo el resumen, confirmo, hago revisiones y envío.

Si analizo el registro semanal de lo que hace el Nakama y sumo el tiempo que habría tardado en hacer manualmente cada tarea, veo que la flota me ahorra unas 60 horas de trabajo. Dedico el tiempo liberado al trabajo que los agentes (todavía) no pueden hacer de forma eficaz: conversaciones con clientes, estrategia de captación, proyectos con otros equipos y ayudar a los compañeros de equipo a crear sus propias flotas.

Diseñar agentes para que sean más eficientes

Los agentes programados se ejecutan todos los días, tanto si los superviso como si no, por lo que las ineficiencias pueden acumularse y afectar a los costes y la fiabilidad. Algunos de los errores más comunes son añadir más instrucciones en lugar de actualizarlas, dar a los agentes más contexto del que necesitan para sus tareas y ejecutar cada trabajo con el mayor nivel de esfuerzo en el modelo más grande.

Lo que mantiene la eficiencia de los agentes es en gran medida la forma en que diseñé la flota: cada agente tiene una única tarea, por lo que sus instrucciones se mantienen centradas en esa tarea; cada agente operativo se ejecuta en un horario, por lo que se activa, hace su parte y se detiene; y los agentes comparten una memoria, por lo que una corrección hecha una vez se reutiliza en todas las partes.

El otro factor importante es en qué modelo se ejecuta cada agente. Una vez que el trabajo de un agente está bien definido, es posible que no necesite nuestro modelo más potente. Furiwake y Shoudan siguen un conjunto de reglas escritas, por lo que se ejecutan en Sonnet, nuestro modelo más pequeño. Sabaki, Nokori y el coordinador se ejecutan en Opus, nuestro modelo más grande, porque su trabajo necesita más criterio. El coordinador es el que más lo necesita, ya que edita las instrucciones de los demás agentes y una modificación incorrecta afectaría a todos los agentes. Henji necesita tanto criterio como Sabaki, porque el correo electrónico de cada cliente es diferente, pero también se ejecuta con más frecuencia que cualquier otro agente, durante toda la jornada laboral. Ejecutarlo en Opus todas las veces sería la opción más cara, por lo que utilizo la estrategia de asesoramiento (opens in new tab) de Agentes gestionados: Henji funciona con Sonnet, y cuando llega a una decisión que no puede tomar por sí solo, pide asesoramiento a Opus. El asesor lee lo que Henji ha hecho hasta el momento y le devuelve un plan, una corrección o una indicación de detenerse; después, Henji finaliza el borrador para que yo lo revise. También establezco el nivel de esfuerzo de cada agente (cuánto tiempo piensa el modelo antes de responder) con independencia de su modelo, y solo lo aumento cuando el razonamiento es difícil, como ocurre con las respuestas de Henji.

Lo que aprendí

Tres consejos que daría a cualquiera que esté creando su propia flota.

1. No necesitas un prompt detallado para cada ocasión. Describe el trabajo una vez, deja que Claude redacte, corrige el borrador y deja que Claude conserve la corrección.
2. La base de conocimiento es más importante que el prompt. Cada corrección y cada interacción anterior se guardan en un lugar que todos los agentes pueden leer y en el que pueden escribir, por lo que Claude obtiene el contexto de ahí en lugar de un prompt más largo. Hicieron falta unos cuantos cientos de rondas baratas de redacción, corrección y guardado para que pareciera que los borradores los escribía yo.
3. Dale a Claude más margen, y antes. Al principio, seguía haciendo las tareas que suponía que requerían mi intervención: actualizar la base de conocimiento o editar manualmente las instrucciones de cada agente. Ambas funcionaron correctamente cuando dejé de encargarme de ellas. Ahora los agentes escriben ellos mismos lo que aprenden en la base de conocimiento, y el coordinador actualiza las instrucciones de los demás agentes cuando se lo pido en lenguaje sencillo. Había sido demasiado cauteloso con trabajo que podía confiar a los agentes.

Empezar con Agentes gestionados de Claude (opens in new tab)