--- title: "Products" id: "1724" type: "page" slug: "products" published_at: "2026-09-20T20:36:27+00:00" modified_at: "2026-09-21T01:36:28+00:00" url: "https://xedant.com/agents/multiagent/docs/products" markdown_url: "https://xedant.com/agents/multiagent/docs/products.md" excerpt: "Products are ready-made agent applications you can deploy from the catalog in a few clicks:…" --- # Products [https://xedant.com/agents/multiagent/docs/products.md](https://xedant.com/agents/multiagent/docs/products.md) **Products** are ready-made agent applications you can deploy from the catalog in a few clicks: MultiAgent, Research Agent, Analytics Agent, Data Agent, Proxy Agent, plus apps for chatbots, CRM, Telegram and interfaces. 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 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. ## 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/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 work: a shared scripts folder `/project/data` and Postgres; - **Proxy Agent** (port 6040) — a lightweight proxy with its own database; - **Chatbot Agent** (port 6050) — messenger bots with a linked agent; - **Telegram Agent** (port 6060) — Telegram work: channels, publishing, analytics; - **UI Agent** (port 6070) — generating and editing interfaces; - **CRM Agent** (port 6080) — customers and deals. 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 research-agent these are `RESEARCH_AGENT_BASE_URL`/`RESEARCH_AGENT_API_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](/agents/multiagent/docs/own-agent) page. ## The shared documents folder Any template with a linked agent shares that agent’s git-managed documents folder: on the server side it is a subfolder of the agent’s repository, mounted into the application at the same path inside the container. Both containers see the same files at the same absolute path, and the agent’s git covers the shared documents too. MultiAgent derives the folder name from the template name — you never specify it separately (for example, `research` for Research Agent). There is no shared folder when no agent is linked or the agent lives on another server. ## 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 API check replies that testing is not supported for products. 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](/agents/multiagent/docs/handover) . [← Back to documentation](/agents/multiagent/docs)