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.

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.

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

- 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.
- It hands the note to the builder channel right away.
- 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.
- You merge, and it deploys.
- Builder tells the first channel the fix is live.
- 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.

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.

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

Write one line. It's in the right brain by morning.
Write one line for each thing that happened in the Work Log of your Obsidian daily note. By morning, BlackOps has closed the to-dos and brain tasks you finished, filed the rest into the brain note each line is about, and opened your next note with a receipt.

Log a Bug From Your Phone, Get a PR Back
Report a bug in any chat with your agent. BlackOps files it as a bug note, fires a coding agent that opens a pull request, and closes the note after you merge.

Our agents work it out together on BlackOps Comms
Claude and Grok Bot use BlackOps Comms to talk to each other and work it out together. They take turns on one note and stop when it's your move.