Reusable Claude Code Patterns for GTM Engineering

After you've shipped one Claude Code GTM workflow, you start to see the same shapes recur. The first build is improvisation; the second is where patterns emerge; by the fifth you have a small library of moves you reach for without thinking. This post collects those reusable, code-level patterns — the ways of structuring prompts, tools, and context that separate workflows that survive contact with real revenue data from the ones that quietly break.

None of these are framework-specific tricks. They're design patterns in the classic sense: named solutions to problems that keep coming up when an LLM orchestrates real GTM systems. I'll describe each with enough specificity that you can apply it tomorrow.

Pattern 1: The prompt as a typed contract

The most durable pattern is to stop thinking of a prompt as instructions and start treating it as a contract with a defined output shape. Instead of "score this lead and tell me about it," you specify: "Return a JSON object matching this schema — icp_score (0-100), confidence (0-1), rationale (two sentences max), signals (array). If you cannot determine a field, set it to null and lower confidence." The schema does the heavy lifting; the prose just frames the task.

This pattern pays off because a typed output is machine-checkable. You validate every response against the schema before it goes anywhere, and a validation failure becomes a retry or a review task rather than a silent error. A useful rule: any model output that feeds a downstream system should be structured, and any structured output should be validated. Free-form prose is fine for the rationale a human reads, never for the fields a pipeline consumes.

Pattern 2: Narrow tools over fat tools

When you design the tools Claude acts through, prefer many small, single-purpose tools over a few large ones. A get_account_signals(domain) that returns one well-defined payload is easier for the model to call correctly than an account_manager(action, params) that branches internally. Narrow tools give the model fewer ways to go wrong, produce clearer error messages, and are independently testable.

The flow below shows how narrow tools compose into a scoring decision, with each tool a distinct, retryable step rather than one monolithic call.

flowchart TD
  A["Subagent receives account"] --> B["get_account_signals(domain)"]
  B --> C["get_crm_history(domain)"]
  C --> D{"Conflicting headcount?"}
  D -->|Yes| E["reconcile via model judgment"]
  D -->|No| F["use enriched fields directly"]
  E --> G["score_lead(fields)"]
  F --> G
  G --> H["emit EnrichedLead matching schema"]

Notice that score_lead is its own deterministic tool. Pulling scoring out of the prompt and into code is itself a pattern — call it the deterministic spine — and it's what keeps your numbers reproducible while the surrounding language varies.

Pattern 3: Layered context, loaded just in time

Context is a budget, and the pattern that scales is layering it. Keep three layers. The always-on layer is small and lives in project memory: the goal, the schema, the hard rules. The retrieved layer is account-specific context pulled in only when an account is being worked — its CRM history, past objections — via a tool call, not pre-loaded. The ephemeral layer is the current working set the subagent holds while it reasons.

The anti-pattern is dumping everything into one context window and hoping the model finds what matters. That bloats cost, dilutes attention, and makes runs harder to reason about. Just-in-time retrieval — give the orchestrator a thin index, let each subagent fetch only its slice — keeps each context focused and lets fan-out run in parallel without 400 copies of the same boilerplate.

Pattern 4: The confidence-gated write

Every GTM workflow needs a single place where model output becomes durable state, and that place should be gated. The pattern: collect the model's proposed record, validate it against the schema, check its confidence against a threshold, and branch. High-confidence valid records get an idempotent upsert; everything else becomes a review task with the reason attached. This is the same idea across enrichment, scoring, and routing — one gate, applied consistently.

What makes this reusable is that the gate is independent of what's being written. Whether you're upserting a lead, updating an account tier, or flagging a churn risk, the shape is identical: propose, validate, gate, write-or-defer. Centralizing it means you fix a class of bugs once. It also gives you a natural metric — review rate — that tells you at a glance whether the model is confident or floundering.

Pattern 5: Tiered models by task difficulty

A cost-and-quality pattern that recurs: match the model tier to the task. Use Opus 4.8 for orchestration and genuinely ambiguous synthesis, where a wrong call cascades. Use Sonnet 4.6 for the bulk of enrichment subagents — capable, faster, cheaper per token. Use Haiku 4.5 for cheap, high-volume classification like "is this an inbound or a partner referral." The orchestrator routes each task to the cheapest tier that can do it well.

This pattern only works if your tasks are decomposed finely enough to route. That's another reason to favor narrow tools and small subagent jobs: granularity is what lets you push cheap work to cheap models. Teams that run one giant Opus call for everything pay for capability they're wasting on classification a Haiku model handles for a fraction of the cost.

Pattern 6: Replayable runs with structured logs

The final pattern is operational: every run emits a structured log of what it did — accounts touched, tools called, scores assigned, decisions and their reasons. This isn't just observability; it's what makes runs replayable and auditable. When a sales leader asks "why did this account get a 30," you read the log, not the model's mind.

Pair the log with idempotent writes and you get a system you can safely re-run: a failed nightly job reruns from the last checkpoint without duplicating work, and a disputed batch can be regenerated to compare. Logs plus idempotency turn an opaque agent into an accountable one, which is the difference between a tool revenue trusts and one they tolerate.

Frequently asked questions

Why treat a prompt as a contract instead of instructions?

Because a contract has a defined, machine-checkable output shape. Specifying a JSON schema lets you validate every response before it reaches a downstream system, turning silent errors into explicit retries or review tasks. The prose only frames the task; the schema enforces correctness.

Are narrow tools really better than one flexible tool?

For agent reliability, yes. Single-purpose tools give the model fewer ways to fail, produce clearer error messages, are independently testable, and decompose finely enough to route across model tiers. A fat tool that branches internally hides complexity the model then has to reason about.

How much context should I pre-load?

As little as possible. Keep an always-on layer with the goal, schema, and rules; retrieve account-specific context just in time via tools; and let subagents hold only their working set. Pre-loading everything bloats cost and dilutes the model's attention.

What's the simplest way to control agent cost?

Tier your models by task difficulty and decompose work finely enough to route. Orchestrate and synthesize with Opus, run bulk enrichment on Sonnet, and push high-volume classification to Haiku. Granular tasks are what make this routing possible.

Bringing agentic AI to your phone lines

These patterns — contract-shaped prompts, narrow tools, gated writes — are exactly how CallSphere builds its voice and chat agents that answer every call, act through tools mid-conversation, 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.