Representante de vendas da Anthropic roda seis agentes em vez de um. Memória compartilhada, chaves separadas

Todas as manhãs, antes de um representante de desenvolvimento de negócios do time da Anthropic no Japão abrir o notebook, um agente já classificou os leads inbound do dia entre os representantes e publicou um resumo no Slack. Outro qualificou os que foram atribuídos a ele, atualizou o Salesforce e redigiu primeiros e-mails em japonês ou inglês. Ele lê os rascunhos, edita e clica em enviar.

Shahboz Ibragimov descreveu a configuração em 16 de outubro em um artigo em primeira pessoa no site da Anthropic. É o workflow de uma pessoa dentro da empresa que vende o modelo, construído sobre Claude Managed Agents, que está em beta. Não é um benchmark. O valor está nas decisões de design, que são as mesmas que um time enterprise vai enfrentar quando seu primeiro agente se tornar vários.

Uma função por agente

A frota, que ele chama de Nakama, tem cinco agentes de trabalho e um coordenador, cada um com uma função e um modelo escolhido para ela:

Seis agentes, seis funções, uma pessoa que envia

	Função	Modelo	O papel da pessoa
Furiwake	Roteia leads inbound entre os representantes, publica um relatório	Sonnet	Lê o relatório
Sabaki	Qualifica leads, atualiza o Salesforce, redige primeiros e-mails	Opus	Revisa e envia cada e-mail
Henji	Verifica a caixa de entrada a cada hora, redige respostas	Sonnet, com Opus como conselheiro	Revisa e envia cada resposta
Shoudan	Envia atualizações de interações com clientes para o Salesforce	Sonnet	Faz verificações pontuais no CRM
Nokori	Resume as reuniões do dia, redige follow-ups	Opus	Revisa e envia
Coordenador	Atualiza as instruções dos outros agentes e o conhecimento compartilhado	Opus	Único autor de solicitações de mudança

Agentes estreitos são mais fáceis de analisar do que um assistente que faz tudo. Cada um tem um conjunto curto de instruções, um pequeno conjunto de ferramentas e uma falha fácil de reconhecer: um lead mal roteado, um campo errado no CRM, um rascunho desajeitado. E o modelo pode combinar com a função: roteamento e atualizações de registros no modelo mais barato, redação que exige julgamento no maior.

Memória compartilhada, chaves separadas

Todos os agentes leem e escrevem em um único armazenamento de memória. É assim que a frota aprende: os agentes comparam seus rascunhos com os e-mails que ele realmente enviou e salvam as diferenças como notas de fraseado, e armazenam fatos encontrados durante a pesquisa para os outros usarem. Levou, nas palavras dele, “algumas centenas de rodadas baratas” de redação e correção até que os rascunhos correspondessem à voz dele.

As credenciais são tratadas ao contrário. Tokens OAuth, chaves de API e tokens de acesso ficam em cofres gerenciados, e o deploy de cada agente é conectado apenas aos cofres que a função dele exige. Os agentes nunca veem as credenciais, e o acesso pode ser revogado em uma etapa. Um agente cuja função é redigir respostas não tem motivo para ter acesso de escrita ao CRM e, neste design, não teria.

Essa separação, conhecimento compartilhado com autoridade separada, é a ideia mais reaproveitável do artigo. É o princípio por trás de manter credenciais de execução fora da camada de raciocínio, aplicado a uma mesa de vendas. Também expõe a próxima questão. Uma memória compartilhada é dado compartilhado: se um agente armazena um fato errado sobre um cliente, todos os agentes herdam esse fato, e se os detalhes de um cliente chegam ao armazenamento, eles persistem ali sob a retenção que o armazenamento tiver. Argumentamos que a memória de agente é armazenamento de dados enterprise; uma frota com uma memória torna isso concreto. Em uma empresa regulada, o armazenamento de memória precisa de um responsável, de um hábito de revisão e de uma regra de exclusão, não apenas do cofre de credenciais.

Um agente que edita os outros agentes

O coordenador é a parte a estudar antes de copiar. Só o autor pode publicar solicitações de mudança em um canal dedicado no Slack. O coordenador lê esse canal a cada 15 minutos, aproximadamente, e atualiza as instruções dos outros agentes e a base de conhecimento compartilhada. Cada mudança de instrução é salva como uma versão numerada.

Isso é um pequeno sistema de gestão de mudanças: um solicitante autorizado, um implementador automatizado e histórico versionado. Na escala de um time, precisa de mais um elemento, uma etapa de revisão entre a edição do coordenador e a mudança entrar em vigor, pelo mesmo motivo que mudanças feitas por agentes passam por gestão de mudanças em outros lugares. Um coordenador que interpreta mal uma solicitação pode reescrever silenciosamente como cada agente se comporta.

Do notebook ao deploy gerenciado

O caminho de migração é um modelo útil. Ele fez o protótipo com skills locais e tarefas agendadas, depois migrou quando a configuração ficou difícil de acompanhar: cada skill virou um prompt de sistema, cada tarefa agendada um cronograma de deploy, a pasta compartilhada um armazenamento de memória. Os agentes agora rodam esteja o notebook dele aberto ou não, com visibilidade central do que rodou.

Ele relata que a frota economiza cerca de 60 horas de trabalho por semana, pela contagem dos próprios logs, em comparação com “umas duas horas toda manhã” de roteamento e qualificação antes. Trate como a medição de uma pessoa. O resultado mais duradouro é o formato do sistema: agentes estreitos, uma pessoa que envia cada mensagem voltada ao cliente, conhecimento compartilhado de propósito e autoridade delimitada por função.