I ran into this while building a workspace for teams using AI agents in business operations: matching invoices, onboarding suppliers, triaging a shared inbox, drafting refund replies. Picture six agents working a back office. One is checking invoices against orders while another sorts the morning inbox. A third is drafting a reply to a refund request. Then there’s the one that’s stopped. It found two different bank accounts on file for the same supplier, and it won’t guess which is current.
Look at the whole setup from a distance and all six seem busy. But only one needs a person. It’s the quiet one, producing nothing at all.
So I built a prototype for this specific problem, called Heedroom.
Coding tools already solved half of this
Engineers running multiple coding agents already have good tools for this. Claude Code’s Agent View lists sessions so you can see which need input, which are still working, and which have finished. You can answer inline without losing your place. Orca, an open-source workspace, takes this further: Claude Code, Codex, and other agents run side by side, each in its own git branch, with terminals and diffs in one window.
In both cases, the decision comes to you. You don’t have to go through every open session just to find the one that’s stuck.
Business agents need a different first screen
That helps, but business operations aren’t code. The person answering an agent’s question often isn’t an engineer. And usually it’s money at stake, not a merge conflict. Four things shaped what I built around that.
A label saying “needs input” doesn’t tell you much. I want to see what the decision is blocking, which sources disagree, and what will happen once someone answers. Take that supplier account: if a signed contract has one set of ending digits and a follow-up email has another, the agent should never pick one. It should show the conflict and wait.
Even the way agents are grouped needs to change: business areas instead of repositories. A finance lead should see Finance, Operations, and Inbox & admin. Branch names mean nothing to them.
Every agent should show its runtime and model, too. Real setups mix tools. The invoice matcher might run on one model, inbox triage on something cheaper, and the refund-reply drafter on something else again. Knowing which agent failed only gets you so far. You need to know whether it’s a model limit or a data problem, and that also tells you why one agent costs more than the others.
Then there’s silence. An agent that stops reporting hasn’t necessarily finished; it could be waiting, working quietly, or disconnected. Put a green “running” badge on it and you’ve hidden the distinction. I’d rather see an honest “unknown.”
If the connection drops, I want to see “unknown” until a fresh observation confirms the agent’s state.
Put blocked decisions first, and say why
Getting the information onto the screen is only part of it. Suppose one decision is holding up every subsequent payment to a supplier, while an older, optional report sits in the queue. The payment decision should come first. Sorting by age alone won’t get you there. The console should explain why it put something at the top, and a person should be able to override it.
There’s a harder problem here, too. A list can tell you which agents are working. It can’t tell you whether their results still fit together. An invoice agent matches an invoice against an order at ten o’clock. Someone edits the order at eleven. Now that match refers to a version of the order that no longer exists. To trust the system, I need every check tied to the exact data it saw, with results flagged when a later change makes them stale. Otherwise, that green checkmark stays put even though it no longer means what it says.
It’s also why I wouldn’t judge agent performance by tokens spent or tasks completed. Redoing work makes both numbers go up. I’d look at time spent waiting for a human decision and how often the same question gets asked again. How many stale results did we catch before they caused damage? How long did it take to get from a blocked decision to an accepted answer?
I’m still working this out. It’s an early prototype running on synthetic data, and the idea is evolving; this isn’t a finished product. The test I keep coming back to is what happens when I sit down at my desk again. Do I find the right decision faster? If I’m still opening agents one by one to figure out who needs me, the console hasn’t done its job yet.
More on how I’m thinking about this is on my writing page.
