A small team, half of it made of agents.
We started running Claude Code sessions alongside people — a developer in one timezone, a contractor on one repo, and a dozen sessions that each think they’re the only one in the checkout. The coordination problem stopped being about machines and became about who can see what, and who is waiting on whom.
JQ Teams is the answer we’re building for our own team as it grows. It sits on top of JQ Agents, which watches the machines. This one coordinates the people.
What’s running today
Roles that fail closed
Owner, member, contractor. A contractor sees only the checkouts they’re assigned to — with no assignment, nothing at all. Forgetting to scope someone gives them an empty screen rather than everything, which is the direction a mistake should go.
Two gates on what anyone reads
A machine opts a repo in before any session text leaves it — and that gate binds everyone, including the owner. Inside an opted-in repo, only people assigned to it can read a session’s question. Liveness without content is the default relationship between two people here.
Who’s working on what, in one view
Every working tree with a session in it, and who owns it — one row per checkout per machine, rather than one per person, so a checkout that is live with nobody assigned is the loudest row on the board instead of an absence you have to notice. Not per repo: a repo with three worktrees is three rows, because that is where the work actually is.
A queue that says what’s blocked on whom
Every open pull request with one verdict attached: ready, waiting on a reviewer, back with the author, or gone quiet. A bot review never counts as an approval — it can’t leave one — so “reviewed” never quietly means “nobody looked”. And a check that has never once passed is reported rather than allowed to block, because a permanently red job is furniture, and merging past it becomes a habit.
Ops health, including what was switched off
Crons, errors, heartbeats and system health on one page — plus the part no other page can show: what has been muted or switched off on purpose, why, and what would turn it back on. A job that is off does not fail, so nothing else will ever raise its hand about it; a silence with no end date is a decision waiting to be made again rather than a thing that quietly became permanent.
Contract jobs with the argument settled up front
Scope, assign, hand off, track to done — with the person, the money and the acceptance criteria as fields rather than paragraphs in an issue nobody re-reads. A job can’t be offered until it has all three, because the expensive failure in contract work is disagreeing afterwards about whether it was finished. And it can’t be offered to someone scoped to see nothing, which is otherwise a silent, correct, completely baffling empty screen for whoever accepted it.
Revocation you can prove
Removing someone keeps the row and stamps when it happened and who did it, in fields that later edits can’t overwrite. A soft delete is only an audit trail if the fields recording it are immutable — ours weren’t, until a reviewer pointed it out.
What isn’t built
Four things, and they’re the four that would make this a product rather than an access model:
- The other half of “who’s working on what”: a session is not yet linked to the task it is working on, so the board shows who owns a checkout, not what they are doing in it.
You can’t install this today
It runs on our machines, for our team, and the relay reads a filesystem we start by hand. Making it work on someone else’s machine is real work we haven’t done — and we don’t want to do it until we know whether anyone else has this problem.
So: one email, if and when it opens. Nothing else, and no drip.