Products – Xedant

Products are ready-made agent applications you can deploy from the catalog in a few clicks: MultiAgent, the Research Agent, Analytics Agent, Data Agent and Proxy Agent, plus apps for chatbots, Telegram, interface testing, customer relationships, news and the company portal. A product installs from the “New Agent” dialog together with a linked agent — credentials are generated for you, variables are filled in ahead of time, and the app and the agent learn about each other on their own. No writing config files by hand, no passing keys around.

What a product is

A product is a template folder in the products catalog (by default /project/products; point it elsewhere with the AGENT_PRODUCTS environment variable). The folder holds a product.json description file (name, description, icon, variable schema), a compose.yml application config template — the file Docker reads to start containers — supporting files, and optionally your own logo (logo.svg/logo.png). The catalog is re-read every time it is shown: adding a product means dropping a template folder into the catalog, no restart needed. A damaged description file does not break the catalog — that template simply shows up with a fallback identity.

Installing with a linked agent

Products deploy from the “New Agent” dialog: the type toggle offers a card for a stand-alone agent and a card for every product in the catalog. The cards are labeled with short names, like the apps themselves: “Analytics”, “Data”, “Proxy”, “Research”, “Chatbot”, “Telegram”, “Test”, “News”, “Portal”; CRM and MultiAgent have no short name and show as they are. The dialog collects the name, server, image, port (pre-filled from the template) and the variable values. An agent-type variable (Linked agent) defaults to the server’s first stand-alone agent — reusing an agent that already works is cheaper than creating a second one. If the server has no agents yet, the dialog offers Create new agent, and the wizard builds a full stand-alone agent exactly like a regular one. Either way, the application receives the linked agent’s address and key so the two can talk.

A deployment creates two records: one for the application (a slug like {template}-app or the declared appSlug) and, when a linked agent was created, one more for the agent — with the template’s own name and slug. Both names get a free variant (“Research App 2”, research-app-2) if already taken on the server. Credentials (user login, passwords, secrets, API keys) are generated by the server — you need to know nothing in advance to install.

A new application is created with a closed port: from the outside it is open only through the server’s subfolder. Direct host:port addresses are set up on the “Ports” tab: every binding has its own “Public port” switch. While it is off, the port is reachable only inside the server — at the 127.0.0.1 address, that is, through nginx and from the server itself; a switched-on port is published on all network interfaces. Binding rows can be added and removed (a new row appears with a closed port), and changes take effect on the next recreation of the application. The install wizard assembles the same bindings in advance, with the same switches, so nothing needs finishing after deployment.

The product catalog

MultiAgent (port 6000) — MultiAgent itself as a product: the default linked agent and the variables for the own agent, your built-in assistant;
Research Agent (port 6010) — research and planning; a shared documents folder /project/apps/research and the shared Postgres database, when the server has one configured;
Analytics Agent (port 6020) — data analysis and visualization, with a linked agent for editing with AI;
Data Agent (port 6030) — data preparation: the linked agent writes the scripts, the app runs them on a schedule; the data lakehouse lives in a shared folder both sides see, plus Postgres when the server has one configured;
Proxy Agent (port 6040) — a single entry point to AI models with its own database;
Chatbot Agent (port 6050) — messenger bots with a linked agent;
Telegram Agent (port 6060) — Telegram work: channels, publishing, analytics;
Test Agent (port 6070) — interface testing: rule checks, scheduled runs, issue tracking and auto-fix through the linked agent;
CRM Agent (port 6080) — customers and deals;
News Agent (port 6090) — a news platform: watching sources, collecting and processing news, alerts, digests and publishing;
Portal Agent (port 6100) — a company portal builder: the linked agent assembles and maintains the pages and publishes them on a public site.

A template announces its capabilities in its description file: sslEnvVar — self-signed HTTPS support (only such templates get the SSL toggle), databaseEnvVar — the connection string for the server’s shared Postgres database, when one is configured (otherwise the app runs perfectly well on its built-in database).

The application ↔ agent link

When a template declares application address and key variables (for the research agent these are RESEARCH_APP_URL/RESEARCH_APP_KEY, for the analytics agent ANALYTICS_APP_URL/ANALYTICS_APP_KEY), every linked agent receives two derived lines in its configuration: the application’s address for container-to-container calls (a Docker network address within one server, a public address across servers) and the application’s public incoming key. The lines are written when the configuration is built and regenerated on every deployment. Several applications can link to the same agent — the values are then joined with commas (addresses and keys as parallel lists).

The multiagent template declares its own linked agent: the own agent’s variables (outgoing) and its key (as a fingerprint) are written into its configuration, and the linked agent receives MultiAgent’s address and public key. Details on the Own Agent page.

The Proxy Agent’s link works the same way: the deployed application accepts machine calls — its program interface is enabled by a key fingerprint — and the linked agent receives the application’s address and the key itself, so it works with it without manual setup.

App folders

An application and its linked agent share folders: the same files sit in both containers at the same path. Thanks to that, the agent can dig into the app’s data, and the app into the agent’s.

Settings and documents — /project/apps/{folder}: the app’s working folder inside the linked agent’s repository. That is why documents land in the agent’s change history, and both containers see them at one path (for example, /project/apps/research). MultiAgent derives the folder name from the template name — you never specify it separately;
App data — /apps/{folder}: databases, files and everything the app creates itself. The linked agent sees the same path — it can check, fix or export that data;
Agent data — /data: the application sees the whole data folder of its linked agent. The Data Agent’s lakehouse lives in this same shared tree, so the results of its scripts are available to the agent too.

There are no shared folders when no agent is linked or the agent lives on another server: each side then works only with its own files.

Besides folders, the application’s manager skill is installed into the agent — a set of instructions that teaches the agent to manage this application. The skill always sits at the same path inside the agent, and the language follows the brand of the server the agent lives on: Pastukhov-brand servers get the Russian variant of the skill, Xedant-brand servers the English one. So the agent and the application speak the same language, and nothing needs switching by hand.

Managing products

A product is managed like a regular agent record with a “Product” badge: the full lifecycle (recreating pulls a fresh image — there is no separate “download image” command), logs across the whole configuration (they cover every service in the stack), and an Nginx route. Variables and the linked agent are edited on the “Product” tab (the “Save & Recreate” button applies the changes; the link can be re-aimed at another agent, a new agent created, or switched off by choosing “None”). A product does not work as a regular agent: it has no live chat-channel connection or chat mirroring, and the “Check API” button replies that testing is not supported for products — the app has API commands of its own.

On the app’s “Environment” tab you can set your own KEY=value lines. The values stack in order: first the line from the template, then the server’s shared variables for all agents and apps, and last your lines for this record. The last one wins, so a single record can override a shared setting without touching the rest.

Every template passes the assigned license key to the app in the AGENT_LICENSE variable — same as with a regular agent. The app’s image is picked by the server’s brand: on a Pastukhov-brand server the Russian build is deployed and starts in Russian right away, even when MultiAgent itself runs under a different brand.

The “MultiAgent” product is a special case: when it is deployed on a server that belongs to a client, server management can be handed over to that instance. How that works is described in Server Handover.

← Back to documentation