Prompt and Context Design for Claude Cowork Agents

Ask two engineers why their Claude Cowork agent gave a mediocre answer and you'll often hear the same instinct: "it needs more context." So they attach more documents, load more skills, expose more tools — and the results get worse. Context is not a volume knob you turn up. It's a scarce resource you allocate, and allocating it well is the highest-leverage skill in agentic work. This post is about that allocation: precisely what belongs in a Cowork agent's context, what to deliberately keep out, and the reasoning behind each call.

The core principle: relevance density over volume

Context engineering is the practice of deciding what information enters a model's working context, in what form, so that the most relevant signal occupies the most attention — and in agentic systems it matters more than prompt wording. The reason is mechanical: the model attends across everything in context, so each irrelevant token competes with the relevant ones. A tightly curated context of the right three facts beats a sprawling one with thirty facts where three are useful.

This reframes the whole job. Instead of asking "what could possibly help?" — which leads to hoarding — ask "what does this specific step actually need?" The discipline of subtraction is unnatural; we're wired to feel safer adding. But in practice, the best-performing Cowork runs are the lean ones, where someone made hard choices about what to leave out.

What belongs in context

Five things earn their place. First, the agent's role and goal — one or two sentences, no more. Second, the operating rules that constrain every run ("cite the source for any number," "never fabricate names"). Third, the specific task with explicit inputs and the expected output shape. Fourth, the small set of tool schemas the task needs. Fifth, the minimal source data — the actual documents or records this step operates on, scoped as narrowly as you can manage.

flowchart TD
  A["Task arrives"] --> B{"Does this step need it?"}
  B -->|Yes, always| C["Role, rules, task, output shape"]
  B -->|Yes, this step| D["Scoped source data & tool schemas"]
  B -->|Reference only| E["Keep in skill, load on demand"]
  B -->|No| F["Leave it out"]
  C --> G["Lean working context"]
  D --> G
  E --> G
  G --> H["Sharper, cheaper run"]

The decision tree in the diagram is the whole method. For every candidate piece of information, ask whether this step needs it. Always-needed items (role, rules) stay resident. Step-specific items (this week's data, this tool) come in for the step and can be summarized away after. Reference material that's only sometimes relevant lives in a skill and loads on demand. And things the step doesn't need are simply left out — the hardest and most valuable category.

What to leave out, and why

Leave out background the model already knows. You don't need to explain what an invoice is or how email works; that spends context re-teaching general knowledge the model has. Leave out "just in case" documents — if the step doesn't operate on them, they're noise that dilutes attention. Leave out entire tool catalogs when the task uses two tools; every extra schema is a distraction and a possible wrong turn.

Most importantly, leave out raw tool output once you've extracted what matters. When a connector returns a large payload, the lasting context should hold the distilled conclusion — the three numbers, the matching record — not the original dump. This summarize-then-discard habit is what keeps long, multi-step runs coherent; without it, context fills with stale payloads the model must re-read on every subsequent turn, and quality decays as the run goes on.

Form matters as much as content

How you present information shapes how well the model uses it. Structured beats prose for data: a short labeled list of fields is easier for the model to reason over than the same facts buried in a paragraph. Put the most important constraints early and state them positively and concretely. "Report counts only for themes with three or more tickets" guides better than a vague "be careful about small themes."

Order has real effects too. Lead with role and the binding rules, then the task, then the data, then the output contract last so it's freshest when the model composes its answer. This isn't superstition — it's working with how the model weighs what it has read. A well-ordered, well-formatted context of modest size routinely outperforms a larger, messier one carrying the same underlying facts.

Designing context for multi-step runs

Single-shot prompts are easy; the hard part is keeping context healthy across a long agentic run where each turn adds material. The pattern that works is active curation: after each step, the agent keeps the distilled result and lets the raw inputs fall away. Think of it as a working memory that holds conclusions, not a transcript that holds everything that ever happened. This is why summarizing tool results isn't just an optimization — it's what makes long runs possible at all.

For genuinely large side-tasks, offload them to a sub-agent with its own fresh context. If a step needs to read fifty documents to extract one verdict, that reading shouldn't live in the main agent's context. The sub-agent absorbs the bulk, works in isolation, and returns only the conclusion. The parent stays lean. Used deliberately, this keeps the main run's context dense with signal even when the underlying work is heavy — at the cost of extra tokens, so reserve it for tasks where the isolation truly pays.

Frequently asked questions

Won't leaving things out cause the agent to miss something?

Rarely, if you keep what the step needs and load reference material on demand through skills. The bigger risk is the opposite: over-stuffed context dilutes attention so the agent misses what mattered. Curate for relevance, and load more only when a specific step asks for it.

How is context engineering different from prompt engineering?

Prompt engineering tunes the wording of instructions; context engineering decides what information surrounds those instructions and in what form. In agentic systems where context accumulates across many turns, the second discipline dominates — great wording can't rescue a context buried in irrelevant payloads.

Should I summarize tool results or keep them raw?

Summarize, then discard the raw payload. Keep the distilled conclusion the rest of the workflow needs and let the original dump fall away. This keeps multi-step runs coherent and stops the model from re-reading stale data on every later turn.

When should heavy reading go to a sub-agent?

When a step requires absorbing a large body of material to produce a small result — verifying many claims, scanning many records. The sub-agent carries that bulk in isolation and returns only the verdict, keeping the main context lean. Use it when isolation outweighs the extra token cost.

Bringing agentic AI to your phone lines

The same context discipline — keep what the moment needs, summarize results, offload heavy work — lets CallSphere's voice and chat agents stay sharp across long conversations, act with tools mid-call, and book work 24/7. Hear it for yourself 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.