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 is built around the root Fleet screen and the eight items of its list. The order follows an ordinary day: first see what is happening, then count the spend and the state of the machines, then deal with people, work and incidents — Analytics, Tokens, Cost, Hardware, Agents, Chats, Decisions, Incidents. Fleets and Policies moved to Assets: that is configuration, not daily work, and their place is next to “Servers”. Any screen 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;
Analytics — summary charts over all agents at once: how many chats, tokens and money go per day and per hour, and who spent how much. Narrowing — by one agent, by labels, by the chosen fleet and by dates. All charts look alike, and dates and reports are shown in the chosen time zone. Details — on the Analytics page;
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. Windows over the last 7 and 30 days, a 30-day forecast and the breakdown by agent, model, factory and skill. Details — in the “Tokens and cost” section below;
Cost — what the work costs: yesterday’s spend, windows over 7 and 30 days, a 30-day forecast, a traffic light over the model-provider accounts, spend ceilings and the same breakdown. Every finished chat counts once — the split into “successful” and “unsuccessful” is gone. Details — below;
Hardware — what happens on the machines themselves: the share of CPU and memory, disk space used, average load and uptime. The numbers refresh every 15 seconds, and every machine has a page of its own with charts and details. Details — on the Hardware page;
Agents — 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 factory, owner, tags, kind 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 “Factory” and “Agent” columns are separate and clickable: the factory 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;
Incidents — 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.

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 factory is added to the name — “factory/agent” — so that two rows with the same name never look identical. Where the factory is already shown as its own column or a group heading, the name stays short. In the “Agents” list there is no separate “Factory” column at all — the factory stands right in the name.

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.

What is running right now

Between the number tiles and the attention zone on the “Fleet” screen lives the list of chats being processed at this very second. One row is one chat, however many chats a single agent runs: you can see which agent and which factory the work runs on, what the chat is called, how long it has already been going, and how many tokens and money it has spent. A click on a row opens that chat’s step-by-step breakdown — the trace, as the “Chats” screen calls it. The list runs from newest to oldest and is cut off at ten rows: past that, a link leads to the “Chats” screen already filtered to running. When nothing runs, there is no list at all — no empty frame, no “0 active”.

The list does not wait for a timer: a chat that has finished or failed leaves it at once, and a chat that has just started appears within seconds — as soon as its record reaches the shared database. The same set of chats is what the green mark in the header counts and what the “Running now” tile shows: one and the same set, not the number of busy agents.

The attention zone below holds only what is really waiting for a human: agents’ questions and checks of finished work. Informational notifications — about a quota, about spend growth, about small deviations — do not fill it: they live in the notification centre and in the notifications tab of the “Decisions” screen. That is why the attention zone never looks like a mountain of work that is not actually there, and the bottom of the screen separately shows how long the oldest waiting question has been standing.

Fleets and the fleet filter

A fleet is a named group of agents that work together. Members of one fleet can stand on different machines and in different factories, and to the system a fleet is a way to narrow everything you see down to one team at once.

A fleet has an icon of its own: a click on it opens the shared icon gallery — the same one agents and chat labels use;
Fleets can be put in the order you need by dragging. That order shows both in the fleet list and in the filter in the header;
Fleet cards are collapsed by default — one row per fleet on the screen, with its name and the edit buttons. The name is the toggle: a click unfolds the card, another click folds it back;
A fleet can be assigned to a factory: the assignment adds all of its agents and apps to the fleet, and everything that appears there later is created inside the fleet already. Removing the assignment removes nobody — it only stops adding new ones.

The fleet chosen in the header narrows a lot at once: the sidebar’s section list, the “Servers” list, the “Hardware” screen, the notification panel and counter, and even the operating system’s sound and popup. While a fleet is chosen, you will not be told about someone else’s agent. Rows without an agent — about an account’s quota, say, or an incident that has started — always come through. Returning the filter to “All” shows you the whole picture again.

The status line in the header

The header holds three independent chips — one per kind of event. They never merge into one phrase: a click on one does not repeat a click on the other, and each has its own text. The chips’ words are shown in the operator’s language, not in the factory’s.

The red “Agents unavailable: N” — while the fleet is calm it is not there at all. It lights up when agents do not answer or are stuck; when there is some of both, the number of unavailable ones is named first. A click opens the “Fleet” screen — that is where this trouble is sorted out;
The yellow “N decisions waiting” — also disappears when there is nothing to wait for. It counts decisions, not agents: one agent with three questions gives “3”. A click opens “Decisions”;
The green “N active chats” — appears only when at least one chat is really running. It counts chats, not busy agents: an agent running three chats at once gives three, not one. At zero there is no chip at all — instead of “0 active chats” nothing is shown. 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. When everything is calm and no chip shows, the “Fleet” screen itself says “Fleet is healthy” — so the absence of trouble is said in words, not left to emptiness.

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 machine 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.

Apps are a different kind: they notify about themselves and land in the journal, but they do not count as agents. They appear in none of the fleet’s states, counters, agent lists or incidents: an app can be stopped while the fleet still counts as calm.

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.

State dots refresh by themselves, without a page reload: the list is re-read on every reconnect, and a background check runs every 10 seconds.

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, and the check repeats every 30 seconds, so a cleared question does not stay in the queue longer than that.

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 — a row in the journal or a mark on its own screen — and does not turn into a message. Nothing is sent on a schedule: no notification is created by the clock, only by an event.

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, and the chosen fleet narrows both the list and the counter: while a fleet is chosen, other people’s rows do not reach the panel;
a popup and a sound — only for blocking decisions and missed deadlines, and only when the tab is not in view. They follow the chosen fleet too. The same sound is never played twice, even with several tabs open, and a sound turned off in one tab does not take it away from another;
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.

Every kind of event has a rule picked from three: “immediately”, “batched” and “off”. A batch arrives as one message, not a stream. A loss notification comes once and only when an agent or an app has been silent for five minutes in a row: a short glitch will not trouble you, but it is visible in the journal at once. Apps have their own separate loss rule — they can be turned off without touching the agents. Drift, spend spikes and auto-recovery create no notifications at all: they stay in the journal and on their screens.

There are quiet hours (23:00 to 08:00 in the system’s time zone 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 moved to the batch 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.

Tokens and cost

Tokens and money are counted from the same records — from chats. Both screens answer three questions: how much went out yesterday, how much is going out now, and how much will go out if nothing changes.

The windows are rolling: “over 7 days” and “over 30 days” mean the last seven and thirty days together with today, not a calendar week and month. The forecast always looks 30 days ahead and is labeled as a forecast. The first tile on both screens answers about yesterday: on “Cost” it is yesterday’s spend, on “Tokens” the tokens of yesterday. When there was no work yesterday, an honest zero stands there — not a dash.

Big numbers are abbreviated: “1.2M” instead of “1,200,000”. On “Tokens” there is one number per entity: input, output and temporary-store reads and writes add up together and are never split by kind.

The breakdown is the same on both screens — by agent, model, factory and skill. Every finished chat counts once: the split into “successful” and “unsuccessful” is gone, and so is the “Tokens by tasks per week” row. At the bottom there is a one-file table export: the keys, the sums, the shares and the number of chats — not a single line of conversation.

The charts on “Cost” are the same charts as on “Tokens”, only in money: three tabs — by agent, by model and by skill. All the tooltips are one size, their rows run from largest to smallest, empty rows are hidden, and the legend scrolls when there are many lines.

Here too — the traffic light over the model-provider accounts (how much is left against the limit, what the money balance is and how many days it will last) and the spend ceilings: per run, per agent per day and per run’s total tokens. When a ceiling is crossed, the chosen behavior fires — stop the work, just notify, or ask for confirmation.

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 — with a small delay, 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. Subagent rows update right after their spend, so the fleet’s totals match the agents’ own numbers;
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. 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 has a subtlety: a chat’s whole cost belongs to its current model, so changing the model mid-run moves the entire row. The Cost screen says so outright;
The time zone is set once — in the “Appearance” window, next to the language. It is one for the whole system: every date, chart and report is shown in it, while the data is stored in UTC. The programmatic Agent API does not change;
The tab reconnects itself. After a server-side update an open tab re-connects every 3 seconds and does not give up while you are signed in;
A started chat is visible at once. A chat’s row appears in the list as soon as the chat is recorded — there is no need to wait for the next event — and subagent spend reconciles within seconds, not once an hour.

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

← Back to documentation