Xedant MultiAgent

Agent factories on your servers: deployment, chats, analytics and order — from one window

Connects and manages any number of Linux servers over SSH — one connection per machine, as many factories on it as you like

Docker is installed and configured on your servers automatically

An agent is one click to run: provision, start, stop, restart

Agents already running on a machine can be connected without a reinstall

You can also work on your own computer: the server is a local WSL distribution, with no passwords or keys

Addresses and ports are assigned automatically — no conflicts

Every factory gets its own deployment slug: several factories on one machine never get in each other’s way

A shared Postgres database serves every agent on the factory

A built-in Git code repository with automatic sync

One login for the whole factory: sign in once and open every protected agent and product — the session lasts 90 days

Factory checkup: a Check and fix checklist that repairs what it finds in one click

All the factory’s not-yet-deployed agents come up with a single “Deploy” action

An agent can be moved to another factory together with its data and database — or erased without a trace

The factory home page can be opened from a phone with a QR code — no password to type

Every chat of every agent in one window

Tasks: long jobs queue up — with a live log and a stop button

Management: a control room for dozens of agents — eight screens, from Analytics to Incidents

Analytics across all agents in one place

Chat statistics can also be archived to ClickHouse for long-term storage

Prompt queue, scheduled tasks, bots, MCP and skills — right in the agent chats

Skill catalog: store ready-made skills and upload them to the agents that need them

Environment sets: define a set of variables once and upload it to as many agents and factories as you like

Own Agent: your own assistant with a chat panel on every page

Balances and limits of your AI provider accounts, all in one place

A library of ready-made services you can install on any factory from a template

Every app on one domain: each gets its own subfolder, and the factory gets a home page

Agent API: let other agents run the system for you — with an access key

English interface (Russian can be enabled) and one time zone for the whole system — every date, chart and report shows in it

Passwords and access keys are stored encrypted

New agent, app and service ports are closed to the internet — they open to the outside only when you choose

Agent licenses are issued and extended right in the interface — no separate tools needed

Live updates — no page reloading needed

Factory files in the browser: two panels, copy between factories, built-in terminal

Backups: daily dumps on the factory and ready-made scripts that pull seven modules to your machine

Everything runs on your servers — no external clouds

Dark and light themes, comfortable on a phone

Product catalog: eleven ready-made apps — from research and analytics to interface testing and news — each with its own agent

Secure HTTPS connection: self-signed, custom or Let’s Encrypt certificates — requesting a certificate also enables the secure port, and all traffic moves to HTTPS

Managing factories

Factories: connecting a server over SSH and the onboarding checks (captured before the servers-to-factories rename)

Add a factory in a minute: pick the server, name the factory, keep the suggested slug

All required software installs and configures itself

Factory checkup — a Check and fix checklist: access, software, folders, certificates, databases, backups; anything missing is repaired in one click

Shared projects and data folders for all agents on the factory

App addresses and certificates are set from the interface — no manual edits on the machine

The factory’s home page is a static board with app cards at the root — in the brand’s language

Central login (the Authorization tab): one login for every protected app on the factory — Forgejo joins by itself

Fleets narrow everything at once: the section lists, notifications and sounds — and a fleet can be assigned to a whole factory

Deploying agents

Deploying agents: an agent card and settings preview

Creating an agent is simple: pick the factory and the app, answer a few questions

Full lifecycle control: provision, start, stop, restart or remove

You see exactly what will be installed before anything runs — with validation

Live agent load (CPU, memory, occupied space), logs and the connection test right from the interface

Ready products (Research, Analytics, Data, Proxy) install together with their agent — from the same dialog

Updates run without downtime: MultiAgent waits for a quiet moment in the chats and restarts the agent on the new version itself

All the factory’s not-yet-deployed agents and apps come up with a single “Deploy” action

Moving an agent to another factory together with its folders and database — or erasing it completely

Centralized chats

Centralized chats of all agents in a single list

Every chat of every agent in one filterable list

Send messages and read replies without logging into each agent

Per-message stats: tokens, cost and speed

Everything updates in real time

Prompt queue, scheduled tasks, bots, MCP servers and skills — without leaving the chat

A chat’s label is chosen right in its title row — no digging through settings

Tasks: the queue of jobs across all factories

Jobs of one server run one at a time and do not get in each other’s way

Fleet-wide jobs run on their own lane and do not wait for routine tasks

A live log and a week of history — you can see what was done and when

Any task can be stopped with one button

“Check and fix”, the terminal and file copying run right away and do not queue

Management: a control room for dozens of agents

Seven agent states: busy, thinking, idle, waiting for a decision, stuck, offline and unknown

Decision queue: response deadlines, only identical repeats merged, a “Dismiss” action and the decision journal

Eight screens in work order: Analytics, Tokens, Cost, Hardware, Agents, Chats, Decisions and Incidents

Incident mode, fleet freeze, hotkeys and the command palette

Notifications only when attention is needed: an agent silent for 5 minutes notifies once; rules per kind — immediately, batched or off

Fleets: named groups of agents from any factories — with their own icon and a drag order you set

Three independent alarm chips: down agents, pending decisions, active chats — each opens its own screen

The Hardware screen: live CPU, memory and disk of every machine, refreshed every 15 seconds

A queue row opens the chat where the decision is needed, and a question answered in the chat closes itself

The Fleet screen shows what is running right now: agent and factory, the chat’s name, how long it has been going, tokens and cost — a row opens that chat’s step-by-step trace, and when nothing runs there is no list at all

The attention zone holds only what waits for a human: questions and checks. Informational notices do not fill it — a queue of notifications alone does not read as a mountain of work

Incidents: where the infrastructure slipped

One posture score for the whole fleet — 0 to 100, recomputed by every findings sweep

Findings with numbers: what exactly lowered the score, and by how many points

The score’s own history: every material move logged with its delta and a sparkline

Incident mode: switched on by hand, or by itself when agents go offline

Tokens: spend and forecast

One number per entity — a chat’s total is input + output + cache read + cache write, never a per-category split

The first tile answers with yesterday; then rolling 7- and 30-day windows and a next-30-days forecast labelled as one — large numbers abbreviated

Daily charts stacked by agent, by model and by skill

Attribution by agent, model, factory and skill, with chat counts

Aggregates-only export — keys, tokens, shares and counts, never a prompt or message text

Policies: the autonomy rules

Autonomy ladder: suggest, confirm or act on its own

Confidence thresholds: above the top one the agent acts by itself, below the bottom one a human decides

A gap of at least 0.1 between the thresholds keeps the system from dithering on the border

Rules are set for the whole fleet, for a class of actions or for a single agent

Threshold history records how often decisions go to a human

Your own assistant (Own Agent)

Connect once — the agent’s address and key are set at startup; the key never reaches the browser

A chat panel and a sidebar block on every page: message box, models and skills, a live chat summary, and the “Tasks (N)” and “Chats” buttons in the footer

Prompt queue with auto-send, voice input and chat sounds

Scheduled work, bots and prompts in chats

Scheduled work, messenger bots and external services — all from the agent’s page, no window switching

Prepare prompts ahead of time — the agent sends them itself, one by one, or on your command

Skills, external services and tasks live with the agent — and secrets are write-only: a saved key is never shown again

Agent API — automation from other agents

Access only with the secret X-API-Key you issue

The helper discovers the available commands by itself — no separate manual needed

Every operation is visible in the interface — the journal, the tasks and their logs

Product catalog

MultiAgent (6000), Research (6010), Analytics (6020), Data (6030), Proxy (6040), Chatbot (6050), Telegram (6060), Test (6070), CRM (6080), News (6090), Portal (6100)

Credentials are generated automatically, and the app and the agent know about each other from the start

The shared database and shared folders (documents, scripts) are configured automatically

Centralized analytics

Centralized analytics across all agents

Every chat of every agent flows into one database

Charts for cost, tokens, messages and commits

Narrow the report by one agent, by labels (any of), by the fleet in the header and by dates — the presets follow the interface time zone

See when your agents are most active

Optionally, chat statistics also go to a ClickHouse archive for long-term storage

Ranges from hours to months, and same-named agents on different factories are shown as separate lines

Metrics and GraphQL: the same numbers in your systems

The report is open not only to eyes, but to programs

The panel is built for a human, but a fleet is often maintained with familiar tools: drawing your own graphs, setting an alert for “daily spend above normal”, stacking the history next to the other server metrics. That is why MultiAgent has two machine addresses carrying the same numbers as the Analytics screen — the charts and summaries are computed by the same code, so the panel and the external series cannot disagree.

The first address serves metrics in a format Prometheus and compatible systems understand: every row is labelled with its agent and factory, and the fleet summaries come as separate rows — you see both a single agent and the whole park. The second is the GraphQL query language: one request returns a ready-made report with all the cuts, and the schema description sits next to it, so a third-party app can assemble its query itself.

Both addresses are off by default and open with a separate name-and-password pair, not connected to the panel login. The collector is not left out either: the Prometheus service from the tool library installs on the factory with one click and immediately starts collecting the metrics of that factory’s app — there is nothing to write in by hand.

The /metrics address serves the same charts as the analytics screen as time series — every row labelled with its agent and factory, and the fleet summaries coming as separate rows

Beside the charts — live numbers: whether an agent is up, how many chats are running right now, how many agents sit on each server and in each fleet

The /graphql address returns the same report for third-party apps: the schema description lives at /graphql/schema, and nothing can be changed through it — read only

Both addresses stay silent until a name and a password are set — a separate pair, the panel login is never used for machine access; the password can be stored as a fingerprint instead of plaintext

The step of a point and the depth of history are settings: from hours to months, thirty days by default

Collecting is cheap: however many times a second you ask, the database is read at most once in 15 seconds — and the panel itself does not slow down

A Prometheus service from the tool library installs on the factory with one click and starts collecting the metrics of that factory’s app — the credentials are written in by themselves

Tracking AI provider accounts

AI provider accounts: quotas and balances

All your AI provider accounts in one list

Balances and limits update in real time

Sign in to a Codex account right from the interface

Spending analytics per provider and per account

Tools and services

The tool library and deploying services (captured before the servers-to-factories rename)

A library of ready-made services for your tasks

A service installs on any factory, with settings entered step by step

Settings can be text, secrets, numbers or choices

Full control over the running services

The library has a Prometheus service: it collects the metrics of that factory’s app with no manual setup, opens under its own subfolder of the domain and receives access to the metrics by itself — no address and password to type in by hand

Every app on one domain

One domain per factory: every agent, product and tool gets its own subfolder, and a summary of all apps sits at the root

It configures itself: deploy an agent or a service and its subfolder appears

Five kinds of routes: agents and products, tools with a web interface, agents’ extra links, custom routes to any address, and the central login’s own route

Certificates: self-signed, your own, or Let’s Encrypt — requesting one enables the secure port itself

Apps talk over the internal network; a fallen service only takes down its own subfolder

Security and backups

Security: encrypted secrets and backups

Passwords and access keys are stored encrypted

The programmatic API and your own assistant turn on only with a secret key — off by default

New agents and apps are not visible from the outside: their ports open only when you choose, and only the web server and the backup receiver face the world

Agent licenses are issued right in the interface when the signing key is on the host — no third-party tools needed

Backups are pulled by your machines: seven read-only modules and ready-made scripts in the Backup tab

A licence renews itself: a few hours before the term ends the key is rebuilt for another 31 days, and the agents holding it are recreated without interrupting the running chat — the toggle is on by default, and a perpetual licence has none

The Backup page in the Assets section hands out one client for all the factories of the chosen fleet at once: each factory lands in its own folder, and a factory without a server address is honestly named as skipped

There are three clients: a script for Linux, an archive for Windows and a file for Docker — the last one installs with a single command in an empty folder and then takes the copies by itself, every day on its own schedule

Secrets never echo back: a stored password or key is visible only as a flag, never as a value

Handing a factory over to the client

The client becomes the owner of their own MultiAgent

If the factory belongs to your client, it makes sense to hand over the controls too. The handover is a one-time operation: it moves the records from your central instance to the client’s own MultiAgent — agents, apps, tools, routes and access keys. Running apps are untouched: nothing stops and nothing gets reinstalled.

Before you run it, you can see exactly what will move and what stays; if anything fails on your side, nothing changes — you can simply repeat the operation. Secrets travel directly between the two instances over a secure channel and never appear in the interface or the logs. Afterwards the routes belong to the client’s instance, while the factory row, its own MultiAgent and machine access stay with you: SSH access, checks, folders and Docker cleanup. You can look into the client’s instance with the Manage button — it signs you in automatically, no password needed.

A one-time, verifiable operation: success means every record has landed

Secrets travel only over the machine channel — they never reach the browser or logs

The Manage button opens the client’s instance already signed in