An Anthropic sales rep runs six agents instead of one. They share a memory, not their keys
An Anthropic business development rep in Japan described his fleet of Claude agents for lead routing, qualification, email and CRM. The design choices transfer better than the hours.
Listen to this article · 5 min
AI-generated narration of the full article.
Every morning, before a business development representative in Anthropic’s Japan team opens his laptop, one agent has already sorted the day’s inbound leads among the reps and posted a summary to Slack. Another has qualified the ones assigned to him, updated Salesforce and drafted first emails in Japanese or English. He reads the drafts, edits them and presses send.
Shahboz Ibragimov described the setup on October 16 in a first-person article on Anthropic’s site. It is one person’s workflow inside the company that sells the model, built on Claude Managed Agents, which is in beta. It is not a benchmark. Its value is in the design decisions, which are the same ones an enterprise team will face when its first agent becomes several.
One job per agent
The fleet, which he calls the Nakama, has five working agents and a coordinator, each with one job and a model chosen for it:
| Job | Model | The person's role | |
|---|---|---|---|
| Furiwake | Routes inbound leads among reps, posts a report | Sonnet | Reads the report |
| Sabaki | Qualifies leads, updates Salesforce, drafts first emails | Opus | Reviews and sends every email |
| Henji | Checks the inbox hourly, drafts replies | Sonnet, with Opus as advisor | Reviews and sends every reply |
| Shoudan | Pushes customer interaction updates to Salesforce | Sonnet | Spot checks the CRM |
| Nokori | Summarizes the day's meetings, drafts follow-ups | Opus | Reviews and sends |
| Coordinator | Updates the other agents' instructions and shared knowledge | Opus | Sole author of change requests |
Narrow agents are easier to reason about than one assistant that does everything. Each has a short instruction set, a small set of tools and a failure that is easy to recognize: a mis-routed lead, a wrong CRM field, a clumsy draft. And the model can match the job: routing and record updates on the cheaper model, judgment-heavy drafting on the larger one.
Shared memory, separate keys
All agents read and write one memory store. That is how the fleet learns: agents compare their drafts with the emails he actually sent and save the differences as phrasing notes, and they store facts found during research for the others to use. It took, in his words, “a few hundred cheap rounds” of drafting and correction before the drafts matched his voice.
Credentials are handled the opposite way. OAuth tokens, API keys and access tokens live in managed vaults, and each agent’s deployment is attached only to the vaults its job requires. The agents never see the credentials, and access can be revoked in one step. An agent whose job is drafting replies has no reason to hold write access to the CRM, and under this design it would not.
That split, shared knowledge with separate authority, is the most reusable idea in the article. It is the principle behind keeping execution credentials out of the reasoning layer, applied to a sales desk. It also exposes the next question. A shared memory is shared data: if one agent stores a wrong fact about a customer, every agent inherits it, and if a customer’s details land in the store, they persist there under whatever retention the store has. We argued that agent memory is enterprise data storage; a fleet with one memory makes that concrete. In a regulated company, the memory store needs an owner, a review habit and a deletion rule, not only the credential vault.
An agent that edits the other agents
The coordinator is the part to study before copying. Only the author can post change requests in a dedicated Slack channel. The coordinator reads that channel about every 15 minutes and updates the other agents’ instructions and the shared knowledge base. Each instruction change is saved as a numbered version.
That is a small change management system: one authorized requester, an automated implementer and versioned history. At team scale, it needs one more element, a review step between the coordinator’s edit and the change taking effect, for the same reason agent-authored changes go through change management elsewhere. A coordinator that misreads one request can quietly rewrite how every agent behaves.
From laptop to managed deployment
The migration path is a useful template. He prototyped with local skills and scheduled tasks, then moved when the setup became hard to track: each skill became a system prompt, each scheduled task a deployment schedule, the shared folder a memory store. The agents now run whether his laptop is open or not, with central visibility into what ran.
He reports the fleet saves about 60 hours of work a week, by his own log count, compared with “a couple of hours each morning” of routing and qualification before. Treat it as one person’s measurement. The more durable result is the shape of the system: narrow agents, a person who sends every customer-facing message, knowledge shared on purpose and authority scoped per job.