Context Design for a Claude Cowork Sales Agent

The most expensive mistake on a large sales book is not a bad prompt — it is a bloated context. When engineers first wire Claude Cowork to a 4,000-account CRM, the instinct is to give the model everything: full account history, every prior email, the whole playbook, all the skills. It feels safe. It is the opposite of safe. A context stuffed with marginally relevant material distracts the model, raises cost, increases latency, and reliably degrades the quality of judgment on the one account that actually matters right now. This post is about the discipline of deciding what goes in and what stays out.

Context engineering is the practice of deliberately curating the minimal, highest-signal set of information an agent needs for a task while excluding everything else, so the model's limited attention stays on what matters. On a sales book, this is the highest-leverage skill you can develop, because it governs every per-account decision the system makes thousands of times a day.

Why more context makes a sales agent worse

It is counterintuitive that a large context window can hurt, given how much Claude can hold. But attention is finite even when the window is large. Bury the one fact that matters — "this prospect replied yesterday asking for pricing" — under forty stale activity records and the model is far more likely to miss it or weight it wrong. On a single account you might not notice. Across a 4,000-account book, that dilution becomes a steady stream of slightly-off recommendations: cold messages to warm leads, ignored buying signals, generic drafts.

There is also a cost dimension. Every token of context is paid for on every sub-agent invocation, and you are invoking sub-agents across hundreds of accounts daily. A context that is twice as large as it needs to be roughly doubles your bill and your latency for no quality gain — usually a quality loss. Treating context as a scarce budget rather than free space is both a quality decision and an economic one.

What to put in: the four things a sub-agent needs

For a per-account sub-agent, four things earn their place. First, the fresh account snapshot: current stage, owner, and the most recent activity — fetched at start time, not handed down stale. Second, the recent signal: the last few meaningful events, especially anything inbound, trimmed to what changes the decision. Third, the one matching skill: the single set of instructions for the task at hand, not the whole skill library. Fourth, the tool schemas the task could plausibly need.

flowchart TD
  A["Sub-agent starts on one account"] --> B["Fetch fresh snapshot"]
  B --> C["Trim activity to recent & relevant"]
  C --> D["Select the one matching skill"]
  D --> E["Attach only needed tool schemas"]
  E --> F{"Anything else proposed?"}
  F -->|Marginal| G["Exclude it"]
  F -->|Decision-changing| H["Include compact summary"]
  G --> I["Run with lean context"]
  H --> I

The diagram captures the assembly as a filter, not a faucet. Each candidate piece of context faces one test: does this change the recommendation for this account? If it merely could be relevant, it stays out. The default is exclusion, and inclusion has to be earned. A small context-assembly function that runs this filter at the start of every sub-agent is one of the most valuable pieces of code in the whole system.

What to leave out, and why it hurts to include it

Leave out the other 3,999 accounts entirely — a per-account sub-agent has no business seeing them, and including them invites cross-contamination where the model references the wrong company. Leave out the full historical activity log; the last several relevant events carry the signal, and the ancient ones are noise that pushes the model toward generic, history-soaked messaging. Leave out skills that don't match the task; a drafting sub-agent does not need the hygiene-check instructions cluttering its attention.

Also leave out raw, unsummarized blobs. If an account has a long notes field or a sprawling email thread, summarize it to the decision-relevant essence before it enters context rather than dumping it whole. The summary is cheaper, sharper, and less distracting. The general principle: anything that does not change what the agent should do for this account is a liability in context, not an asset, no matter how true or interesting it is.

Compaction: keeping long-running work lean

Some tasks span many tool calls — researching an account, then drafting, then refining. Over a long sub-agent run, the context naturally accumulates tool outputs and intermediate reasoning. Without management it bloats toward the same problem. The pattern is compaction: periodically summarize the working context down to its decision-relevant state and continue from the summary. The agent keeps the conclusions it has reached and the facts it has verified, and sheds the raw intermediate chatter.

On a sales book this matters most for the orchestrator, which lives across the whole run. It should never carry every sub-agent's full output forward; it should keep a compact ledger — account ID, decision, status — and discard the prose. Compaction is what lets the system process a large working set in one run without the orchestrator's context swelling until it degrades. Build it in from the start rather than discovering the need when a run mysteriously slows and gets dumber late in the batch.

The playbook problem: shared knowledge without shared bloat

Every account benefits from your sales playbook — positioning, objection handling, segment-specific angles. The naive move is to paste the whole playbook into every sub-agent. Don't. Instead, store the playbook as a skill or reference that the sub-agent pulls the relevant section from based on the account's segment. A mid-market healthcare account loads the healthcare angle; an enterprise retail account loads a different one. Each sub-agent gets the slice of shared knowledge that applies to it and none of the rest.

This keeps shared knowledge genuinely shared — one source of truth you update in one place — while keeping each context lean and on-target. It also makes the playbook itself testable: when you change a segment's angle, your eval set tells you whether recommendations for that segment improved without disturbing the others. Shared knowledge and lean context are not in tension once you select the relevant slice per account rather than broadcasting the whole thing.

Frequently asked questions

Doesn't Claude's large context window make this irrelevant?

No. A large window is capacity, not free attention. Burying the one decisive fact under stale material still degrades judgment, and you pay for every token on every per-account call. Lean context is both higher quality and cheaper.

How do I decide what to exclude?

Apply one test to every candidate: does this change the recommendation for this account? If it only might be relevant, exclude it. Inclusion is earned, exclusion is the default. Summarize anything large before admitting it.

What is compaction and when do I need it?

Compaction is periodically summarizing a long-running agent's accumulated context down to its decision-relevant state and continuing from there. You need it for the orchestrator across a full run and for any sub-agent that spans many tool calls.

How do I share a playbook without bloating every context?

Store it as a skill or reference and pull only the segment-relevant slice into each sub-agent. One source of truth, but each account sees just the angle that applies to it — shared knowledge without shared bloat.

Bringing agentic AI to your phone lines

CallSphere applies this same context discipline to voice and chat — giving each agent exactly the caller context it needs and nothing more, so it answers every call, uses tools mid-conversation, and books work 24/7 without losing the thread. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.