How I Get Work Done With Agents (October 2026)

This is a snapshot, dated 19 October 2026. The setup below is how I work right now, on Claude Opus 5.5 and Codex. Models change every few months, and so does this setup. The routing skill below last changed its behaviour the day before this went out. If you are reading this well after October 2026, treat it as history and check the agent-skills repo for what the tools look like today.

I have written about memory, evals, permissions, subagents and a dozen other parts of working with agents. I have not written down how a piece of my own work actually gets from “we should build this” to merged. This is that post.

The short version: I lead the architecture conversation with an agent in the room. The result is written down before anyone breaks it into work. Then every change goes through a router called sluice, which decides how much process that change is worth. PRs go through magpie before a human posts anything. And what makes it production-ready is not the code generation. It is the review and testing wrapped around it.

Key Takeaways

Architecture starts as a conversation about what we are building, the constraints and what to be careful of. Then it moves to architecture, data model, flow and stack. All of it lands in persistent docs before any work item exists.

Not all work needs the same scrutiny. Sluice routes each change into one of four channels by its shape. Across my sessions the median fast change took 8 minutes of active time with no subagents. The median deep run took 90 minutes and dispatched 13.

The workflow is automated, but it is built to be re-measured. Sluice has 19 eval cases run with and without the skill, plus a freshness check that flags rules the current model no longer needs.

Magpie reviews PRs for clients, internal work, startups and my own projects. Of the findings it surfaced, 58% were posted after I read them in its report.

Claude Code is primary. Codex is the second opinion and the QA pass, because a different model catches what the first one talked itself into.

The setup in one paragraph

Claude Code is where the work happens. Codex is the second opinion. It peer-reviews magpie’s findings and does QA on the result: smoke tests, and dogfooding the thing that was built.

Work runs in git worktrees, which sluice cuts itself, so several implementers can work at once without fighting over one checkout. I parallelise as much as the plan allows. My global CLAUDE.md holds the rules I want in every session: no hacks, no disguised TODOs, tests written by hand against the spec, and report what is not done. The skills below enforce the parts that prose alone did not.

Architecture starts as a conversation

On most projects I am the technical lead, so the architecture discussion is mine to run. It always starts in the same place: what are we building, what are the constraints, and what do we need to be careful about. Only after that do we get to architecture, the data model, the flow and the stack.

The agent is present for all of it. I do not do the thinking somewhere else and hand the agent a ticket afterwards. Agents are a consistent tool in how I work, so everything in that conversation happens with one present.

The output is persistent documents, written before the work is broken into items. That ordering matters more than anything else on this page. A work item written before the design exists encodes whatever its author assumed. An agent will then build exactly that assumption, faithfully.

On the main product I work on, the docs/ folder now holds 214 specs and 355 plans. They are why a session that starts cold can pick the work up without being re-briefed, and the same goes for a different agent or a different person. I wrote about why this pays for itself in Spec-Driven Agent Development. I measured how much a precise spec narrows what agents build in Do You Still Need to Read AI-Generated Code?

Why route the work before doing it?

Everything after the design runs through sluice, a skill I built for Claude Code. The goal was to automate the workflow while still being able to adapt it, evaluate it and update it when models change.

It exists because the pipeline I used before charged every task the cost of the largest one. That pipeline put roughly 14k tokens of skill content and at least four round-trips with me in front of any code. It did that for a new billing system and for a one-line flag alike. It was defensible for a multi-week feature and had no way to scale down. Routing saves time because not all work needs the same amount of scrutiny at each stage.

Sluice sorts each request into one of four channels:

Channel	When	What it adds
`bypass`	No code change: a question, an explanation	Nothing. It just answers
`fast`	Existing interfaces, one subsystem	Test first, then a recorded passing check before handback
`main`	Adds an interface, or crosses two subsystems	Agree the intent first, hunt for bugs when there is a checkable claim, independent review before merge
`deep`	Three or more subsystems, or I asked for a plan	A written design and plan, signed off by me, then a hunt after the change goes live

The signal is the shape of the change, not its size. Whether a change adds an interface or crosses a subsystem boundary is knowable before writing code. Line count is not. A size-based router would be guessing at exactly the moment it has to decide.

What that looks like in practice

Between mid-September and mid-October, the agent announced a sluice channel 127 times across my sessions: 62 fast, 41 deep and 24 main. The sluice meter reads its numbers from the session transcript, not from the agent’s memory. It shows how far apart the channels are:

Channel	Sessions metered	Median active time	Median agents dispatched	Most agents in one run
fast	18	8 min	0	8
main	9	24 min	1	12
deep	28	90 min	13	47

Same skill, an order of magnitude apart, decided per request. That spread is the point. Paying deep-channel prices for a one-line fix wastes the time. Giving a billing change fast-channel scrutiny is how the bug below would have shipped.

Routing is per request, not per session. One long session often walks fast, main, deep and back to fast as the asks change. Sometimes the agent escalates mid-task. A “fix the chart” request on this blog started fast. Then the agent saw the fix touched the read-time helper, the OG images, the layout, the post cards and the analytics manifest. It said so and moved itself to main before writing the shared helper.

I steer it too. Usually that means naming the channel up front (“this should be fast so let’s address it directly on main”). Sometimes it means asking it to triage follow-ups (“do they require full work or are they fixes that can be in fast channel?”). More often I correct the process than the channel. “Did you not use sluice for this work?” shows up more than once in my sessions. Every miss like that became a change to the skill, not a habit I had to remember.

Deep runs: design, plan, then fan out

A deep run stops twice for me. The first stop is to sign off the design. The second is to approve the plan and answer the pre-flight questions: which tasks get a reviewer, which mechanical ones run at low effort, and whether to use one worktree or one per implementer. After that it runs without me.

The plan is a dependency graph, not a list. Each task declares what it needs, what it offers and which files it touches. Which tasks can run at once is derived from that, not guessed. Tasks that change nothing visible go first, and exactly one task, the flip, turns the new behaviour on. If something breaks late, it breaks at one known point.

Review is tiered. A review costs roughly what the implementation cost, so reviewing everything doubles the plan. Tasks that only create files get no review. Anything touching auth, data, money or concurrency gets a reviewer that cannot be downgraded, and so does every flip. Across 49 run records with 341 tasks, the median plan had 6 tasks and 55% of tasks were reviewed.

That flip rule earned its keep on a billing change. The strongest-model review on the flip came back with a Critical: “the flip does not fire for the user it was written for.” Essentially every self-serve user had an expired trial record, and it was checked before their live subscription. The ordinary path of sign up, trial, pay would still have been denied. Every task’s tests were green. The review caught it before merge.

The meter also shows something I did not expect. In several deep runs most of the wall-clock was waiting on me. One run took 22 hours 24 minutes, and 19 hours 33 minutes of that was me. The agents’ own work took a couple of hours. In a deep run I am the slow part. That is why I spend my attention on the two stops and not on the tasks between them.

Bug-hunter became a gate

Since 14 October, sluice also runs bug-hunter. In main it runs when the agreed intent states something checkable, such as a limit, a boundary or an invariant. In deep it runs across the whole diff after the flip. Its rule is “no repro, no finding”. It writes QA-style scenarios as failing tests in the repo’s own test runner and reports only what it can prove.

I had just written a guard hook to stop agents doing dangerous things in git, and bug-hunter proved five bugs in it. One was a quoted force push, git push origin '+main', that walked straight through. Another was an empty payload that passed unchecked instead of being rejected. The code had tests. They were the tests I thought of, which is the problem bug-hunter exists for. I wrote about that gap in Write the Test for What Must Never Happen.

How do you keep a workflow current when models change?

The part of sluice I care most about is not the routing. It is that the routing can be re-measured. Every rule in a skill like this encodes something the model could not do on its own when the rule was written. Models move, and a rule goes stale in one of two directions. Either the model stops obeying it, or the model starts doing the thing unasked and the rule is dead weight.

So sluice ships with 19 eval cases. Each runs twice, once with the skill and once with the bare model, with Opus 5.5 as the judge. The current baseline is skill 0.24.1 at three runs per arm. Averaged across all 19 cases, the skill scores 0.96 against 0.61 for the bare model. Two of those cases cannot meaningfully fail without the skill, so the true gap is a little smaller than that. The biggest gaps are where you would expect. Verifying before handing back scores 1.00 with the skill and 0.25 without. Agreeing the shape of a new interface scores 0.89 against 0.33.

A freshness check maps 43 rules to the cases that pin them. After each run it labels each case: regressed, redundant, or skill-worse. Redundant means the bare model now does it unaided, so the rule is a candidate for retirement. The first read found one case where sluice made the model worse, 0.54 against 1.00 without it. That is how the skill-worse label came to exist. Five cases already score 1.00 without the skill on Opus 5.5. Those rules are on notice.

The Opus 5.5 release in September is a good example of why this matters. Three things broke, and the evals found all three:

The channel announcement disappeared. 5.5 sometimes turns text written between tool calls into a paraphrased progress summary. The literal channel name then never reached the transcript. Sluice now announces through a tool call, which is kept as written.
It routed before reading the repo. 5.5 gets to work quickly, so it picked a channel before reading CLAUDE.md, which can rule sluice out entirely. The router now reads repo instructions first.
Effort replaced model as the cost lever. On 5.5, low effort comes close to medium on coding at much lower cost. Mechanical tasks now go to a low-effort implementer instead of a cheaper model.

None of these would have shown up as an error. They would have shown up as the workflow quietly doing less than it claimed. That is the main reason I trust a measured skill over a well-written prompt.

Magpie: PR review without the noise

Magpie is the PR reviewer I run on client work, internal work, startup work I pick up, and my own PRs when they need it. It was built to remove noise. An AI reviewer that posts forty comments trains everyone to ignore it, which is worse than no reviewer.

The pipeline:

Scout. Reads the PR description and the repo’s own review rules. That lets specialists flag “the diff does not do what the PR says it does”, a finding that reading the diff alone cannot produce.
Five specialists in parallel: security, bugs, performance, code smells and architecture. Large PRs are sharded so nothing is silently skipped.
Dedupe with evidence checks. A finding is dropped mechanically if it cites a file that does not exist, an invented line, or evidence that is not in the code.
Critic. Subagents re-read the worktree and keep, drop or merge each finding, with the lines they checked.
Peer review by Codex. A different model audits what Claude produced. Across ten reviewed PRs Codex made 68 changes: 63 corrections to existing findings and 5 new ones.
A local HTML report. The top ten are recommended and the rest are folded. Nothing posts automatically.

That last step is deliberate. I read every finding in the report and pick what goes on the PR, and magpie posts it as one GitHub review. Across the runs I have labelled, 142 of 245 findings were posted, 58%. Leaving out one third-round re-review of the same PR, it is 73%.

The precision work is measured too. On 63 hand-labelled findings, a rewrite of the critic lifted actionable precision from 0.64 to 0.79. The recall work is more humbling. I keep a list of issues that human reviewers found and magpie missed: 30 of them across six PRs so far. I tried a round of new specialist instructions aimed at those misses. Over about $122 of replays it showed no measurable gain, so I reverted it. Magpie is a first line, not the last one, which is the argument I made in AI Reviews the Diff. Humans Review the Decision.

What makes agent work production-ready?

Code generation is the cheap part now. The work becomes production-ready in review and testing, not in generation. Every piece above exists to put a check where a confident agent would otherwise skip one:

Fast: a test written first, watched failing, then a recorded passing check. A hook refuses the handback if the tree changed since the check.
Main: the same, plus a bug hunt against the agreed claim and an independent reviewer with fresh context.
Deep: a signed-off design, tiered review, a hunt across the whole diff after the flip, and a final review of the plan as a whole.
PRs: magpie’s five specialists, a critic, a second model, and me.
After that: Codex smoke-testing and dogfooding the build. A reviewer reading the diff and a user clicking through the product find different things.

What I would tell someone starting today

Copy the two ideas under my tools, not the tools. First, match the scrutiny to the shape of the change. A single pipeline for all work is either too heavy for small changes or too light for large ones. Second, measure your workflow against the bare model. The next model release will quietly make some of your rules unnecessary and break others.

The skills are public and MIT-licensed: bunx @iceinvein/agent-skills install sluice bug-hunter magpie. Sluice conflicts with the superpowers plugin, so disable that first.

Where the numbers come from

Every number in this post is first-party, counted by script on 18 October 2026:

Sluice routing and meter figures come from my Claude Code session transcripts, mid-September to 18 October 2026, across 12 projects. The meter counts output tokens and wall-clock only, with no dollar costs. Route counts include sessions spent building sluice itself.
Deep-run figures come from 49 sluice run records written between 23 August and 17 October 2026.
Eval figures come from the accepted Opus 5.5 baseline and the design docs in the agent-skills repo.
Magpie figures come from 8 labelled review runs over 7 PRs, 3 August to 26 September 2026. That is a small sample, and one PR was reviewed three times.

Client and product names are left out on purpose.

Frequently Asked Questions

Is this still how you work?

It describes my setup as of 19 October 2026, on Claude Opus 5.5 and Codex. Expect it to have changed. The evals exist precisely so that it changes when the models do.

Why route by the shape of a change instead of its size?

Because shape is knowable before the code is written and size is not. Whether a change adds an interface or crosses subsystems can be judged from the request and the repo. The diff’s line count only exists afterwards.

Does magpie post comments on its own?

No. It produces a local report with its top ten recommended findings, and a human picks what to post. About 58% of the findings it surfaced have been posted.

Why use Codex alongside Claude Code?

A second model does not share the first one’s blind spots or its confidence in its own reasoning. In magpie’s peer-review stage, Codex corrected 63 of Claude’s findings across ten PRs and added five it had missed.

Do the agents take part in architecture decisions?

They are present for all of them, but I lead the discussion and the decisions. What gets written down before work items exist is the part that keeps every later session consistent.