JQ Agents
If you run more than one AI coding session, you lose track of them. One is waiting for an answer, one stopped an hour ago, one is still working — and you find out by walking back to the laptop and checking each window.
JQ Agents is a read-only board of the whole fleet: which repo, which branch, how long idle, and which sessions are actually waiting on you. Readable from a phone.
Where this actually stands
We built it for ourselves, it runs on our own machines every day, and it is not something you can install yet. Making it work on someone else's machine is real work we haven't done. So this page is a question rather than a launch: if you'd use it, say so, and that's what decides whether it gets built properly.
If enough people don't, we'll say that too, and you'll never hear from us about it again.
How it works
A small relay runs on your machine
Claude Code already writes a transcript for every session. The relay reads the last few lines of each one — which repo, which branch, when it last moved, and whether the turn ended asking you something — and posts that summary. It never reads your code, and it can’t type into a session.
The board groups them by repo, not by session
Several sessions usually share one checkout, and the branch is a fact about the checkout. So you see “three sessions on quicksites-v2, one of them blocked” rather than a flat list of ids you have to decode.
You get told once, when one starts waiting
The alert fires on the moment a session becomes blocked — not every minute while it sits there. Several at once arrive as one message. A session that stopped hours ago never pages you at all.
“Two ways to do this migration: add a nullable column (reversible, slightly messy) or a new table (cleaner, needs a backfill). Which do you want?”
JQ Agents: hivejournal-2026 is waiting on you
A session just started waiting on you.
• hivejournal-2026 · feat/checkout-rewrite
“Two ways to do this migration: add a nullable column (reversible, slightly messy) or a new table (cleaner, needs a backfill). Which do you want?”
You answer them where they're running — the board is read-only and can't reply for you.
What it shows you
Which sessions hold which repo
Grouped by working tree, not by session — because several sessions routinely share one checkout, and the branch is a fact about the tree. You see “three sessions on quicksites-v2, two on main, one on a feature branch.”
Which ones are waiting on you
Not “idle” — waiting. A session that ended its turn with a question is different from one running a tool, and both are different from one that was interrupted and simply stopped. The board tells them apart and says which.
How long it has been
Live, idle, stale or ended, from the last real activity. “Not running” never reads as “hasn’t answered” — the two look identical from outside until something checks, so every row states its own liveness.
Nothing it shouldn’t
Question text is off by default, per working tree. A repo you never thought about reports that a session exists and nothing about what it said. Turning it on is a deliberate act, one tree at a time.
Coming next
None of this is built yet, and the list is short on purpose. Each item came from asking the sessions in our own fleet where they actually lost time, so every one is anchored to something that went wrong rather than to a feature that sounded good. Where a session's answer contradicted our assumptions, we kept the session's version.
Why a session is slow, not just that it is
The board can say what every session is doing and not why one of them is crawling. This samples each machine — load, memory, disk, and the round-trip time and jitter to the model API — and names the constraint. The expected answer is “nothing”, and it renders nothing at all in that case: a badge that is always present is a badge nobody reads.
Built after a session spent an afternoon slow on a laptop showing three healthy Wi-Fi bars. The signal was fine; the link had negotiated a low rate on a crowded channel, and no bar count would ever have said so.
Tell a session that another one is already in its tree
The board already groups by working tree, so it can answer “is someone else in this checkout right now.” The gap is that no session ever asks, because sessions don’t open dashboards. This makes it a one-shot read an agent can take at the moment it’s about to branch, commit or push — still read-only, still no command channel.
Two sessions of the same product answered one question independently within a minute of each other, neither aware of the other. One had asserted, from a real check it ran, that this couldn’t happen to it. The check it used cannot detect the case: local tools report the tree, not who else is standing in it.
Tell a session when something it claimed turned out to be wrong
A session states conclusions constantly and receives corrections almost never. When one session records a claim and another later contradicts it — in a commit, a review, a test that now fails — the board holds both halves and can close the loop.
A session recommended the same database index four times over eleven hours. It could not have worked. Another session found the flaw and shipped the correct one; the first learned of it by accident and would otherwise still be recommending it.
A question that knows whether it was answered
Today a waiting session has one state: waiting. It can’t tell “nobody has seen this” from “you read it and moved on” from “this stopped mattering an hour ago.” Asked, seen, answered, superseded — with superseded doing most of the work, because what usually ends a question isn’t an answer.
Three items sat unanswered for two days and were re-reported four times, identically, which is indistinguishable from nagging. Two had already been resolved by a different session, and nothing told the one still asking.
Measuring rework, not just waiting
The obvious next step is ranking fixes by time recovered. The trouble is that the measurable thing is latency and the expensive thing may be rework — work redone after going confidently in the wrong direction. That time isn’t slow, it’s negative, and no resource graph will show it. We’d rather ask the question in public than ship a number that’s precise and beside the point.
Put to us by one of our own sessions, whose measured friction was almost entirely of this kind: hours lost with the processor essentially idle.
What it deliberately doesn't do
You can't answer from it. There is no reply box and no command channel — nothing on the board sends an instruction, a message or a keystroke into a running session. That was the first thing we cut, on purpose. A surface that can drive your agents remotely needs to prove it's you, and a board that only reads doesn't. You read here; you answer where the session is.
It doesn't hoover up your transcripts. Sessions accumulate whatever you paste into them, which for most developers includes credentials at some point. So the text of a session's question is off unless you turn it on for a specific repo, it's truncated, and secret-shaped strings are scrubbed before anything leaves the machine.
Part of JQ, the assistant that runs through HiveJournal. See the full feature list.