Enterprise AI Assistant

A production AI agent that gives employees role-aware access to 1C data and business operations through natural language without giving the model unrestricted access to the ERP.

Production2026

Contents

Summary

Employees use the assistant through Telegram to retrieve business data, investigate operational issues and prepare supported actions in 1C. Access depends on the user’s enterprise role and permissions; the model never receives unrestricted ERP access.

The engineering problem is not merely understanding a natural-language question. It is carrying a request from conversation to a useful enterprise result while preserving the controls of the underlying business system.

My role

I designed and built the path connecting Telegram, LangGraph, controlled MCP/business tools and 1C. The implementation covers user mapping, permission and parameter checks, human confirmation for consequential operations, tracing and audit context.

What works

natural-language access to supported business analytics and operational data;
role-aware execution in the context of an identified enterprise user;
explicit business tools instead of arbitrary database or ERP operations;
controlled preparation and confirmation of supported consequential actions;
tracing across agent, tool, integration and 1C execution steps.

Outcome

Users can ask ordinary business questions without knowing which report, register or internal 1C structure contains the answer. The system returns structured results while retaining explicit access and execution boundaries.

The system is used in production for internal business workflows.

Architecture

01User

02Telegram

03Identity mappingTelegram user → enterprise / 1C user

04Agent orchestrationLangGraph

05Tool selection

06Authorization + parameter validation

07MCP / controlled business tools

081C / ERP

Structured resultTraces / audit context

Controlled request path from user identity to enterprise execution.

The LLM interprets intent and selects from explicit capabilities. Deterministic application code validates the current user, permissions and tool parameters before execution reaches 1C.

Representative request flow

“Who owes us?”

The assistant returns a table of all debtors.

Another request example: “Who owes us the most?”

Natural-language request
  → Telegram user
  → enterprise / 1C user and role
  → agent interprets intent
  → accounts-receivable tool selected
  → permissions and parameters validated
  → 1C executes the business query
  → structured result
  → business-oriented response and audit context

The user sees a concise answer; the application keeps the underlying business boundary intact.

Example capabilities

The current tool set is expressed in business terms:

revenue for a selected period, top customers, accounts receivable and counterparty settlements;
inventory balances, business-document lookup and operational status checks;
reconciliation analysis, discrepancy investigation and gathering supporting documents;
failed exchanges, unsynchronized orders and integration error records;
preparation of a supported operation for user confirmation.

Who uses it

Owner / Director

Revenue, sales, receivables, customer ranking and settlement questions.

Example

Who owes us the most?

Production manager

Stock availability, materials, finished goods and inventory questions.

Example

How many units of this product are currently in stock?

Chief accountant

Reconciliation, document analysis, discrepancy investigation and supported accounting actions.

Example

There is a discrepancy with counterparty “Romashka” for Q3.

IT specialist

Exchange monitoring, synchronization errors and operational diagnostics.

Example

Which orders failed to synchronize during the last week?

Key engineering decisions

User and authorization stay outside model trust

Telegram users are mapped to enterprise users, and that mapping remains part of each tool call. Deterministic code—not the prompt—decides whether a capability is available and whether its inputs are valid.

The model selects business capabilities

The agent can select an accounts-receivable lookup, inventory check or integration diagnostic. It cannot invent unrestricted database operations. Narrow tools keep business semantics close to 1C and make inputs, outputs and failure boundaries explicit.

Risk determines the control level

Reading revenue or inventory is not equivalent to changing a business document. Supported operations with business consequences can be prepared by the assistant but require the applicable confirmation before 1C executes them.

Business semantics stay close to 1C

The integration layer returns structured business results rather than raw internal records. This keeps accounting and operational rules in the system that owns them, while the agent focuses on intent, tool selection and explaining the result.

Observability

Tracing connects the request, agent steps, selected tool, validation and 1C call. It distinguishes invalid parameters, denied operations, integration failures and errors returned by 1C, while preserving an execution record for important business actions.

Lessons learned

explicit business tools are safer and easier to maintain than raw ERP access;
user and permissions must remain attached to the operation, not only the chat session;
model quality does not replace deterministic validation and execution contracts;
read-only analysis and consequential actions need different control levels;
multi-step enterprise agents need tracing across every integration boundary.