ИИ-агенты, которым разрешено действовать только там, где это безопасно

Кому это подходит

• Продуктовым командам, чей ассистент должен пользоваться внутренними инструментами, а не только генерировать текст.
• Операционным командам с повторяющейся многошаговой работой, где всё ещё нужно суждение.
• Платформенным командам, которых попросили «сделать агента» и нужно свести это к архитектуре.

Для чего агенты нужны — и для чего нет

• Копилот должен читать несколько систем и предлагать следующее действие.
• Прототип агента зацикливается, бронирует дважды или пишет не тому человеку.
• Руководство хочет агентов; домену нужен конечный автомат с LLM на одном шаге.

Что проектирую

• Интерфейсы инструментов с типизированным входом, идемпотентностью и минимальными правами.
• Разделение планировщика и исполнителя, чтобы модель не выдумывала и не коммитила одновременно.
• Условия останова, таймауты и потолок вызовов.
• Оценки: сценарии траекторий, таксономия отказов, регресс.
• Человеческое подтверждение необратимых действий.

Как решаю, нужен ли агент

Если шаги известны — процесс. Если следующий шаг зависит от грязного ввода, а инструментов мало — маршрутизатор. Если модель должна найти путь через много инструментов — тогда, и только тогда, цикл агента с жёстким потолком и журналом. Большинство коммерческих запросов «агента» схлопываются в маршрутизатор плюс три инструмента.

Что делает агента достаточно надёжным для выпуска

Надёжность — не промпт. Это та же дисциплина, что у любого распределённого воркера, плюс вероятностный планировщик.

Как ломаются агенты

• Модели дают браузер и прод-учётные данные «чтобы было полезнее».
• Нет среды симуляции — оценки бьют по живым клиентам.
• Многоагентный спор вместо спецификации.
• Процесс прячут за агентом, потому что процесс так и не спроектировали.

Результат

• Архитектурное решение: процесс, маршрутизатор или агент — с причинами.
• Контракты инструментов и модель прав.
• Рабочий агент или копилот с трассами и потолками.
• Набор оценок, который команда может гонять в CI.

Избранные проекты

• Synopsys – Продуктовый UI в Synopsys для бенчмаркинга и сравнения больших языковых моделей, включая поверхности пробного вывода для экспериментов с генеративным ИИ.
• Genie Platforms – Разговорная AI-платформа для продаж, RevOps и GTM – AI-SDR внутри существующих процессов выручки.
• Mindshine – Платформа голосового и текстового поиска (TIVA Data / Knowledge Base): доступ к данным независимо от источника.

Связанные услуги

• Интеграция ИИ – Модель внутри существующего процесса — с контрактами и выходом, а не чатбот рядом с продуктом.
• Автоматизация с ИИ – Снять ручное узкое место в живой операции: сначала правила, модель — только на грязном вводе.
• Архитектура ПО – Системный дизайн живых продуктов: чему существовать, где границы и как система отказывает.

Связанные заметки

• Когда добавлять LLM в существующий продукт — и когда не стоит

Вопросы, которые задают