AI Agents for Business: Platform, Components, Channels

Introduction

AI agents are not just chatbots that respond according to a script. They are intelligent systems that understand context, connect to your databases and documents, call APIs, and make decisions. For business, this means: less routine, faster responses, lower costs, higher quality.

We identify four types of agents that cover the key needs of any company:

But behind each of these agents is a common platform — and it is precisely this platform that determines whether the agent will be convenient, secure, and manageable. In this document, we break down the platform's business components and delivery channels.

Business Components of the Platform

1. Dialogue Analytics

Without analytics, an agent is a black box. Businesses need to understand what is happening inside.

What analytics provides:

Analytics is opt-in: by default, no agent is tracked; it is enabled globally or for a specific template.

Example of what this might look like (numbers are illustrative):

📊 Dashboard for July 2026
├─ Total dialogues: 8,230
│  ├─ Resolved by agent: 5,760 (70%)
│  ├─ Escalated: 1,810 (22%)
│  └─ Not resolved (not in the database): 660 (8%) ⚠️
├─ Top 5 topics:
│  1. Order status — 2,140
│  2. Return/defect — 1,520
│  3. Delivery to regions — 980
│  4. Product comparison — 890
│  5. Warranty — 720
├─ Average response time: 1.2 sec
└─ Average user rating: 4.7 / 5

2. Security

An AI agent works with company data — documents, the customer database, financial information. Security is not an option, but a foundation.

Levels of protection:

Example: how personal data masking works

User: My passport is 4512 345678, check the order
Agent (sees):  My passport [PASSPORT_MASKED], check the order
In the logs:   [PASSPORT_MASKED] — the original data is not
               stored, only the fact that personal data was detected

3. Knowledge Base and Data

An agent is only as good as its knowledge is up to date. Sources are divided into two types: a search archive and live data through tools.

How the agent acquires knowledge:

Updating. The archive is rebuilt by the crawler — manually, by script, or via cron. There is no automatic indexing of documents (Confluence, Google Docs, 1C) and no versioning of the knowledge base.

4. Quality control

The agent must not just answer, but answer well. Quality is maintained by controllable mechanisms.

5. Integration layer

The agent does not exist in a vacuum — it connects to the company's IT landscape.

Built-in integrations:

Planned: 1C/ERP, amoCRM/Bitrix24, Active Directory/LDAP, ClickHouse, Jira/Kaiten/Notion, payment gateways (YuKassa, etc.), delivery services (CDEK, PEK, Russian Post), WhatsApp Business API. They do not yet have native support — some are achievable only via arbitrary HTTP through site_tool.

Delivery channels

The agent must be where the user is. It is not the user who goes to the agent, but the agent who goes to the user.

1. Website widget

The most obvious channel for external clients.

Placement example:

University website
├─ Home — widget with an offer: "I will answer questions
│  about admissions, schedules and student life"
├─ Admissions campaign page — the widget automatically suggests:
│  "Would you like to know the passing score for your faculty?"
└─ Student personal account — widget in context: "Need a certificate
   of enrollment? I can help you arrange it"

2. Telegram bot

The most popular channel in Russia for internal communications and support.

Scenario for manufacturing (a production company):

A shop-floor employee opens Telegram on a smartphone → @CompanyHelperBot
→ "Request time off" → one button → done.

No need to: find a computer, log into 1C, remember a password,
figure out the interface.

3. VK, Yandex Messenger, email and API

Besides the widget and Telegram, the agent connects to other channels:

Channel comparison

Additionally: the result of an observer agent's work goes to a sink — webhook, Telegram, VK, Yandex Messenger, email, another agent, or storage (S3/WebDAV/FTP).

Architecture: how it works

flowchart TB
    subgraph channels["📱 CHANNELS"]
        Widget["Website widget"]
        Messengers["Telegram · VK · Yandex"]
        Api["HTTP API (SSE)"]
        Email["Email"]
    end

    subgraph triggers["⏰ TRIGGERS — launch without a human"]
        Cron["Cron"]
        Webhook["Webhook"]
        Monitor["Monitor (RSS, etc.)"]
    end

    Host["🌐 Host — HTTP server<br/>authentication · admin UI"]

    subgraph kernel["🧠 CORE — operating system for agents"]
        direction TB
        Sched["Scheduler<br/>concurrency and queue"]
        Processes["Process table<br/>agent = process (PID, state)"]
        Ctx["Context (RAM analog)<br/>eviction and compaction"]
        Budg["Budgets (cgroups analog)<br/>token bucket · groups"]
        Hooks["Lifecycle hooks<br/>guard · rag · memory · cache"]
        Ipc["IPC and system calls<br/>spawn · fork · send/recv"]
    end

    subgraph providers["⚙️ INFERENCE (CPU analog)"]
        Router["Model routing<br/>and inference cache"]
        Llm["LLM<br/>OpenAI-compatible · DeepSeek · Ollama"]
    end

    subgraph tools["🔧 TOOLS (I/O devices analog)"]
        Web["Network · websites · browser"]
        Know["Search archive (BM25) · PDF · documents"]
        Db["SQL · DuckDB · files"]
        Act["Scripts · subagents · email · S3"]
    end

    subgraph store["💾 STORAGES"]
        Transcripts["Dialogue transcripts"]
        Events["Event log (audit)"]
        State["State store"]
    end

    subgraph modules["🧩 MODULES — features on top of the core"]
        Wf["Workflow (DAG)"]
        Analytics["📊 Dialogue analytics"]
        Approvals["Approvals · escalation"]
        Connectors["Connectors (OAuth)"]
    end

    Widget --> Host
    Messengers --> Host
    Api --> Host
    Email --> Host
    Cron --> Host
    Webhook --> Host
    Monitor --> Host
    Host --> Sched
    Sched --> Processes
    Processes --> Ctx
    Processes --> Budg
    Processes --> Hooks
    Processes --> Ipc
    Hooks --> Router
    Router --> Llm
    Processes --> Web
    Processes --> Know
    Processes --> Db
    Processes --> Act
    Processes --> Transcripts
    Processes --> Events
    Processes --> State
    Events -.-> Analytics
    Hooks -.-> Approvals
    Ipc -.-> Wf
    Act -.-> Connectors

Key principles:

• An agent is a process. Each agent runs as an independent process with its own PID, context, set of tools, and budget. An agent template (agent.yaml) is a recipe; the process is created lazily, on the first request. Workflows and subagents are also processes, with spawn/fork semantics.
• The core is order. A single asynchronous runtime schedules all processes, maintains the concurrency limit, and distributes budgets (token bucket, groups per user and session). The core mediates every tool call: validates arguments, enforces time limits, logs, and calculates cost.
• The model is a replaceable processor. The core does not perform inference itself but schedules it on a pluggable provider (OpenAI-compatible API, DeepSeek, Ollama). Model routing selects the model for the request, and the inference cache eliminates repeated calls.
• Controllability through hooks. Hooks intercept the lifecycle at points "before/after a message, tool call, inference, token stream, context compaction." This is where DLP and PII masking (guard, pseudonymize), answer grounding (groundedness), memory (memory), RAG (rag), caches (faq_cache, tool_cache), and loop breaking (loop_guard) live.
• Modularity. The core is only a mechanism; features (workflow, cron, channels, analytics, connectors, memory, model routing, documentation) are separate modules connected to the core through a single service seam. A disabled subsystem responds "not configured" rather than breaking the platform.
• Autonomy through triggers. An agent is launched not only by a message: cron — on a schedule, webhook — by an external push, monitor — when new data appears (RSS). The result goes to a sink: webhook, Telegram, email, another agent.
• Control and isolation. An agent does not read someone else's context or spend someone else's budget. All steps are written to transcripts and an event log (audit). The working knowledge base is a BM25 search archive; access to external databases and systems is only through tools, with configurable read-only mode and confirmation.

Conclusion

AI agents for business are not magic and not hype. They are an engineering solution that stitches together three things:

1. Model — a large language model that understands natural language.
2. Company data — documents, databases, regulations, product catalog.
3. Channels — website, Telegram, VK, Yandex Messenger, email — wherever the user is.

The result: employees and customers get an answer in seconds, the business saves millions, and analysts finally do analytics instead of exports.

And all of this — with payback starting from a week.