Почему AI agents разочаровывают в продакшене и что исправить в первую очередь

AI agents разочаровывают в продакшене, когда их пытаются пустить по дорогам, построенным для дашбордов. Чтобы сделать их надежными, нужно встроить в основу четыре гарантии.

AI agents выглядят блестяще в демо, потому что демо — это дружелюбный мир. Данные отобраны, инструменты ведут себя предсказуемо, и пока агент обдумывает ответ, ничего важного не меняется. В продакшене все наоборот: данные приходят с задержкой, факты противоречат друг другу, права доступа мешают, API дают тайм-ауты, а состояние системы постоянно меняется.

Именно поэтому ранние «агенты в продакшене» часто сводятся к более безопасным сценариям: только для чтения, workflows human-in-the-loop или узкие домены с тщательно подготовленными данными. Некоторые громкие внедрения тоже пришлось сократить после столкновения с грязными реальными ограничениями. Это не приговор автономности, а напоминание о том, что автономность не прощает ошибок. Небольшие трещины в data stack быстро превращаются в крупные сбои в поведении агента.

Та же схема повторяется всякий раз, когда агенты выходят из игрушечных workflows в системы с реальным состоянием. По мере роста масштаба слабые гарантии дают предсказуемые симптомы: слишком уверенные действия на устаревших данных, хрупкое рассуждение при смещении смысла и накопление ошибок, как только агент получает возможность что-то записывать обратно.

Решение — относиться к agents так, как они есть: как к системам, которые читают, рассуждают и записывают поверх живых operational data. Это заставляет выстраивать гарантии, которые большинство enterprise stacks обычно обеспечивает лишь неявно. Главные из них четыре: freshness, semantics, safe write paths и lineage.

Freshness: перестаньте рассуждать о вчерашнем

Многие организации научились жить со stale data: batch pipelines, replica lag, caches, delayed CDC (change data capture), materialized views. Люди компенсируют это суждением. Agents компенсируют это уверенностью.

Один из типичных сбоев в продакшене — когда рассуждение верное, но относится к неправильному временному срезу. Агент читает inventory, который отстает на несколько минут, и запускает reorder, который конфликтует с уже идущим replenishment. Или агент видит incident как «resolved» в одной системе, хотя в другой rollback еще pending, и продолжает изменение, которое следовало отложить. Это и есть freshness bugs.

«Freshness guarantee» означает, что время становится первоклассной сущностью. У фактов есть timestamps. Запросы поддерживают чистую семантику «as of», чтобы агент мог спросить, что было истинно в момент T, что истинно сейчас и что изменилось с момента его последнего действия. Workflows задают freshness SLO для данных, от которых зависят. Если платформа не может их выдержать, агент должен деградировать gracefully: поставить паузу, запросить подтверждение или перейти в read-only plan.

Freshness имеет и измерение развертывания. Многие сценарии для agents по природе локальны — от фабрик до retail sites. Если нужен низколатентный context, отправлять все в центральное хранилище и ждать возврата по кругу — это не оптимизация, а архитектурный дефект.

Semantics: делайте смысл явным, а не выводимым

Agents ошибаются более тонко, когда данные выглядят правильно, но в разных системах означают разное. Customer versus account. Order versus transaction. Код статуса, который разошелся между командами. Дублирующиеся идентификаторы. Несогласованное именование. Каждая система может быть локально корректной, а агент — глобально ошибочным.

Именно здесь команды тянутся к vector search и называют это memory. Embeddings отлично подходят для similarity. Но они слабы в представлении сложной структуры и ограничений. На практике similarity может помочь найти релевантный материал, но не дает semantic contract. Он не может гарантировать, что «этот customer» — одна и та же сущность в CRM, billing, support и identity systems. Он не умеет естественно кодировать ограничения вроде «device принадлежит только одному site одновременно» или «refund требует matching settlement». Когда agents полагаются на fuzzy recall, чтобы выполнять детерминированную работу, они ведут себя как уверенные импровизаторы.

Semantic guarantee означает явную модель entities и relationships, часто в виде «context graph», который связывает operational records с документами и сигналами, описывающими их. Это сдвиг по сравнению со старыми knowledge graph-программами, которые импортировали данные пакетами ради аналитических запросов. Появляющийся сценарий для agents — постоянный streaming данных, значительная часть которого приходится на documents и files, в сочетании с real-time read и write в одном operational loop.

Safe write paths: agents меняют данные, значит, проектируйте с учетом обратимости

Read-only agents могут ошибаться и все равно быть полезными. Write-capable agents могут ошибаться и быть разрушительными. Эффект накопления здесь в том, что ошибочное обновление становится ground truth для следующего шага, повторная попытка создает duplicate side effect, а частичная запись оставляет мир в несогласованном состоянии.

Safe write paths начинаются с transactional guarantees. ACID transactions сохраняют coherent state transitions. Важна idempotency, потому что agents повторяют попытки, а сети ведут себя нестабильно. Важен concurrency control, потому что агент почти никогда не единственный актор, меняющий состояние. Затем идут guardrails: row-level security, role-based access и ограничения, enforced by the platform, а не спрятанные в prompts.

Практический шаблон — plan-validate-commit. Агент предлагает структурированный change set, проверяет его на текущем состоянии и ограничениях, а затем выполняет commit с audit record, который связывает действие с evidence. Approval может быть автоматическим или человеческим — в зависимости от риска, но write path остается дисциплинированным.

Lineage: если вы не можете отследить решения, вы не сможете их улучшить

Когда agent ошибается, командам нужно ответить на простой вопрос: что он видел? Без этого отладка превращается в археологию.

Lineage связывает данные и поведение. Он включает provenance для records и documents, а также agent-specific traces: какие retrieval results использовались, какие tool calls выполнялись, какие policies применялись и что изменилось в результате. AI-native платформа должна делать сбор и запрос этой информации практичным. В ней должны быть immutable audit trails для высокорисковых действий, versioning или time travel для критичных сущностей и связи между решениями и точными data snapshots, которые были использованы. Так же evaluation превращается в engineering: через replayable scenarios, regression tests и drift detection.

Что дает AI-native data platform

Эти четыре гарантии ведут к одному выводу: agentic workloads наказывают fragmentation. Каждый дополнительный datastore, index и pipeline — это еще одно место, где semantics могут съехать, а freshness провалиться. На runtime agents вынуждены склеивать пять систем, а runtime stitching — это место, где consistency умирает. Поскольку agents работают через эти системы непрерывно, а не эпизодически, они усиливают интеграционные дефекты.

AI-native data platform — это фундамент, который может хранить operational truth, semantic context и retrieval signals в одном месте, обеспечивая transactional correctness, controlled writes и auditable history. Обычно это означает нативную поддержку всех data shapes, которые нужны agents в одном workflow: relational records, JSON documents, graph relationships, time-series events и vector embeddings. Это также означает поддержку composable queries, которые могут объединять структурированные фильтры, traversal по relationships и similarity search без перегонки данных между сервисами.

Еще одно требование — гибкость развертывания. Data plumbing обычно движется медленнее, чем front-end UX, потому что яркие интерфейсы проще объяснить, чем сложную работу по обеспечению consistency на масштабе. Agents выводят эту проблему на поверхность. Платформы, которые могут запускать один и тот же engine в cloud, в self-hosted environments, в memory и на edge, снижают orchestration overhead и упрощают поддержание гарантий.

С чего начать: чек-лист готовности agents для инженера

Полная автономность редко должна быть стартовой точкой. Стартовой точкой должны быть явные гарантии.

Начните с read paths. Докажите качество retrieval, границы freshness и semantic coherence, пока agent работает в advisory mode. Определите context contract: authoritative sources, правила entity resolution, важные relationships и то, что означает «достаточно свежо» для каждого workflow. По умолчанию включите lineage, чтобы каждую рекомендацию можно было отследить до evidence.

Постепенно вводите writes. Ограничьте ранние действия обратимыми операциями. Сделайте tool calls idempotent. Используйте transactions. Оставьте enforcement на уровне platform. Рассматривайте approvals как настраиваемый control, а human sign-off — там, где этого требуют риск и blast radius.

Agents разочаровывают в продакшене, когда мы просим их ездить по дорогам, построенным для dashboards. Встройте эти четыре гарантии в substrate, и та же модель начнет вести себя как гораздо более надежная система. В этом и есть неглянцевая правда про «agent memory» и «context graphs». Это инфраструктурная работа, но именно она быстрее всего ведет от демо к deployment.

Материал — перевод статьи с английского.

Оригинал: Why most AI agents disappoint in production (and what to fix first)