Focus mode for AI agents
contents · notes
# contents
# in this post
▣fig.1 · A PR that is ready to merge. All screenshots use made-up data from a fictional ticketing app.img ▣fig.2 · A plan waiting for approval.imgor rss. no spam, one-click out.
I only want to be involved in a unit of work twice: when I approve the plan, and when I judge the finished pull request. Everything between those two moments should run without me.
The factory
That is what our "factory" does. My teammate Steven built the first version, and I've been running mine on top of Claude Code for a few weeks. One unit of work, usually one Linear ticket, moves through fixed stages:
- Verify: check the ticket against the actual code. Is the problem real, and is the proposed fix still right?
- Plan: write a plan with me. This is the first time it stops and waits.
- Build: write the failing test, the fix, and open a draft PR.
- Review: an automated code review, repeated round after round until it comes back clean.
- QA: exercise every permutation it can think of, in a real browser and against real data.
- QA report: publish what was tested and what passed.
- Risk: publish a risk assessment: blast radius, what could break, what to watch after deploy.
- Done: mark the PR ready, then keep watching it until it merges, answering review bots and merging the main branch when conflicts appear.
The change this makes is that nothing pauses for me in the middle. I approve a plan, go do something else, and come back to a PR with a QA report and a risk report attached.
Parallel factories
Most real projects aren't one unit of work. A project I'd once have done ticket by ticket usually turns out to be five tickets that don't depend on each other.
So the second step was a bulk version of the factory. It plans the whole project with me once, then runs one factory per sub-ticket at the same time, each moving through build, review, QA and the reports independently. The terminal shows a table: one row per ticket, one column per stage, and a row turns amber when that ticket needs an answer from me.
The new bottleneck: me, clicking around
A few days of parallel factories moved the bottleneck from the work to my attention. I'd have six or seven agent sessions open in the agents list, and finding the one that needed me meant opening each of them: is this one still in review? Is that PR green yet? Did CodeRabbit leave a comment nobody answered?
None of that checking is a decision. It's logistics, and it's exactly the kind of work an agent should do for me.
agentctl: the agents bring the work to me
So I built agentctl, a small terminal app that replaces the agents list as the thing I keep open all day. It flips the relationship: instead of me checking on agents, they bring me what needs a decision, one item at a time.
The header says how many items need me and how many agents are running. Below it is a single card: the one thing I should do right now.
This card says a PR is ready to merge, and "ready" has a strict meaning. All three gates must be green:
- CircleCI passes.
- No merge conflicts with the main branch.
- Every CodeRabbit comment has been answered and resolved.
If any gate is red, the PR never reaches me. The factory keeps working on it in the background, and the card only appears once it's clean.
The card also reminds me what the project is, because I'm switching between five of them. Then my review is quick: read the QA report, read the risk report, look at the PR, and decide. When the QA report is solid I often ship without opening the app in a browser myself. We'll see whether that ever bites me; so far it hasn't.
What reaches the queue
Only moments that need a human make it into the queue. Everything else stays with the agents.
| Card | When it appears | What I do |
|---|---|---|
| Ready to merge | The factory is done and CI, conflicts and CodeRabbit are all green | Read the QA and risk reports, review the PR, merge it in GitHub |
| Approve plan | A factory finished planning and is waiting for a yes | Approve it, or say what to change |
| Answer questions | A session stopped to ask me something | Answer, and it carries on |
| Stalled | Something has made no progress for 2 hours, or a finished PR is still red | Find out why: the card names the failing gate |
The order matters too. PRs that are ready come first, because finishing work beats starting more. Plans and questions come next, because each one is an agent sitting idle. Stalled work comes last.
The dispatcher: starting work by itself
The queue handles the end of the pipeline. The dispatcher handles the start, so I don't have to pick what's next either.
Every 5 minutes it looks at the Todo tickets in my current Linear cycle that no session is working on yet:
- A ticket with an open "blocked by" relation in Linear waits.
- For the rest, a quick Claude check compares the ticket with the work in progress. If it builds on an unmerged PR, or would collide with the same feature, it waits, with a one-line reason.
- Anything left gets a factory:
claude --bg "/factory <ticket>".
A new factory comes back to me as an "approve plan" card once it has a plan. Holds and starts show up as one-line notices in the header, like held MQ-472 · waits on MQ-445 (unmerged #2301) in the screenshots above.
It has no cap on how many factories run at once. Every one of them stops for my approval before it builds anything, so the plan step is the real gate.
Getting around
I wanted to never leave this screen, so moving in and out of sessions had to be one key:
- → opens the card's Claude session in the same terminal. ← on an empty prompt brings me straight back to the card.
- ↑ / ↓ or the mouse wheel browse the queue without skipping anything.
- s skips the card for now; z snoozes it for an hour.
- Every link is clickable: hover underlines it, a click opens it. The number keys 1–9 open them too.
The ← key took some work. Claude Code's own attach command sends ← to its agents list, with no setting to change that. agentctl runs each session through a small relay that notices Claude leaving the session and presses Esc on the agents list for me, so it never flashes on screen.
Where this stands
I built this in a day, and I can't say yet whether it will change how I work as much as the factory did. The dispatcher is the least proven part: I've tested its decisions, but I haven't let it run unattended through a full cycle.
The idea I'm most excited about is the shift itself. If the agents handle the logistics, my day becomes a queue of decisions only a person can make: approve this plan, answer this question, ship this PR. Everything between those moments just happens.