How I Delegate to Claude: Five Patterns That Stuck

Type a prompt, get a wall of code, eyeball it, paste it somewhere. That is roughly how I started out with Claude Code, and it works fine for snippets. For me it started to wobble the moment a task spanned more than one file, needed a decision made before code existed, or had to run while I was asleep.

After building Ordinance and this portfolio mostly through Claude Code, I’ve gradually settled into five patterns that tend to work for me. None of them are clever prompts. They’re shapes of work, ways I structure a task so that delegation becomes repeatable and, more importantly, verifiable. Speed for its own sake was never really what I was after. What I wanted was higher output volume without lowering my own bar on correctness.

This is a snapshot of how I work right now. Plenty of people work very differently, and my own setup keeps shifting, so treat this as one practitioner’s notes rather than a method to adopt wholesale.

A small lesson I keep relearning: if it only works when I’m there to nudge it, it wasn’t a workflow for me. It was a conversation.

The five patterns

flowchart TB
  subgraph S1[1. Sequential]
    direction LR
    A1[Step] --> A2[Step] --> A3[Step]
  end
  subgraph S2[2. Operator]
    direction LR
    B1[Claude] -->|act| B2[Tool / UI]
    B2 -->|observe| B1
  end
  subgraph S3[3. Split and Merge]
    direction TB
    C0[Task] --> C1[Subtask]
    C0 --> C2[Subtask]
    C0 --> C3[Subtask]
    C1 & C2 & C3 --> C4[Merge]
  end
  subgraph S4[4. Agent Teams]
    direction TB
    D0[Lead] --> D1[API agent]
    D0 --> D2[Data agent]
    D0 --> D3[Deploy agent]
  end
  subgraph S5[5. Headless]
    direction LR
    E1[Trigger / CI] --> E2[Claude] --> E3[Result]
  end

1. Sequential: steps in order, each output feeds the next

My default. I break a task into ordered steps where step N depends on the output of step N-1. What helps me most is making the boundaries explicit rather than handing over a vague paragraph and hoping.

When I added the semantic cache to Ordinance, the chain was: write the migration for the embedding column, backfill existing queries, wire the cosine lookup into the request path, add the audit-log fields, run the eval suite. Each step has a checkable output before the next begins. If the backfill produces garbage embeddings, I find out before any retrieval code is touched, not three steps later when results look subtly wrong.

Sequential is unglamorous, but for me it’s where context discipline starts. One concern at a time means the model isn’t juggling the migration and the request path in the same breath.

2. Operator: Claude drives a tool or UI toward a goal

Here Claude isn’t writing code, it’s operating something: a CLI, a browser, a database shell, a deploy dashboard. I give it a goal and the means to act and observe, and it loops: act, read the result, decide the next action.

For Ordinance I reach for this constantly against the database. “Find chunks where section_hierarchy is empty and tell me which documents they came from” turns into a sequence of psql queries where each result shapes the next one. I’m not specifying the queries; I’m specifying the goal. The same pattern handles “the Railway deploy is failing, figure out why”: Claude pulls logs, forms a hypothesis, checks an env var, confirms.

What makes operator mode feel safe to me is the feedback loop being real. The tool’s actual output, not the model’s imagination, drives the next step.

3. Split-and-merge: fan out, then recombine

Some tasks are embarrassingly parallel. I decompose into independent subtasks, run them concurrently, then merge the outputs. This is the same instinct behind Ordinance’s query expansion (fan three query variants into parallel hybrid searches, then RRF-fuse the results), except here the fan-out is work, not retrieval.

The most useful application for me has been drafting. This very blog series (the harness and RAG-to-agent posts included) started as a split-and-merge: outline the posts, spin up an independent pass on each that pulls real details from the relevant part of the codebase, then merge into a consistent voice and cross-link them. Each draft was researched against the actual code rather than my memory of it, which is why the architecture diagrams match what’s deployed.

Merging is the part I’m tempted to skip, and the part I’ve learned not to. Parallel outputs always have seams: duplicated intros, inconsistent terminology, contradictory claims. The merge step is real work, not a cat.

4. Agent teams: specialized subagents with their own context

This is where, for me, it stops feeling like a chat and starts feeling like delegation. I define subagents in .claude/agents/, each with its own system prompt, its own context window, and its own allowed tools. The lead agent dispatches; the subagents report back summaries.

The payoff I notice most is context discipline. When I onboard onto an unfamiliar codebase, I’ll spawn three explorers at once: one on the API layer, one on the data model, one on the deploy and infra config. Each reads deeply in its lane and returns a tight summary. The lead never has to hold five thousand lines of someone else’s code in its main context; it holds three paragraphs. The investigation goes wider and the working context stays cleaner.

I find it useful to scope tools per agent too. A read-only explorer doesn’t get write access. A deploy agent gets the deploy CLI but not the ability to edit source. For me that separation is as much a safety property as an organizational one.

flowchart TB
  LEAD[Lead Agent
main context] -->|dispatch| AAPI[API Explorer
read-only
routes + handlers]
  LEAD -->|dispatch| ADATA[Data Explorer
read-only
schema + migrations]
  LEAD -->|dispatch| ADEPLOY[Deploy Explorer
read-only
CI + infra config]
  AAPI -->|summary| LEAD
  ADATA -->|summary| LEAD
  ADEPLOY -->|summary| LEAD
  LEAD --> PLAN[Synthesized plan]

5. Headless: Claude in automation, no human in the loop

The final shape removes me entirely. Claude runs in CI or a cron job, triggered by an event, producing a result that another system consumes. No interactive approval, so for this to work the guardrails have to live in the prompt and the tooling, not in my judgment.

I run a headless triage automation: when an issue lands, Claude reads it, labels it, checks whether it reproduces against the current main branch, and either drops a diagnostic comment or flags it for me. It runs without me watching. The discipline here is the inverse of interactive work: because nobody is reviewing each step, I’ve found the task has to be narrow, the tools have to be scoped tight, and the output has to be a structured artifact (a label, a comment, an exit code) rather than prose I’d have to read anyway.

For me, headless is the honest test of whether a workflow is genuinely repeatable. If it only works when I’m there to nudge it, it wasn’t a workflow. It was a conversation.

The machinery that makes it work

The patterns are the shapes. Four pieces of machinery are what let me reuse them instead of reconstructing context every session.

CLAUDE.md is persistent project memory. Conventions, the deploy pattern, infra identifiers, the things I’d otherwise re-explain every session. Ordinance’s CLAUDE.md records that everything is TypeScript with Zod at every boundary, that migrations run on boot on Railway, that the faithfulness judge runs on the cheaper model. Without it, every session starts cold and the model re-derives decisions I already made, usually slightly differently.

Subagents are the unit behind agent teams, but I find them useful even solo: spawn an explorer to answer one question without dragging its entire investigation into the main context. The summary comes back; the noise stays out. (I went deep on subagents as an architecture primitive in Anatomy of an Agent Harness; here they’re a daily tool rather than a system component.)

Slash commands package a repeatable workflow into one invocation. My /fix-issue command encodes a whole sequence: read the issue, reproduce, write a failing test, fix, confirm the test passes, summarize. I’m not retyping that procedure; I’m running it. For me, slash commands are how a one-off workflow turns into something I can lean on again.

Plan Mode is probably the one I’d be most reluctant to give up. Instead of jumping to code, Claude produces a plan. I annotate it: this assumes the cache is warm, it isn’t; this query needs the is_current filter. Then the part that matters most for me: address my notes, don’t implement. The plan gets revised. I annotate again. Only when the plan is right does implementation start.

flowchart LR
  G[Goal] --> P[Draft plan]
  P --> A[I annotate
the plan]
  A --> R{Plan correct?}
  R -->|No| FIX[Address notes
NOT code]
  FIX --> A
  R -->|Yes| IMPL[Implement]
  IMPL --> V[Verify]

The reason this works for me: catching a wrong decision in a plan costs a sentence. Catching it after the code exists costs a refactor, plus the risk that I review tired and miss it. Plan-first moves verification to the cheapest possible point. For Ordinance’s retrieval pipeline, the plan-first loop caught a design where query expansion would have run before the cache check, burning model calls on queries that should’ve returned in 15ms. That was a one-line note on a plan, not a production incident.

What I take away from it

The throughline, at least for how I work, isn’t any single pattern. It’s the move from one-shot prompting toward delegation I can trust. Each pattern is a different shape of handoff; the machinery is what makes the handoff repeatable for me instead of artisanal.

The payoff I see shows up as volume, not just speed: I ship more because three explorers run while I review one plan, and a triage bot works issues while I sleep. It shows up as context discipline, because subagents and CLAUDE.md keep the working set small. And it shows up as verifiability, because plan-first catches wrong decisions before code exists and headless forces structured, checkable output.

Speed turned out not to be the part I cared about most. What keeps me coming back is delegation that’s reproducible and verifiable. Your mileage and your setup will almost certainly differ from mine, and mine will have changed again by the time you read this.