Prompt and Context Design for Claude Cowork

Two Claude Cowork deployments can use the same model, the same connectors, and the same skills, and behave completely differently — because one fills the context with everything that might be relevant and the other puts in only what is. Context is the most underrated lever in an enterprise agent. Get it right and the agent is sharp, cheap, and consistent; get it wrong and it's distracted, expensive, and erratic in ways that prompt-tweaking won't fix. This post is about the discipline of deciding what belongs in context, what to load on demand, and what to deliberately leave out — and why each choice changes behavior.

Key takeaways

• Context is a budget; every token you add competes with reasoning, so default to leaving things out.
• Put only always-true material in base context; load procedures on demand via skills.
• Give the agent retrieval paths to data instead of pasting the data — tools beat dumps.
• State constraints as crisp rules, not long explanations; the agent needs the limit, not the essay.
• Curate examples ruthlessly — a few sharp ones beat many mediocre ones that pull behavior off course.

Why context is a budget, not a backpack

It's tempting to treat the context window as a backpack — if it fits, throw it in. But every token the agent carries is a token it has to reason across, and irrelevant material actively degrades decisions: the model spends attention reconciling things that don't matter to the task at hand. A 1M-token window doesn't change this; capacity is not the constraint, relevance is. The right mental model is a budget you spend deliberately, where the question for every item is "does this earn its place on this request?"

This is why Cowork's dynamic skill loading exists. The design assumes you won't pour every procedure into the prompt; instead the base stays lean and relevant detail is pulled in only when the task calls for it. Designing context well means working with that grain, not against it.

What belongs in base context

Base context should hold only what is true on every request: the agent's role and tone, hard constraints it must never violate, and the small set of facts that frame all its work. "You assist the operations team; never close or delete records; always cite the ticket ID you acted on" is the kind of durable rule that belongs here. It's short, universal, and load-bearing on every turn.

What does not belong here is anything task-specific. The detailed steps for reconciling a ledger, the clause library for contract review, the format of last quarter's report — all of that is relevant sometimes, which means it belongs in a skill that loads when its moment comes, not in the base where it taxes every unrelated request.

flowchart TD
  A["Incoming request"] --> B{"True on every request?"}
  B -->|Yes| C["Keep in base context"]
  B -->|No| D{"Procedure for a task?"}
  D -->|Yes| E["Put in on-demand skill"]
  D -->|No| F{"Large data the agent needs?"}
  F -->|Yes| G["Expose via tool, fetch on demand"]
  F -->|No| H["Leave it out"]

The diagram is the whole decision in one view: every candidate piece of context gets sorted into base, skill, tool, or the cutting-room floor. Most material, honestly, belongs in the last two buckets.

Retrieve data, don't paste it

A frequent mistake is pasting a giant document or a full dataset into the prompt so the agent "has it." This bloats context and freezes the data at one moment in time. The better pattern is to give the agent a tool that retrieves exactly the slice it needs, when it needs it. Instead of pasting 200 tickets, expose search_tickets and let the agent pull the 5 that matter for this request.

The win is double: the context stays small and the data stays live. The agent works from current state rather than a stale snapshot, and you pay only for the rows that actually inform the answer. As a rule, if data is large or changes, it belongs behind a tool, not in the prompt.

State constraints as rules, not essays

When you need the agent to respect a limit, give it the limit, not a paragraph justifying it. "Never share customer PII in summaries" is a rule the agent can apply on every turn. A three-paragraph explanation of your privacy philosophy is something it has to re-read and interpret, and it competes for attention with the actual task. Crisp imperative rules are both cheaper and more reliably followed than discursive ones.

# Good base-context constraints (short, imperative, testable)
- Never close, delete, or modify records; read and draft only.
- Cite the ticket ID for every action you recommend.
- Do not include customer PII in any summary.
- If data is missing, ask; never fabricate values.

Each line is a check the agent can apply mechanically. That testability is the point — you can verify behavior against these rules, which you cannot do against a philosophy statement.

Curate examples, don't accumulate them

Examples are powerful and dangerous. A couple of sharp, representative examples teach the agent the shape of a good answer. A dozen mediocre or inconsistent examples teach it the average of all of them, which pulls behavior toward the middle and introduces contradictions. When in doubt, cut. One excellent example of the exact format you want beats five that are merely okay, and far beats a pile that quietly disagree with each other.

Common pitfalls

• Context as a backpack. Adding everything "just in case" dilutes reasoning. Default to leaving out; make each item justify its place on the request.
• Procedures in base context. Task steps that are only sometimes relevant belong in on-demand skills, not the always-loaded base.
• Pasting data instead of fetching it. Large pasted documents bloat context and go stale. Expose a tool and retrieve the needed slice live.
• Explaining constraints instead of stating them. The agent needs the rule, not the rationale. Long justifications cost tokens and reduce compliance.
• Too many examples. Inconsistent or excessive examples average out the behavior you wanted. Keep a few sharp ones and cut the rest.

Design your context in 5 steps

1. List every piece of context and sort each into base, skill, tool, or remove.
2. Reduce the base to role, tone, and hard constraints that hold on every request.
3. Move all task procedures into skills with trigger-friendly descriptions.
4. Replace pasted data with tools that retrieve the exact slice on demand.
5. Rewrite constraints as short imperatives and trim examples to a few sharp ones.

Keep in context vs. leave out

Material	Decision	Why
Role, tone, hard limits	Base context	True on every request
Task procedures	On-demand skill	Relevant only sometimes
Large or live data	Tool retrieval	Stays small and current
Long rationale	Leave out	Costs tokens, not compliance

Frequently asked questions

Why not just put everything in context if the window is huge?

Because a large window doesn't remove the cost of irrelevance — the agent still reasons across everything you include, and unrelated material degrades its decisions. Capacity is not the constraint; relevance is, so spend the budget deliberately.

What belongs in base context versus a skill?

Base context holds what's true on every request — role, tone, and hard constraints. Task-specific procedures belong in skills that load on demand, so they cost nothing on the requests where they don't apply.

Should I paste a document into the prompt for the agent to use?

Usually no. Pasting bloats context and freezes the data. Expose a tool that retrieves the exact slice the agent needs, so context stays small and the data stays current.

How many examples should I include?

A few sharp, consistent ones. Too many examples — especially mediocre or contradictory ones — average out the behavior you wanted and introduce conflicts. When unsure, cut down to your best example of the exact format you want.

Bringing agentic AI to your phone lines

Lean, well-designed context is what keeps a live voice agent fast and on-script. CallSphere brings this discipline to voice and chat — assistants that answer every call, fetch only what they need mid-conversation, and book work 24/7. See it 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.