agents guiding agents

since april, my workflow has changed more than my stack.

same tools, mostly.

different operating model.

in april i was writing about prompts as programs, proof gates, and the internet after the browser. those were the right ideas. they were still framed as things i was building toward.

now they are how i work.

coding agents are easy to misuse. ask a model to code and you get code. sometimes good code. often slop with confidence.

the work now is preventing slop.

that means designing the system around the model: roles, isolation, review, proof, state, approval.

the operating model

the core shift is role separation.

one agent should not plan, patch, review, verify, summarize, and decide whether production is safe in the same breath.

those are different jobs.

when they collapse into one context, the system starts optimizing for completion instead of proof.

my current pattern looks more like this:

human intent
→ hermes orchestration
→ agent lane assignment
→ claude / codex / subagents execute in isolated workspaces
→ independent review or verifier checks the work
→ durable state gets written to git, linear, files, logs, or an API
→ human approves irreversible actions

hermes is usually the orchestrator.

sometimes that means one main hermes session guiding claude and codex in tmux panes.

sometimes hermes spawns its own subagents, and those subagents guide claude or codex through tmux so the coding agents can keep their own clean session shape.

that sounds convoluted until you watch the failure modes disappear.

• claude can focus on the patch
• codex can look for a second path
• greptile can score the review
• hermes can hold the rollout state
• i can decide what gets to touch production

review is its own loop too.

greptile assigns a score. fix until it is 5/5. repeat.

claude workflows are useful when i need a council: review, architecture, release risk, product framing. sometimes that is five agents. sometimes it is 26 and a stupid amount of tokens.

expensive.

sometimes worth it.

phone as control plane

i run much of this from my phone now.

probably 95% by voice.

the phone is not my IDE. it is the control plane.

voice makes that work. it feels like walkie-talking a room of agents.

i can say more than i can type. the ideas flow better. i can steer at the speed of thought instead of the speed of thumbs.

that changes the work.

when the task is orchestration, the phone is enough:

• inspect a failing run
• split work into lanes
• tell claude to patch the narrow thing
• tell codex to search for a safe workaround
• verify GitHub logs and API state
• file follow-up tickets
• approve a canary
• widen rollout after proof

mobility matters too. i can walk, think, recover, and come back sharper. that sounds soft until you run this workflow for days. energy is part of throughput.

a real example

a production runtime skills rollout failed before publishing the desired release.

the skills archive built. then Node KMS signing failed while fetching an impersonated OAuth token:

unable to impersonate
Invalid response body while trying to fetch oauth2/v4/token
Premature close

rerun failed the same way.

clicking rerun again would have been cargo cult ops.

we split the problem.

lane 1: durable fix
  add a narrow retry around transient KMS auth / transport failures
  do not retry IAM failures
  add tests

lane 2: immediate ops path
  preserve the workflow contract
  use gcloud kms asymmetric-sign from GitHub Actions
  dry-run first
  then production canary
  then full rollout with behavior proof

the second lane found the path that got us unstuck.

gcloud signing worked, but the first dry run failed because the signature file was raw bytes and i treated it like base64 text.

good.

that is why dry runs exist. preflight signature verification caught it before anything touched production.

fixed that. dry run passed.

then canary.

then full rollout.

then a separate production convergence API check, because the workflow's own convergence condition was too weak.

the workflow lied

for cohort=all, the runtime OTA publish script exited success after one runtime was stably on the target release.

one.

for an all-cohort rollout.

that is the bug.

the GitHub run was green while the fleet still showed divergent runtimes. later the fleet converged, and the direct production API check showed:

converged: 7
divergent: 0
desiredReleaseStale: 0
legacy: 0
stale: 1
errors: []

the rollout ended fine.

the proof gate was wrong.

we filed two tickets:

• retry or replace the flaky KMS signing path
• fix all-cohort convergence so it waits for the active fleet, not one runtime

this is the line that matters: agents are useful when they show receipts.

otherwise they produce confident motion.

confident motion is how slop enters the system.

the loop

the durable unit is the loop:

trigger
context
hermes orchestration
lane assignment
independent checker
objective gate
durable state
human approval for irreversible actions

that is where the engineering leverage is.

the model matters. the prompt matters. the system around them decides whether the work can be trusted.

for this rollout, the fix was not a better prompt.

it was a better proof gate.

what to copy

if you are building this kind of workflow, start with one repeated task.

give it one orchestrator.

give it one maker lane.

give it one independent checker.

give it one objective gate.

give it one durable state sink.

then run it until it breaks.

when it breaks, ask which role collapsed.

• did the maker review its own work?
• did the workflow declare success too early?
• did state live only in chat?
• did connector auth get assumed instead of checked?
• did the human approve before there was proof?

those are the real bugs.

fix those and the system gets stronger.

not louder.

stronger.