AI Agent Control Plane: The List That Says Who Needs You
Learn what an AI agent control plane does, why fleets need one, and how orchestration, permissions, and observability fit together in real workflows.
What does it look like when one agent out of five is stuck?
Tuesday, 14:10. Five agents are running across three repositories. One finished its refactor an hour ago. One is deep in a test run. The third asked a question at 13:50 (should it overwrite the config file, y or n?) and has been waiting since. Nothing on screen has changed in twenty minutes, because a waiting agent does not make noise.
Every terminal is open. Every log is readable. The person who started them is looking right at the stuck one and cannot tell it from the busy ones.
That scene is the real problem behind the phrase AI agent control plane. AuricIDE has no component with that name, and no commands called that. What it has is an Agents panel and an Agent Console. Both rest on one idea. A control plane is a short, ranked list of the things that need a person, with the answer one click away. It is not a wall of status lights.
Is more visibility the answer?
The obvious fix is more to look at: more dashboards, more logs, more metrics per agent. Visibility sounds like control.
It is not. Ten agents in ten terminals are completely visible, and the stuck one is still invisible, because every terminal looks the same from the outside. Adding a chart of tokens per minute only gives the person another thing to scan. Attention runs out long before information does.
A better question is which of the five agents needs a human right now. The tool should answer that. The person should not have to.
How does AuricIDE decide what needs you?
The Agents panel groups agents by repository. At the top sits a group called "Needs attention", and it has an order. Agents that ended in an error come first, then agents waiting for input, then agents that look stalled.
Two of those states are guesses, and the app is open about how it guesses. An agent shows "Needs input" when the last lines of its output look like a prompt: a y/n question, "do you want to...?", "press enter". Silence alone never triggers it. An interactive agent shows "Stalled?" after 120 seconds without any output, with a note such as "quiet 2m". A headless run gets 45 minutes, counted from launch, because a headless command often prints nothing until it is finished. An interactive agent that has not printed anything yet is not flagged, and one that printed in the last five seconds simply shows as working.
When nothing needs anyone, the panel says so with a green "all quiet" chip. That chip is the most useful part of the design. Quiet is a result. It tells a person they can look away.
What can a person do about it?
The card is where the answer happens, so it carries the actions. A waiting agent can be answered with "Reply to agent...", and a stalled one can be nudged with a single Enter. A failed agent can be retried, which starts a new process with the same configuration. An agent that is busy but not urgent can be set aside. It folds into a one-line row and still counts as running, and the setting lasts only for the session. Stopping asks "Stop this agent?" first, and a stopped agent disappears from the panel.
For the wider picture there is the Agent Console, a full-screen overlay. Project clusters are drawn as blocks, sized by how many agents each one has. A header sums it up in one line. It counts how many agents are running across how many projects, how many need you, and how many are done and not yet reviewed. A merged activity feed runs underneath. Auto-opening the Console on the start screen is a setting, and it is off by default.
Agents that run unattended work differently. A headless agent runs without a terminal in front of it, exits when it is done and leaves an entry in the inbox. A failure shows up as a toast and an inbox entry, unless the Conductor is going to retry the work itself. Needs input and stalled create no inbox entry at all. They show up in the attention list and nowhere else. What a fleet should record about its agents over a whole afternoon is a different question, and AI agent monitoring covers it.
Back in the scene, the same afternoon looks different. The panel shows "Needs attention · 1" at the top, and the card under it reads "Needs input". The person reads the question and types n. The agent continues. The other four never asked for anything. They stay out of the way. The whole interruption takes less time than finding the right terminal would have.
Later, two more agents finish while the person is in a meeting. Both were started as headless runs, so each leaves an inbox entry saying it finished, with a summary. No window had to be open. Nothing was missed.
What does this cost?
The guesses can be wrong. "Needs input" depends on the last five lines of output looking like a prompt, so an agent that asks its question in an unusual way can sit unrecognised and look like it is working. "Stalled?" is a fixed wait of two minutes, and an agent that is thinking through a long tool call gets flagged the same as one that is hung. The 45 minutes for headless runs has the opposite cost: a real hang there takes a long time to surface.
The other limits are small and manual. A set-aside agent comes back after a restart. A stopped agent leaves no card to look at afterwards. And none of this decides anything for the person. The list says who needs attention, and the person still has to give it.
That is a deliberate decision. A control plane that answered the prompts on its own would be quicker, and it would also be answering questions nobody had read. AuricIDE ranks and surfaces.
It leaves the answering to a human.
What stays true in any tool?
Information is cheap. Attention is not. Any setup that runs several agents ends up with more output than one person can read in an afternoon, however carefully they follow it. The useful tool decides what to show. It says plainly when there is nothing to show, and it puts the reply next to the question.