One agent finds the bug. Another ships the fix.

A channel hands its bug to builder. Once the fix is deployed, builder tells that channel to try again, so the agent that hit the bug is the one that checks the fix.

One agent finds the bug. Another ships the fix.

We already had a way to hand bugs to an agent. Log a Bug From Your Phone, Get a PR Back walks through it: a bug note in BlackOps, a bug-fixer Sortie that starts a Claude Code session, and a pull request at the end.

It worked, but two parts of it wore on us. Every Sortie opened a new session. If we wanted to keep working on a fix, to ask a question or push it in another direction, we had to go find that session in routines and open it there. And to find out where a fix stood, we fired another Sortie to ask, which wasn't as reliable as just looking.

Before: each step fired a Sortie that started its own session, you found that session in routines to keep working, and a status check took another Sortie. Now: one builder channel you open in Duet to check in or keep going.

Now bugs go to our builder channel in Claude Duet instead. Builder is one ongoing chat that works on the BlackOps code. To see where a fix stands, or to keep going on it, we open builder in Duet and read or type. There's no session to find and nothing to fire.

We run our agents in separate channels like that, one per area of work. One channel handles our day to day and keeps the daily notes. Builder handles the code. Both are Duet, our agent in Claude Duet, and both are connected to BlackOps. When one channel hits a bug that belongs to the other, the channels carry it themselves. The channel that finds the bug hands it to builder. Builder fixes it, and once the fix is deployed, it tells that channel to try again. The agent that hit the bug is the one that checks the fix.

The round trip

The round trip in six steps: a channel writes a bug note you approve, the note lands in BlackOps, builder picks it up and opens a pull request, you merge, and builder tells the first channel to try again.
  1. A channel hits a bug and writes it up as a bug note in BlackOps. It shows you the note and saves it when you say yes.
  2. It hands the note to the builder channel right away.
  3. Builder reads the note, finds the cause, writes the fix and tests, and opens a pull request. The PR link goes back on the note.
  4. You merge, and it deploys.
  5. Builder tells the first channel the fix is live.
  6. The first channel runs what failed again.

You approve the bug note and you merge. Everything that moves between the channels moves without you.

A real run

Here's that loop on a bug we hit in our own daily notes, start to finish.

The bug

Our work channel generates a daily note each morning and commits it to a vault, the git-backed Obsidian repo that BlackOps syncs notes into. That vault had just been connected as a new target on another of our sites.

The daily note generated in BlackOps, but every write to the vault failed with "Vault target not found." All of that day's meeting notes failed the same way. The vault target showed as active in settings the whole time.

The handoff

The channel asked whether to log it as a BlackOps bug. On our yes, it wrote the bug note: what happened, what should have happened, steps to reproduce, a High severity and the repo. That put it on the Bugs board.

Builder used to sweep for new bug notes within the hour. We told the work channel to stop waiting: any bug logged there goes straight to builder. It passed this one over on the spot.

Recreated messages from two channels: the work channel logs the vault bug and passes it to builder; builder finds the cause, fixes it with seven new tests, merges on your word and says the fix is live; the work channel confirms the note reached the vault.

The fix

Builder read the bug note and the daily note code and found the cause. The vault was registered on a different site than the one running the daily note, and the daily note writer only looked for vault targets on its own site.

Before: the daily note runs on site A and only searches site A, so a vault registered on site B returns Vault target not found. After the fix: the daily note looks the vault up by its own ID and writes to it on site B.

The fix looks the vault up by its own ID, in three places:

  • Writing notes. Daily notes and meeting notes can write to a vault on any of your sites.
  • Adding items. Items added to today's note reach the vault file there too.
  • Obsidian edits. Edits and ticked boxes in that vault come back to BlackOps.

Seven new tests fail on the old code and pass on the fix. There's no migration. Builder put the PR link on the bug note and stopped for the merge.

The one step we still did by hand

The bug reached builder as a plain thread, not a task. In Claude Duet, the Tasks list is where you see what's open and where you approve the next step, and a bug passed over from another channel doesn't land there on its own. Builder can make a task by itself when we've just written to it, but work that arrives while we're away, like another channel's bug, starts as a thread.

So builder said this one had no task yet. We said "Make it a task," and the fix moved onto the Tasks list, ready for our merge. We've put in a feature request for every new item that reaches a channel to start as a task, whoever sends it. Until then, it's one short message.

The retry

We typed merge and it deployed. Builder could have regenerated the note itself to check. It didn't. Regenerating rewrites that day's note in place, and the note belongs to the work channel, which had already said it would regenerate it once the fix landed. So builder told the work channel the fix was live and left the retry to it.

The work channel regenerated the note, and it landed in the vault. The same run also turned up a separate problem, and the channel reported that straight back to us too.

That's the reason the retry goes back to the agent that found the bug. Builder knows the code. The work channel knows the job, so it knows what "fixed" should look like and notices what's still off. A fix isn't done when the pull request merges. It's done when the thing that failed works.

Across the whole run, we said yes to the bug note, made the fix a task and typed merge. We never copied a message from one channel to another.

What BlackOps holds in the middle

The channels message each other in Claude Duet. What they hand each other is a BlackOps note.

  • The bug note is the work order. Every bug note has the same fields: status, severity, what happened, what should have happened, steps to reproduce and the repo. Builder reads it by ID, so nothing gets retyped or lost between channels.
  • The Bugs board shows where it stands. The note is the card, so when an agent writes a new status into it, the card moves.
  • The fix goes back on the note. The PR link and what changed stay with the bug, and they sync to your vault with every other note. The next agent that touches that code can search past bugs before it starts.

The Sortie setup still works if you run one chat and one coding agent. Once you run a set of channels, a builder channel you can open is easier to live with.

Set it up yourself

  • A channel per area of work. Connect BlackOps to each one, so every channel reads and writes the same notes.
  • A builder channel. Give it your repo, and let it open pull requests.
  • A bug-logger skill in BlackOps. Every channel writes bugs in the same format and asks before saving, whichever agent you're talking to.
  • Two standing rules, said once. The channel that logs a bug hands it to builder right away. Builder tells that channel to try again once the fix is deployed.
  • The merge stays yours. Builder opens the pull request and waits.

Then the next time an agent hits a bug, it doesn't wait for you to notice.

See how BlackOps works at blackopscenter.com, or start your trial.

Related Posts