Management – Xedant

Management is the section for those who have many agents and one or two people watching them. Ten agents you can still hold in your head; a hundred, no: each needs watching, each needs something confirmed, each needs its spend counted. The section is built so that attention goes only to what really needs a decision, and everything calm stays out of the way.

The main principle is management by exceptions: while everything is fine, the console is almost empty and silent. The moment an agent needs your decision or something goes wrong, it floats to the top — with a short explanation of what the agent is busy with and what it needs from you. States are never made up: each is confirmed by a verifiable signal (the container’s condition, the connection to the agent, the live event flow), and when there is no evidence, it says “unknown” instead of guessing something plausible.

Why a console at all

In ordinary work, agents bother no one: they run on schedule, answer in chats, write code. Trouble starts when there are dozens of them: one waits for a confirmation and stands still for hours, another unexpectedly burns through the budget, a third lost its connection, and a fourth asked a question you never noticed. You cannot track that by hand.

The console solves three jobs. First — show at a glance whether everything is all right. Second — gather everything waiting for a human into one place and not let it get lost. Third — explain where the money and time go, and not let spend grow unnoticed.

One more peculiarity: a notification here is a transition, not a state. When a situation repeats, the counter on the existing row grows and no new notification is created. That is why a calm day never turns into a stream of identical messages.

The map of screens

The section consists of ten screens: the root Fleet and nine items in its list — Fleets, Registry, Chats, Decisions, Cost, Tokens, Posture, Policies and Analytics last. Any of them is a couple of steps from any other, and the command palette searches across all of them at once.

Fleet — the section’s root. It answers the main question: is there anything that needs attention. It shows the state of all agents, a few key numbers (how many chats run right now, how many decisions wait, errors per day, spend per day), an attention zone with the top of the decision queue and the latest events. Every number sits next to its own norm, so you can tell whether it is high or low; every metric has its own “calm threshold”, and when it is crossed the value is highlighted — with an icon and a word, not by color alone;
Fleets — named groups of agents that work together. Members of one fleet can live on different servers. A fleet can be created, changed and deleted, and its name must be unique. On a fleet card the members are grouped by server, and every server group is collapsed by default: you see the server’s name and the number of members, while the members themselves unfold on a click on the row. A server label leads to its page, a member name to the agent’s card. An empty fleet corresponds to no agent until members are added to it;
Registry — the table of all agents: state, what it is busy with, how long idle, today’s spend, risk class and the time left to answer. There are quick filters (“need a decision”, “errors”, “stuck >15 min”, “expensive”, “quarantine”, “shadow”, “offline”), grouping by server, owner, tags and state, named views and three row-density levels. The board with the “Queued”, “In progress”, “Blocked”, “In review” and “Done” columns lives here too: cards can be dragged, and that is a real change of priority, not a rearrangement on the screen;
Chats — the chat history of all agents: status, duration, cost, tokens. Rows page through numbered pages of ten, and the list has an exact total. The “Server” and “Agent” columns are separate and clickable: the server leads to its page, the agent to its own. Any chat opens into a step-by-step breakdown: what the agent did, how long each step took, where time was lost, what caused the error. The breakdown is a record of the real course of work, not a re-run;
Decisions — everything waiting for a human: agents’ questions, reviews of finished work, and plain notifications. Details below;
Cost — what one successful chat costs (not the token spend alone), with the sample size. Here too: spend today, this week and this month, the forecast to the end of the month, spend ceilings and the breakdown by agent, owner, server, tag, task type and model;
Tokens — how many tokens in total and where they go. One number per entity: input, output and temporary-store reads and writes add up together and are never split by kind. Plus tokens per successful chat, windows for today, the week and the month, the forecast to the end of the month, calm charts and the same breakdown as on “Cost”;
Posture — a 0-to-100 assessment of your infrastructure’s condition: the weak spots it found (broken accesses, agents without an owner, idle containers, expiring licenses, spend growth against the usual), behavior observations, who creates the most errors and spend, and the incident mode;
Policies — the autonomy rules: what an agent may do on its own, what it must ask about, which tools are forbidden, how much it may spend, and which confidence thresholds turn the queue on;
Analytics — charts over the fleet with named filters: there is “All”, saved filters and “New filter”, and inside a filter three tabs — “Fleets”, “Servers” and “Agents”.

In tables and on charts an agent is labelled with its short name while that name is unique in the list. When names match, the server is added to the name — “server/agent” — so that two rows with the same name never look identical. Where the server is already shown as its own column or a group heading, the name stays short.

Permanent elements hang over every screen: the status line in the header, the notification icon, the command palette and the keyboard cheat sheet. There is no bar at the bottom of the screen — the decision queue reminds you of itself with an icon in the section list, the number in the browser tab title, the chips in the header, the notification centre and the attention zone on “Fleet” itself.

The status line in the header

The header always holds two separate chips, and each answers for its own thing. They are two different messages, not one: a click on one does not repeat a click on the other.

The problem chip — while the fleet is calm it is not there at all. It turns red when there is trouble: “Agents offline: N” or “Agents stuck: N”. It turns yellow when things wait for a decision: “N decisions waiting”. A click on the red one opens “Fleet”, a click on the yellow one the decision queue;
The work chip — always there, green, with the number “Chats running: N”. It counts chats, not busy agents: an agent running three chats at once gives three, not one. A click opens “Chats” filtered by “running” — exactly the rows that were counted.

The number in the browser tab title — “(N)” — stays while the queue is not empty and goes out together with it. The site’s own tab icon is always the same and never changes on any event: you cannot tell from it whether something happened — for that there are the chips in the header.

Agent states

Every deployed agent has exactly one state, and it is always backed by a signal:

busy — processing a chat, that is, working right now;
thinking — work is going, but the last live event is a reasoning step or a step still executing;
idle — the container runs, but nothing is being processed;
waiting for a decision — a question to a human hangs in the chat, and the reason is named in words: a human is needed, or we are waiting for the model provider, an external system or a tool;
stuck — the work counts as running, there is no question, but no live signals have arrived past the silence threshold (10 minutes by default; a separate agent can have its own);
offline — only by evidence: the connection to the agent does not answer, or the container check saw that it is stopped;
unknown — there is no evidence either way. That is how it is right after a MultiAgent restart or while the connection to the server does not answer. Such agents count neither as reachable nor as unreachable: they do not go into the “offline” numbers and do not color any badges.

What matters is that “waiting for a decision” is never confused with “stuck”. When an agent has asked a question and patiently waits for the answer, that is how it is marked — however long it stays silent. The silence threshold does not apply to it. “Stuck” is when there is no question and no signs of life either: then it is worth opening the chat breakdown. This separation removes false alarms: you know exactly where something waits for you and where something is broken.

An agent that is not in the observation at all stands apart. “Not deployed” is not a state but a sign: there is definitely no container (the agent is not deployed yet, the record was imported as a single row, or the container was removed). Such an agent drops out of the observation entirely — no state, no events, no numbers — and comes back on its own when the container appears again. A vanished container is neither an incident nor a recovery, so silently dropping out of the list means nothing and notifies nothing.

A state change reaches every window at once, but a repeat of the same state creates neither an event nor a notification. A state is visible not only by color: each has an icon and a word, so everything stays distinguishable even in black and white. When there is no data at all, a question mark and the word “Unknown” are shown — not a zero and not a guess.

The Decision Queue

The Decision Queue is the heart of the section. Everything that cannot decide itself lands here, and only this can interrupt you. There are three kinds of items:

Question — the agent asks and stands still without an answer;
Review — the work is finished and needs accepting or sending back. This is how, for example, overnight jobs that ran without a human arrive: in the morning you see what came out and what it cost;
Notification — just a message. It never interrupts, has no deadline and does not grow the badge counter.

Every item carries a risk class, and it decides how much time there is to answer:

T1 — reversible and cheap (for example, a small sum that is easy to return). Such items approve themselves and never reach the queue at all: only a journal record remains;
T2 — ordinary. 60 minutes to answer;
T3 — blocking: an irreversible action or a large sum. 15 minutes to answer, and when the time runs out, the agent’s work is suspended so it does not hang forever waiting for a human.

The queue is ordered not by arrival time but by importance: risk, cost and deadline proximity. Different requests stay separate rows and are decided one by one — there is no batch “approve all” button. But a full repeat of the very same request creates no new row: the counter of the one already standing grows “×N” — ten repeats of one request do not become ten rows and do not flood the screen.

A row leads to where the decision is made: a click on it (or Enter) opens the chat in which the agent waits for the answer; a record without a chat — for example, a proposal to change the rules — opens a card with the plan and buttons. A question is answered in the chat: such a row has only “Dismiss” and “Open”, and no “Approve” or “Reject” buttons. The “Dismiss” action removes the record from the queue without deciding anything: it is neither an approval nor a refusal, and it does not feed the rule learning. And if a question was answered right in the chat and the “question” label was taken off it, the record closes itself with the reason “Answered in chat” — no need to wait until you come to the queue. The state changes at once, without a page reload.

Every decision is written to the journal: who, when and why. A rejection requires a reason. A deferred item returns on its own when its time comes — with a fresh response deadline. Rejections with the same reason are a signal: after the third such case, the queue itself offers to change the rule instead of asking the same thing a fourth time. And when some recurring operation is confirmed over and over without disputes, the system may start approving it by itself — but only when earned, and always with a journal record.

Above the list sits the queue’s “budget”: how many decisions were made today, how much time they take and how many items have been hanging for over a day. The guideline is 40–60 decisions a day; it is a ceiling, not a goal: when the queue asks for more, the agents lack autonomy — tune the rules instead of speeding up.

Records created neither by a human nor by an emergency but by an ordinary scheduled auto-run do not reach the queue at all: such a run lives in “Chats” like any other work. Only what genuinely asks a human stays in the queue.

Incident, freeze and stop

When a big trouble happens, the console switches to incident mode. It is the only exception to the “silent screen” rule: a bar with the incident’s cause and duration appears above the whole application, and the section shows the maximum of detail. The mode is switched on manually (a reason is required and lands in the journal) or automatically — when many agents drop at once or errors pour in. On leaving the mode, a draft post-mortem is collected: what happened, what was done, what was decided.

Fleet freeze is a brake for what already runs. It stops the current runs and holds back the requests queued in those chats, so the agent does not restart them on its own. Requests that arrive after the freeze are not held — a freeze does not block work entirely. Lifting the freeze releases exactly the requests that were held: nothing extra is let go and nothing is forgotten.

“Stop all” stops the agents’ containers one after another and asks you to type a confirmation word — that is how serious it is. Safe mode during an incident is gentler: the autonomy rules drop to the most cautious “propose” level and queued requests are held; runs already in flight keep working. On leaving the incident, what was held is released and the rules return to their former level.

Hotkeys and the action search

Everything the console can do is reachable from the keyboard too — a real speedup when decisions come in batches. The command palette (⌘K or Ctrl+K) opens from any screen and searches across sections, agents, live queue items and actions. The ? key opens the cheat sheet with all the combinations. Dangerous actions always ask for confirmation first, and irreversible ones make you type a name.

Navigation: 1–8 across the section’s eight screens, i — the decision queue, / — filter the list, r — refresh the data;
Through the list: g/G — to the top and the end, j/k — down and up;
On a row: Space — quick peek, Enter — open, P — pause processing, S — stop, R — restart, E — escalate, H — shift handover, A — approve, X — reject (a reason is required), D — defer, Shift+S — dismiss without deciding, T — chat breakdown, Q — quarantine;
Undo: ⌘Z reverts the last reversible action (for example, it lifts a pause and releases exactly the requests that were held), Esc closes the window.

Keys never fire while you are typing text. Row and navigation combinations can be remapped to your liking, and a reset button restores the originals.

Notifications

A notification appears only when at least one condition holds: you asked for it, there is a time dependency, your decision is needed, or it is personal context. Everything else stays a state in the interface and lands, at most, in the daily digest. That is how the console avoids turning into a news feed.

A notification can take several routes — and each route shows what exactly it carries:

The Decision Queue — for what waits for a human. You are reminded of it by the icon in the section list, the “(N)” in the browser tab title, the chips in the header and the attention zone on “Fleet”;
the notification centre (the header icon) — the shared journal of what happened, with one action: “Open”. Something read in one window dims in all the others;
a popup and a sound — only for blocking decisions and missed deadlines, and only when the tab is not in view;
a messenger — a short message with links goes to your system’s webhook address. Approving happens only in the interface: the link opens the decision card inside the app, where the details and the addressee are visible. A decision cannot be made from the messenger — a deliberate restriction for safety;
the daily digest — what was done, what was spent, which decisions were taken and what is left.

There are quiet hours (23:00 to 08:00 in the server’s timezone by default): ordinary notifications pile up and arrive in one batch after the window ends. Blocking decisions, quota and payment security messages, and automatically started incidents bypass quiet hours — you hear about those at once. The overall volume has three levels: calm, ordinary, advanced. Individual types can be demoted to the digest or turned off right from the notification row, but the most important classes have no switch — instead, a note explains why they cannot be turned off.

The agent asks for a decision itself

An agent does not have to wait for an answer in its chat — it can put the question straight into the Decision Queue, using the same access key the programmatic Agent API uses. The request then lands where it will surely be noticed, and does not get lost in the conversation.

curl -X POST <address>/api/agent/inbox -H "X-API-Key: $MULTIAGENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"review","title":"Deploy to production?","dedupKey":"deploy:prod",
       "riskHints":{"costEstimate":6000,"reversible":false},"agentChatId":42}'

The risk class is set by hints: whether the action is reversible and roughly what it costs. The system then decides honestly: a reversible and cheap action approves itself at once (leaving only a journal record), an expensive or irreversible one becomes blocking with a short deadline, and the rest queues up normally. Sending the same dedupKey again does not create new items — it grows the counter on the one already standing. The GET /api/agent/inbox command shows the agent its own active requests.

What is worth knowing

The console does not sugarcoat: where there is no data, it says so. It helps to know the limits in advance:

Quarantine and tool bans are management-level marks, not restrictions inside the agent itself. What really stops an agent is pause, stop and escalation; a tool ban marks it as unwanted and shows that in the interface;
“Thinking” accounting is shared. The ceiling covers all of a run’s tokens at once (request and reply) and says so honestly — there is no separate accounting of “thinking”;
Some numbers are last-known. Spend arrives as chat data updates — every few minutes, not the same second. A chat’s spend is attributed to the day of its last activity and stays there — restarting MultiAgent does not reset the picture and start anything anew;
Lists page through pages. Every list has an exact total and numbered pages of ten rows — rows beyond the open page are not lost. The counters in the header describe the last few hundred rows and always name the volume they were computed over;
A chat breakdown is a record. The step-by-step view and “playback” show things as they were and re-run nothing;
There are no shifts and no time zones. A shift schedule is a saved signature for team expectations, not a calendar. When no second operator is configured, the system says plainly that a notification is a repeat — it does not name a nonexistent operator;
Spend breakdown by account is unavailable, and the breakdown by model is an estimate (chat data keeps no separate per-model history). The Cost screen says so outright.

How the agents themselves and their chats work — on the Agents and Chats pages; about ready-made variable sets for agents and servers — on the Environments page.

← Back to documentation