# How I Delegate to Claude: Five Patterns That Stuck

> Five agentic coding patterns I keep reaching for — sequential, operator, split-and-merge, agent teams, and headless — plus the machinery (CLAUDE.md, subagents, slash commands, plan-first) that makes delegation repeatable and verifiable.

Author: Manik Soin (https://maniksoin.com)
Published: 2026-05-30
URL: https://maniksoin.com/blog/five-claude-code-workflow-patterns/
Tags: AI, Agents, Claude Code, Workflows, Developer Tools

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](https://github.com/manik-soin/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

```mermaid
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
```

| Pattern | When to use | Human involvement |
| --- | --- | --- |
| Sequential | Dependent steps, each output feeds the next | High: checkpoint per step |
| Operator | Driving a tool or UI toward a goal | Medium: set goal, watch loop |
| Split-and-merge | Embarrassingly parallel work, then recombine | Medium: own the merge |
| Agent teams | Wide investigation across separate concerns | Low: dispatch and synthesize |
| Headless | Repeatable automation triggered by an event | None: guardrails live in tooling |

### 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](/blog/anatomy-of-an-agent-harness) and [RAG-to-agent](/blog/from-rag-to-agent-harnessing-ordinance) 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.

```mermaid
flowchart TB
    LEAD[Lead Agent\nmain context] -->|dispatch| AAPI[API Explorer\nread-only\nroutes + handlers]
    LEAD -->|dispatch| ADATA[Data Explorer\nread-only\nschema + migrations]
    LEAD -->|dispatch| ADEPLOY[Deploy Explorer\nread-only\nCI + 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](/blog/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.

```mermaid
flowchart LR
    G[Goal] --> P[Draft plan]
    P --> A[I annotate\nthe plan]
    A --> R{Plan correct?}
    R -->|No| FIX[Address notes\nNOT 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.