AI agent demo vs production: в чём реальная разница

Demo впечатляет на встрече. Production выдерживает плохие входы, ограниченные permissions, human gates и исключения в понедельник утром. Разрыв - не «ещё чуть-чуть polish в chat UI». Разрыв в том, ведёт ли себя система в ваших constraints, когда никто не подставляет готовые промпты.

Полный набор controls за этим утверждением - в материале определение и архитектура production AI agent. Покупайте production design, а не demo polish.

Demo vs production с одного взгляда

Используйте эту таблицу, когда смотрите demo вендора или внутренний прототип. Она сопоставляет обычные shortcuts demo с controls, которые реально нужны в production.

Подпись: таблица решения - черты AI agent demo против production controls. Если строка на стороне production пустая, вы всё ещё смотрите на demo.

Почему demo работает, а production падает

Демо оптимизируют под успех на встрече. Кто-то выбирает удобные тикеты, широкие API keys и путь, который модель уже хорошо закрывает. Зал аплодирует, потому что сценарий срабатывает.

Production падает по обратным причинам. Входы не отобраны: опечатки, пустые поля, злые клиенты, неполные записи CRM и edge cases, которые никто не репетировал. Credentials должны быть узкими, чтобы ошибка одного tool не стёрла и не раскрыла больше, чем должна. Multi-step agents ещё и накапливают ошибки: каждый слабый шаг умножает риск через tool calls - поэтому Anthropic рекомендует простые composable patterns, обширное тестирование в sandboxed environments и guardrails до ставки на открытую автономию (Building effective agents).

Вывод: demo, которое работает только на happy path, - ожидаемо. Называть этот путь «production ready» - и есть провал.

Chatbot demo vs agent system

Узкий Q&A chatbot может быть production-ready при меньшем blast radius. Он отвечает из knowledge base, передаёт человеку и не переписывает ваши systems of record.

Agent demo с tools - другой класс риска. Он может создавать тикеты, обновлять поля CRM, слать сообщения или запускать workflows. Это и есть различие chatbot-demo vs agent-system, важное для покупателя: тот же polish на встрече, куда выше цена ошибки, когда permissions настоящие.

Если demo только чатится - оценивайте его как support surface. Если demo действует - оценивайте как систему, которая при ошибке может навредить людям и данным.

Как вендоры размывают границу (agent washing)

Вендоры часто хостят demo на вашей logo theme, ваших цветах и выборке FAQ. Это брендинг, не production.

В отраслевых и agency-текстах это иногда называют agent washing: отгружают отполированное demo под ярлыком production без evaluation, observability, least-privilege tools, failure handling и runbook. Проще: demo на вашем брендинге без ваших constraints - всё ещё demo.

Следите за такими паттернами:

• Credentials - «временный admin», который никогда не сужают.
• Сбои отмахивают: «retries добавим во phase two».
• Логи заканчиваются chat transcript; tool calls и cost невидимы.
• После pilot нет именованного владельца.
• Единственный «eval» - слайд с зелёными галочками с sales-звонка.

Если этих constraints нет, вы купили театр с датой deployment.

Buyer tests: вопросы, которые счищают demo

Не принимайте чистый sample как proof. Гоняйте тесты, которые вендор или внутренняя команда не поставят за пять минут.

1. Replay messy tickets за прошлый месяц - не golden path. Берите реальные exceptions: refunds, edge cases политики, неполные данные, злой тон.
2. Покажите permission scopes - какие tools, какие environments, least privilege или admin?
3. Kill switch drill - кто останавливает agent mid-run и сколько это занимает?
4. Есть ли eval suite - cases, pass bars и что гоняется после смены prompt или model. См. как оценивать AI-агентов до go-live.
5. Последний incident или failure log - что сломалось, что сделал agent, кто заметил.
6. Владелец runbook - именованный человек за review queue, on-call и post-incident notes.
7. Tool failure и budget limit - что происходит, когда API уходит в timeout или spend бьёт в cap?

Назначение чеклиста: buyer-вопросы, чтобы проверить, production-ready ли AI agent demo. Если ответы размыты, вы всё ещё в demo mode.

Production signals, которые стоит требовать

Вам не нужен platform whitepaper, чтобы требовать эти signals. Они нужны до того, как через agent пойдут данные клиентов или деньги.

• Human gates и oversight. Необратимые действия требуют approval paths, а не надежды. Практики OpenAI по governance agentic systems подчёркивают accountability и human approval для значимых решений (Practices for governing agentic AI systems). Практический design gates: human-in-the-loop AI-агенты: как это устроено.
• Trajectory-aware evaluation. Оценивайте путь (выбор tool, recovery, уточняющие вопросы), а не только финальный ответ. Google Cloud строит agent evaluation вокруг полных trajectories и staged rollout: sandbox → canary → production (A developer's guide to production-ready AI agents; Agent Quality).
• Least-privilege tools. Scoped credentials и authenticated tool access сильнее API keys основателя.
• Security против prompt injection и смежных LLM-рисков. Agents с tools наследуют риски из OWASP Top 10 for LLM applications, включая prompt injection и excessive agency (OWASP Top 10 for LLM Applications).
• Staged deploy mindset. Sandbox internal tests, canary на ограниченный traffic, затем более широкий production. Полная глубина архитектуры - в посте определение production AI agent, не здесь.
• Observable failures. Когда что-то ломается, нужны logs и traces, а не память. Связанные материалы кластера: режимы отказа production-агентов и наблюдаемость агента: logs и traces.

Hybrid-паттерны в production обычны: deterministic controls и policy на шаги с деньгами и compliance, LLM judgment там, где нужны язык и routing. Это design recommendation, а не универсальный закон - и оно совпадает с позицией Anthropic: начинать просто и добавлять agent autonomy только когда более простых workflows уже мало (Building effective agents).

Как вписывается Northstar

Northstar поставляет production paths: discovery, scoped tools, human gates, evals и ownership после handoff - не demo polish под видом go-live. Если у вас есть прототип, которому нужен production design, смотрите решения или начните разговор через CTA на сайте.

Мы не выдумываем case study для этой страницы. Тест тот же, что мы советуем гонять на любом вендоре: messy tickets, реальные scopes, kill switch, evals, logs.