Un comercial de Anthropic gestiona seis agentes en vez de uno. Comparten memoria, no sus claves

Cada mañana, antes de que un representante de desarrollo de negocio del equipo de Anthropic en Japón abra su portátil, un agente ya ha clasificado las oportunidades entrantes del día entre los representantes y ha publicado un resumen en Slack. Otro ha cualificado las que le asignaron, actualizó Salesforce y redactó los primeros correos electrónicos en japonés o inglés. Lee los borradores, los edita y pulsa enviar.

Shahboz Ibragimov describió la configuración el 16 de octubre en un artículo en primera persona en el sitio de Anthropic. Es el flujo de trabajo de una persona dentro de la empresa que vende el modelo, construido sobre Claude Managed Agents, que está en beta. No es un benchmark. Su valor está en las decisiones de diseño, que son las mismas que enfrentará un equipo empresarial cuando su primer agente se convierta en varios.

Un trabajo por agente

La flota, que él llama Nakama, tiene cinco agentes de trabajo y un coordinador, cada uno con un trabajo y un modelo elegido para ese trabajo:

Seis agentes, seis trabajos, una persona que envía

	Trabajo	Modelo	Rol de la persona
Furiwake	Enruta las oportunidades entrantes entre los representantes y publica un informe	Sonnet	Lee el informe
Sabaki	Cualifica oportunidades, actualiza Salesforce y redacta los primeros correos	Opus	Revisa y envía cada correo
Henji	Revisa la bandeja de entrada cada hora y redacta respuestas	Sonnet, con Opus como asesor	Revisa y envía cada respuesta
Shoudan	Envía a Salesforce las actualizaciones de las interacciones con clientes	Sonnet	Hace verificaciones puntuales del CRM
Nokori	Resume las reuniones del día y redacta los seguimientos	Opus	Revisa y envía
Coordinador	Actualiza las instrucciones de los otros agentes y el conocimiento compartido	Opus	Único autor de las solicitudes de cambio

Los agentes de alcance limitado son más fáciles de entender y controlar que un único asistente que lo hace todo. Cada uno tiene un conjunto breve de instrucciones, un conjunto pequeño de herramientas y un fallo fácil de reconocer: una oportunidad mal enrutada, un campo del CRM incorrecto, un borrador torpe. Y el modelo puede ajustarse al trabajo: el enrutamiento y las actualizaciones de registros en el modelo más barato, la redacción que exige más criterio en el más grande.

Memoria compartida, claves separadas

Todos los agentes leen y escriben un único almacén de memoria. Así aprende la flota: los agentes comparan sus borradores con los correos que él envió realmente y guardan las diferencias como notas de redacción, y guardan hechos encontrados durante la investigación para que los usen los demás. Según sus palabras, hicieron falta “unos cientos de rondas baratas” de redacción y corrección antes de que los borradores se ajustaran a su voz.

Las credenciales se gestionan al revés. Los tokens OAuth, las claves de API y los tokens de acceso viven en bóvedas gestionadas, y el despliegue de cada agente se conecta solo a las bóvedas que exige su trabajo. Los agentes nunca ven las credenciales, y el acceso se puede revocar en un paso. Un agente cuyo trabajo es redactar respuestas no tiene ninguna razón para tener acceso de escritura al CRM, y con este diseño no lo tendría.

Esa separación, conocimiento compartido con autoridad separada, es la idea más reutilizable del artículo. Es el principio de mantener las credenciales de ejecución fuera de la capa de razonamiento, aplicado a un equipo comercial. También deja al descubierto la siguiente pregunta. Una memoria compartida son datos compartidos: si un agente guarda un hecho incorrecto sobre un cliente, todos los agentes lo heredan, y si los datos de un cliente acaban en el almacén, permanecen allí bajo la retención que tenga el almacén. Sostuvimos que la memoria de los agentes es almacenamiento de datos empresarial; una flota con una sola memoria lo hace concreto. En una empresa regulada, el almacén de memoria necesita un responsable, un hábito de revisión y una regla de eliminación, no solo la bóveda de credenciales.

Un agente que edita a los otros agentes

El coordinador es la parte que hay que estudiar antes de copiar. Solo el autor puede publicar solicitudes de cambio en un canal de Slack dedicado. El coordinador lee ese canal aproximadamente cada 15 minutos y actualiza las instrucciones de los otros agentes y la base de conocimiento compartida. Cada cambio de instrucciones se guarda como una versión numerada.

Eso es un pequeño sistema de gestión de cambios: un solicitante autorizado, un implementador automático y un historial versionado. A escala de equipo, necesita un elemento más: un paso de revisión entre la edición del coordinador y la entrada en vigor del cambio, por la misma razón por la que los cambios escritos por agentes pasan por la gestión del cambio en otros contextos. Un coordinador que malinterpreta una solicitud puede reescribir en silencio el comportamiento de todos los agentes.

Del portátil al despliegue gestionado

La ruta de migración es una plantilla útil. Prototipó con habilidades locales y tareas programadas, y luego migró cuando la configuración se volvió difícil de seguir: cada habilidad se convirtió en un prompt de sistema, cada tarea programada en una programación de despliegue, la carpeta compartida en un almacén de memoria. Ahora los agentes se ejecutan tanto si su portátil está abierto como si no, con visibilidad central de lo que se ejecutó.

Según cuenta, la flota ahorra unas 60 horas de trabajo a la semana, según su propio recuento de registros, en comparación con “un par de horas cada mañana” de enrutamiento y cualificación antes. Tómelo como la medición de una persona. El resultado más duradero es la forma del sistema: agentes de alcance limitado, una persona que envía cada mensaje dirigido al cliente, conocimiento compartido a propósito y autoridad acotada por trabajo.