Claude Cowork Patterns: Prompts, Tools, and Context

Once you have shipped a couple of Claude Cowork workflows, you start noticing the same structural decisions recurring. How granular should a skill be? Should one tool do five things or five tools do one thing each? Where does shared context live so you are not pasting the same policy into every skill? These are the patterns that separate a Cowork deployment that scales to twenty workflows from one that becomes an unmaintainable tangle.

This is a patterns post, written for the engineer who owns more than one workflow and wants conventions that hold up. The examples are concrete and meant to be lifted into your own skills and connectors.

Key takeaways

• Keep skills single-purpose with a sharp trigger description — composition beats one giant skill.
• Design tools around verbs the agent needs, return structured data, and make schemas self-documenting.
• Separate stable context (policies, glossaries) from per-run context (the task data) so caching and reuse work.
• Make tools idempotent and return enough state for the agent to know whether to retry.
• Write skill instructions as decision procedures, not prose essays — the agent follows steps, not vibes.

Pattern one: one skill, one job, one sharp trigger

The temptation is to write a mega-skill that handles "all of finance." Resist it. Skills compose: Claude can load several into one run when each is relevant. A small, sharply-described skill loads at the right moment and stays out of context otherwise. A sprawling skill either loads constantly, eating context, or never matches cleanly.

The discipline is in the description field, because that is the trigger. Compare a vague trigger with a sharp one:

description: Helps with finance tasks.          # too broad, loads everywhere
description: Use when reconciling a vendor      # sharp, loads only for this
  invoice export against the general ledger
  and flagging amount mismatches.

A reusable rule of thumb: if you cannot write a trigger description that names the input and the goal in one sentence, the skill is doing too much. Split it.

Pattern two: tools as verbs that return structured state

Tools are where the agent touches the world, and the shape of a tool determines how reliably the agent uses it. The pattern is: one tool per meaningful verb, a typed input schema, and a return value that is structured data plus enough status for the agent to reason about what happened.

flowchart TD
  A["Agent decides to act"] --> B["Choose tool by verb"]
  B --> C["Fill typed input schema"]
  C --> D["Connector validates & runs"]
  D --> E{"Success?"}
  E -->|Yes| F["Return data + status: ok"]
  E -->|No| G["Return error + retryable flag"]
  F --> H["Agent continues plan"]
  G --> H

The key detail is the return shape. A tool that returns a bare string forces the agent to parse prose to figure out whether it worked. A tool that returns a structured object — a result payload plus a status and, on failure, a retryable flag — lets the agent make a clean decision. Here is the contract I reach for:

{
  "status": "ok",
  "data": { "matched": 612, "exceptions": 4 },
  "retryable": false
}
// on failure:
{
  "status": "error",
  "message": "ERP read timed out",
  "retryable": true
}

With this shape the agent's logic is trivial: on error and retryable, try again; on error and not retryable, surface to the human. You have moved control flow out of fuzzy text and into data. This matters more than it first appears, because the alternative — an agent reading "the operation may not have completed" and guessing — is exactly where flaky, hard-to-reproduce agent behavior comes from. A structured return turns a probabilistic interpretation into a deterministic branch.

A related pattern is to keep the data payload small and pre-digested. If your tool can return either six hundred raw ledger rows or a computed summary of matched and unmatched counts, prefer the summary and offer the raw rows behind a second, explicit tool the agent calls only when it needs to drill in. Returning the firehose by default floods the agent's context with material it usually does not need, which is the tool-design equivalent of the context-bloat problem skills are meant to avoid.

Pattern three: stratify context by lifetime

The most expensive mistake in multi-workflow Cowork is pasting the same policy text, glossary, or coding standard into every skill. It bloats context, drifts out of sync, and defeats caching. The pattern is to stratify context by how long it lives.

Stable, shared context — the company's expense policy, the chart-of-accounts glossary, the tone guidelines — belongs in a shared resource that many skills reference, and because it does not change between runs it is a prime candidate for prompt caching. Per-run context — this month's invoice export, this specific request — is loaded fresh each time. Keeping these separate is what lets you update a policy in one place and pay for the stable prefix once across many calls.

Pattern four: make tools idempotent

Agents retry. A flaky network, a re-plan, a checkpoint rejection — any of these can cause a tool to be called twice. If your "notify controller" tool sends a message every time it runs, a retry double-notifies. The pattern is idempotency: design mutating tools so calling them twice with the same input has the same effect as calling them once.

The standard technique is an idempotency key — the agent passes a stable key derived from the task, and the connector dedupes on it. For a notification, the key might be the period plus the report hash; the connector records keys it has already acted on and short-circuits duplicates. This single pattern eliminates a whole class of "the agent did it twice" incidents.

Pattern five: write instructions as procedures

Skill instructions are not documentation; they are a procedure the agent executes. Numbered, imperative steps with explicit decision points outperform flowing prose. "If any invoice lacks a match, list it as an exception and do not proceed to notification" is a step the agent can follow. "Be careful about unmatched invoices" is a vibe it will interpret inconsistently.

The same applies to stop conditions and escalation. Spell out exactly when the agent should halt and hand back to a human — "if total variance exceeds the threshold, stop and ask" — rather than hoping it infers caution. Agents are good at following clear procedures and unreliable at guessing your risk tolerance, so encode the tolerance. A practical test for any skill body: hand it to a competent new hire with no other context. If they could execute it without asking you a clarifying question, the agent can too. If they would have to guess, so will the model, and it will guess differently on different days.

Apply these patterns in five steps

1. Audit your existing skills and split any whose trigger description names more than one input or goal.
2. Refactor tool return values to a structured {status, data, retryable} contract.
3. Extract repeated policy and glossary text into one shared resource referenced by skills.
4. Add idempotency keys to every mutating tool and verify a double-call is a no-op.
5. Rewrite skill bodies as numbered procedures with explicit stop and branch conditions.

Common pitfalls

• Mega-skills. One skill that does everything loads constantly and reasons poorly. Compose small ones.
• Stringly-typed tool returns. Forcing the agent to parse prose for success/failure breeds flaky control flow. Return structured status.
• Copy-pasted policy text. Duplication drifts and bloats context. Centralize stable context.
• Non-idempotent mutations. Without idempotency keys, retries cause duplicate side effects. Make writes safe to repeat.
• Essay-style instructions. Prose invites inconsistent interpretation. Write executable procedures.

Frequently asked questions

How many tools should one connector expose?

As many distinct verbs as the workflow needs, but no "do everything" tool. One clear verb per tool with a typed schema lets the agent choose correctly and keeps each schema small enough to surface only when relevant.

What goes in a skill versus a tool?

A skill is procedure and judgment — how to do the task. A tool is an action with a side effect or a data fetch. If it changes the world or reaches a system, it is a tool; if it tells the agent how to think about the task, it is a skill.

Why does context stratification matter for cost?

Stable context can be cached so you pay for it once across many runs, while per-run data cannot. Mixing them defeats caching, so you re-pay for unchanging policy text on every single call.

Is idempotency really necessary if I have checkpoints?

Yes. Checkpoints gate human-visible actions, but retries can still fire automatically below the gate. Idempotency protects against duplicate effects that no human ever saw coming.

Bringing agentic AI to your phone lines

CallSphere builds on these same patterns — sharp skills, structured tool contracts, idempotent actions — for voice and chat agents that answer every call, use tools live, and book work nonstop. See the patterns running in production 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.