# Agentic-пайплайны в enterprise: паттерны и антипаттерны

Когда агенты в корпоративных процессах оправданы, а когда хватит детерминированного workflow: архитектура, типовые провалы и чек-лист внедрения.

> For the index of this section of the site, see [llms.txt](https://anetlab.com/llms.txt)

19 октября 2026 г.10 мин чтения

# Agentic-пайплайны в enterprise: паттерны и антипаттерны

Когда агенты в корпоративных процессах оправданы, а когда хватит детерминированного workflow: архитектура, типовые провалы и чек-лист внедрения.

[Виктор Бузин](https://anetlab.com/about.md) · Founder & Principal Engineer, AnetLab

16+ лет в enterprise-разработке: .NET, AI/LLM-системы, RAG, MCP. Автор материала и практик в студии.

## Почему agentic workflows важны для enterprise

Agentic workflows объединяют reasoning LLM, выполнение tool calls, retrieval и policy controls, чтобы автоматизировать многошаговые задачи с меньшим участием человека. В enterprise это обычно означает переход от чат-ассистентов к системам, которые могут:

*   классифицировать и маршрутизировать запросы,
*   собирать контекст из корпоративных источников,
*   вызывать API и внутренние сервисы,
*   передавать задачу человеку при необходимости,
*   и формировать аудируемый результат.

На бумаге это выглядит просто, но внутри реальной организации появляются latency budgets, access control, compliance, change management, dependency sprawl и разная готовность к автономии. Поэтому архитектура должна оптимизировать в первую очередь надёжность, а уже потом новизну.

Полезная ментальная модель: enterprise agent — это не один prompt. Это workflow runtime. Модель — лишь один компонент в более широкой control plane.

Если спроектировать всё как «LLM плюс tools», почти неизбежно появятся такие проблемы, как:

*   неконтролируемый fan-out tool calls,
*   дублирующиеся действия,
*   drift контекста,
*   неконтролируемый cost,
*   и результаты, которым downstream-системы не могут доверять.

Ниже — паттерны, которые помогают сделать agentic workflows operationally sane.

* * *

## Практическая reference architecture

**Diagram brief:** Схема слоёв, где показаны:

*   **Channel layer:** web app, Teams/Slack, API, ticketing system
*   **Orchestration layer:** policy engine, planner, state machine, retry controller, human approval gate
*   **Model layer:** LLM, small classifier model, embedding model
*   **Knowledge layer:** RAG index, document store, vector DB, metadata catalog
*   **Tool layer:** CRM, ERP, email, internal APIs, MCP servers
*   **Governance layer:** authN/authZ, audit logs, prompts registry, safety filters, secrets management
*   **Observability layer:** traces, metrics, cost tracking, evaluation harness

Практическая enterprise-архитектура agentic-системы обычно разделяет обязанности так:

1.  **Intent capture** — принять запрос от пользователя или системы.
2.  **Policy check** — определить, разрешена ли задача, насколько она рискованна и нужен ли approval.
3.  **Context assembly** — собрать релевантные данные из retrieval-систем и business APIs.
4.  **Planning** — разбить работу на ограниченные шаги.
5.  **Execution** — вызвать tools с явными аргументами.
6.  **Verification** — проверить результат, найти аномалии, сравнить с правилами.
7.  **Escalation or completion** — передать человеку или завершить действие.
8.  **Audit and learning** — сохранить traces для evaluation, compliance и улучшений.

Эта архитектура должна быть явной. Если orchestration спрятана внутри одного prompt, вы теряете контроль над safety, observability и возможностью итераций.

* * *

## Шесть архитектурных паттернов

### 1) Retrieve-then-act

Это самый безопасный default для enterprise-workflows. Сначала agent собирает authoritative context через RAG, структурированные запросы или API lookup, и только потом решает, что делать.

**Лучше всего подходит для:** support triage, policy lookup, contract summarization, internal knowledge assistants, incident response prep.

**Почему работает:** модель меньше склонна hallucinate actions, когда до планирования у неё есть правильные факты.

**Design notes:**

*   Prefer structured retrieval для operational facts.
*   Ограничивайте context минимально необходимыми evidence.
*   Записывайте, какие источники повлияли на action.

**Частый implementation choice:** retrieval pipeline + deterministic business rules + LLM для synthesis.

* * *

### 2) Planner-executor split

Planner создаёт bounded plan, executor выполняет по одному шагу за раз.

**Лучше всего подходит для:** multi-step operations, cross-system fulfillment, onboarding, procurement workflows, internal ops automation.

**Почему работает:** разделение planning и execution снижает accidental tool chaining и делает failures проще для локализации.

**Design notes:**

*   Делайте planner output machine-readable.
*   Ограничивайте каждый шаг одним intent.
*   Перепланируйте после tool results, если state существенно изменился.

**Пример формы:**

*   Planner: «собери customer record, проверь entitlement, подготовь response, запроси approval, если refund выше threshold».
*   Executor: выполняет каждый шаг с явными preconditions.

Этот паттерн полезен, когда LLM нужно reasoning, но нельзя позволить ей самой импровизировать execution path.

* * *

### 3) Human-in-the-loop approval gates

Высокорисковые действия должны проходить approval gate до execution.

**Лучше всего подходит для:** financial actions, external communications, data deletion, access grants, production changes, legal or compliance-sensitive tasks.

**Почему работает:** сочетает machine speed с accountable human judgment.

**Design notes:**

*   Заранее определите risk thresholds.
*   Показывайте человеку concise evidence bundle, а не весь raw prompt.
*   Фиксируйте identity approver и rationale.

**Не используйте** approval gates как заплатку для плохой automation design. Gate должен защищать bounded process, а не спасать хаотичную систему.

* * *

### 4) Event-driven agent orchestration

Вместо ожидания запроса от пользователя system реагирует на events: создан ticket, истекает contract, упала data quality job или KPI вышел за threshold.

**Лучше всего подходит для:** operations, customer success, compliance monitoring, ITSM, supply chain alerts.

**Почему работает:** многие enterprise workloads уже event-native.

**Design notes:**

*   Используйте durable queues и idempotent handlers.
*   Кодируйте event metadata так, чтобы agent понимал urgency и ownership.
*   Отделяйте detection от action, чтобы избежать noisy auto-remediation.

Этот паттерн хорошо сочетается с policy rules и bounded automation.

* * *

### 5) Tool-calling with a narrow capability surface

Дайте agent только те tools, которые действительно нужны, и expose их через маленькие, чёткие interfaces.

**Лучше всего подходит для:** production systems, где надёжность важнее гибкости.

**Почему работает:** меньше tools — меньше ambiguity, меньше blast radius и проще security review.

**Design notes:**

*   Оборачивайте internal services через stable contracts.
*   Валидируйте каждый tool input.
*   Проектируйте tools вокруг business verbs, а не вокруг raw infrastructure primitives.

Например, `create_support_case` лучше, чем `execute_generic_api_request`.

Narrow tool surfaces особенно полезны при интеграции через MCP, потому что они подталкивают к reusable, versioned tool definitions вместо ad hoc prompt glue.

* * *

### 6) State-machine governed autonomy

Используйте explicit state machine, чтобы контролировать, какие действия разрешены на каждом этапе.

**Лучше всего подходит для:** onboarding, claims handling, case management, procurement, compliance workflows.

**Почему работает:** state machines делают autonomy legible. Они явно задают, что agent может сделать next и какие условия должны быть истинны.

**Design notes:**

*   Моделируйте states, transitions, guards и terminal outcomes.
*   Держите LLM как decision-support component внутри state machine, а не выше неё.
*   Храните state externally, чтобы работу можно было продолжить после failure.

Для enterprise это часто самый удобный паттерн, когда нужна deterministic control с точечной reasoning.

* * *

## Пять anti-patterns, которых стоит избегать

### 1) Unbounded autonomous loops

Если agent может бесконечно думать, вызывать tools и retry без бюджета, он рано или поздно создаст cost, delay или damage.

**Симптомы:** runaway API calls, повторные retries, дублирующиеся tickets, длинный tail latency.

**Исправление:** step limits, timeouts и budget caps.

* * *

### 2) Prompt-as-orchestrator

Огромный prompt, в котором живёт вся orchestration logic, хрупок и плохо тестируется.

**Симптомы:** hidden dependencies, нечитаемая логика, version drift и debugging методом проб и ошибок.

**Исправление:** перенесите control flow в code или workflow engine; prompt оставьте для reasoning.

* * *

### 3) Tool sprawl without governance

Каждая команда добавляет свои wrappers, naming conventions и permissions model.

**Симптомы:** duplicate capabilities, inconsistent schemas, security exceptions и unclear ownership.

**Исправление:** стандартизируйте tool contracts, регистрируйте capabilities centrally и применяйте consistent authz/audit logging.

* * *

### 4) No verification layer

Agent, который выполняет actions без проверки outputs, опасен в любой enterprise-среде.

**Симптомы:** invalid records, silent partial failures и слабая confidence в automation.

**Исправление:** добавьте schema validation, post-action checks, business rule validation и anomaly detection.

* * *

### 5) Treating autonomy as a binary

Команды часто спрашивают, система «agentic» или «not agentic». На практике autonomy — это spectrum.

**Симптомы:** over-automation в рискованных областях или under-automation там, где риск низкий.

**Исправление:** назначайте autonomy levels по workflow step, data sensitivity и business impact.

Хороший enterprise design позволяет одним шагам быть fully automated, а другим — требовать approval или deterministic handling.

* * *

## Decision matrix: когда что использовать

| Сценарий | Рекомендуемый паттерн | Уровень автономии | Главная причина | Лучший guardrail |
| --- | --- | --- | --- | --- |
| Internal knowledge Q&A | Retrieve-then-act | Low | Сначала факты, потом действия | Source citation и confidence threshold |
| Ticket triage and routing | Event-driven orchestration | Low to medium | Высокий объём, повторяемость | Idempotency и queue retries |
| Refund request handling | Planner-executor split | Medium | Несколько шагов, понятные policy | Approval выше threshold |
| Access provisioning | State-machine governed autonomy | Medium | Строгий lifecycle и audit needs | Role-based policy checks |
| Customer-facing email drafting | Human-in-the-loop gate | Low | External impact, важен tone | Human approval before send |
| Cross-system fulfillment | Tool-calling with narrow capability surface | Medium | API-heavy, bounded actions | Tool allowlist и input validation |

**Как пользоваться matrix:**

*   Если задача в основном informational — начинайте с retrieve-then-act.
*   Если задача включает несколько systems — отделяйте planning от execution.
*   Если действие необратимо или externally visible — добавляйте approval.
*   Если процесс имеет lifecycle states — моделируйте их явно.

Самая частая ошибка — пытаться применить один паттерн ко всем workflows. Зрелые enterprise-программы комбинируют их.

* * *

## Как естественно вписывается Agent Shaker

Agent Shaker можно использовать как practical accelerator для prototyping и operationalizing agentic workflows в enterprise-среде. Его естественная роль — не заменить architecture, а стандартизировать часть workflow surface.

Типичные точки естественного fit:

*   определение repeatable agent flows,
*   упаковка tool integrations,
*   эксперименты с prompt и policy variants,
*   создание reusable templates для orchestration.

При грамотном использовании Agent Shaker помогает перейти от ad hoc experiments к governed workflows. Особенно полезен он тогда, когда нужно сравнивать patterns side by side, тестировать tool boundaries и поддерживать implementation consistency между командами.

[Agent Shaker](https://techbuzzz.github.io/agent-shaker/) — open-source платформа координации агентов, которую мы делаем в AnetLab. Она даёт единый слой поверх моделей и инструментов: запуск сценариев, сравнение конфигураций бок о бок, трассировка вызовов к MCP-серверам и воспроизводимые прогоны. Репозиторий открыт — можно взять его как стартовую точку и собрать свой контур.

* * *

## Чеклист внедрения

Перед запуском enterprise agent workflow проверьте следующее:

*   [ ]  Бизнес-результат чётко определён.
*   [ ]  У workflow есть bounded autonomy level.
*   [ ]  Каждый external tool имеет stable contract.
*   [ ]  Authentication и authorization enforced.
*   [ ]  Prompts, policies и tool schemas versioned.
*   [ ]  Есть retrieval strategy для authoritative data.
*   [ ]  Каждое действие логируется с trace IDs.
*   [ ]  Есть retry policy и step budget.
*   [ ]  High-risk actions требуют approval.
*   [ ]  Outputs валидируются до downstream use.
*   [ ]  У команды есть evaluation harness.
*   [ ]  Ownership for failures задокументирована.

Если чего-то из этого нет, workflow, скорее всего, ещё не готов к production autonomy.

* * *

## FAQs

### 1) Что такое agentic workflow в enterprise-контексте?

Это workflow, в котором AI-system может рассуждать о задаче, собирать контекст, выбирать tools и выполнять bounded steps под control policy.

### 2) Чем это отличается от chatbot?

Chatbot в основном отвечает на сообщения. Enterprise agentic workflow может выполнять multi-step work, взаимодействовать с systems и формировать auditable outcomes.

### 3) Нужна ли всем enterprise-agent systems полная автономия?

Нет. Большинству production-систем нужна selective autonomy в зависимости от риска, impact и data sensitivity.

### 4) Где здесь RAG и MCP?

RAG обычно используют для grounding agent в authoritative enterprise knowledge. MCP часто применяют, чтобы expose tools и services через standardized interfaces.

### 5) Какая самая большая архитектурная ошибка?

Считать prompt всей системой. Настоящие agentic workflows требуют orchestration, policy, verification и observability вне модели.

### 6) Нужно ли применять agent для каждой automation-задачи?

Нет. Используйте agent там, где reasoning, context selection или dynamic planning дают value. Там, где process уже well-defined, лучше deterministic automation.

### 7) Как контролировать cost?

Задавайте step budgets, routing простых запросов на smaller models или rules, кэшируйте retrieval results и ограничивайте unnecessary tool calls.

* * *

## Related Articles

*   [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.com/blog/enterprise-ai-architecture.md)
*   [MCP для enterprise: протокол, безопасность и границы](https://anetlab.com/blog/mcp-for-enterprise.md)
*   [RAG на .NET: архитектура, которая переживает продакшн](https://anetlab.com/blog/rag-na-dotnet.md)
*   [Как вывести AI PoC в продакшн: 90 дней по фазам](https://anetlab.com/blog/ai-poc-to-production.md)

* * *

## CTA

Если ваша команда оценивает agentic workflows в enterprise-системах, начните с одного bounded use case и спроектируйте orchestration layer до масштабирования autonomy.

Agent Shaker может помочь стандартизировать workflow surface, сократить implementation drift и ускорить experimentation с governed agent patterns.

[Попробовать Agent Shaker](https://techbuzzz.github.io/agent-shaker/) или [рассказать про вашу задачу](https://anetlab.com/contact.md) — соберём решение под ваш контур, а не под готовый шаблон.

Читайте также

18 октября 2026 г.AI/LLM

### [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.com/blog/enterprise-ai-architecture.md)

Практическое руководство по архитектуре корпоративных AI-систем: RAG против дообучения, агенты против workflows, оценка качества и governance.

[Читать разбор](https://anetlab.com/blog/enterprise-ai-architecture.md)

[Архитектура](https://anetlab.com/blog?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)[Оценка качества](https://anetlab.com/blog?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md)

13 октября 2026 г..NET

### [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.com/blog/dotnet-azure-ai-architecture.md)

Как собрать production-ready AI-систему на .NET и Azure: async-пайплайн, RAG, Polly, observability и контроль стоимости — с рабочим кодом.

[Читать разбор](https://anetlab.com/blog/dotnet-azure-ai-architecture.md)

[AI/LLM](https://anetlab.com/blog?tag=AI%2FLLM.md)[Архитектура](https://anetlab.com/blog?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)[RAG](https://anetlab.com/blog?tag=RAG.md)