Разборы · Статья: · Видео: · 7:13

Модель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов

Разбор доклада инженера Meta Superintelligence Labs: почему при переходе от чатботов к автономным агентам главной проблемой становится не интеллект, а надёжность, и как строить детерминированную инфраструктуру вокруг вероятностной модели.

Смотреть на YouTube

Deterministic Infra for Non-Deterministic AI Agents - Nishant Gupta, Meta Superintelligence Labs

AI Engineer · 7:13

Главы видео — нажми, чтобы перейти к моменту 10
  1. 0:00 Проблема не в интеллекте, а в надёжности Разговор об ИИ был про модели, но с переходом к автономным агентам главным становится не ум, а надёжность.
  2. 0:58 Великое несоответствие Облачная инфраструктура строилась на допущениях (короткие запросы, детерминизм), которые агенты нарушают.
  3. 1:34 Демо показывает возможности, продакшен требует надёжности Может ли агент сделать это 10 000, 100 000, миллион раз, восстановиться после сбоя и уложиться в бюджет.
  4. 1:53 Реальные сбои — не галлюцинации Recursive loops, deadlocks, retry amplification, отравление памяти, взрыв расходов — вот что валит систему.
  5. 2:29 Retry amplification: как ошибка становится аварией Невалидный вызов инструмента запускает цикл повторов, каждый жрёт compute — минорная ошибка API становится инцидентом.
  6. 3:08 Модель предлагает — платформа решает Главный принцип: модель генерирует предложения, инфраструктура валидирует, policy engine одобряет, gateway исполняет.
  7. 3:24 Agentic control plane — ОС для автономного ИИ Как контейнеры породили Kubernetes, агенты порождают новый управляющий слой: планирование, память, политики, мониторинг.
  8. 4:00 Наблюдаемость и память: почему падают мультиагенты Нужны трассы «почему», а не логи «что». Общая память даёт stale reads и консистентностные сбои под маской ошибок рассуждения.
  9. 4:55 Слои безопасности и человек в контуре Defense in depth плюс человек как постоянный обработчик исключений, а не временный костыль.
  10. 6:13 Инфраструктура — новая линия конкуренции Distributed-паттерны переносятся 1:1; промпты и модели коммодитизируются, побеждает тот, у кого надёжнее системы.

Коротко

При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:24
Показать текст выжимки
Если коротко, это доклад инженера из Meta о том, почему будущее ИИ-агентов решают не модели, а инфраструктура вокруг них. Главная мысль такая. Когда компании переходят от простых чатботов к автономным агентам, которые сами планируют, вызывают инструменты и принимают решения в боевых системах, узким местом становится не интеллект, а надёжность. Модель по природе вероятностна, а инфраструктуре быть такой нельзя. Простыми словами. Не пытайтесь сделать саму нейросеть безошибочной. Постройте вокруг неё строгую обвязку, которая проверяет и ограничивает каждое её действие. Модель только предлагает, а платформа решает, одобряет и исполняет. Стоит ли смотреть. Да, это плотные семь минут для инженеров. Но это концепция без кода и примеров, так что ждите идею, а не готовый рецепт. Кому особенно полезно. Платформенным и инфраструктурным инженерам, а также специалистам по надёжности и эксплуатации. Пара сильных мыслей. Первая. Галлюцинации — самый скучный тип сбоя. Настоящие аварии инфраструктурные: зацикленные повторы, тупики, отравление памяти, взрыв расходов. Вторая. Мультиагентные сбои чаще всего это проблемы согласованности состояния, которые маскируются под ошибки рассуждения. Что делать на практике. Никогда не давайте модели напрямую управлять боевыми системами. Поставьте лимиты на повторы и глубину рассуждений, иначе одна мелкая ошибка превратится в счёт за видеокарты. И введите трассировку решений, а не просто логи, чтобы понимать не только что случилось, но и почему. Один контраргумент. Аналогия агент равно распределённая система красива, но недетерминизм нейросети качественно иной, чем сетевой сбой, и не все привычные паттерны переносятся один в один. И напоследок мысль иначе. Надёжность вокруг ненадёжного оператора давно инженерят в авиации и медицине — те же чек-листы, слои защиты и человек как обработчик исключений. ИИ-агенты просто повторяют этот путь.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

Современные ИИ-агенты сами планируют, вызывают инструменты и принимают решения — но делают это непредсказуемо. Автор говорит: не пытайтесь сделать саму модель безошибочной, стройте вокруг неё строгую «рельсовую» инфраструктуру, которая проверяет и ограничивает каждое её действие. Тогда система работает стабильно, даже когда модель ошибается.

Как ребёнку

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

Аналогия — «это как…»

Это как атомная станция: реактор по природе бурный и непредсказуемый, поэтому вокруг него строят контур защиты, датчики, клапаны и операторов. Ценность — не в укрощении реактора, а в надёжной обвязке вокруг него. Модель — это реактор, инфраструктура — контур.

Зачем это мне

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

Для тех, кто в теме

Тезис — сместить инженерный вес ниже слоя модели: execution gateway плюс policy engine между proposal и действием, трассировка решений (planning/tool-calls/memory/state) вместо плоских логов, память как shared distributed state со stale reads и проблемами консистентности, инференс как cluster scheduling. Distributed-примитивы переносятся (circuit breakers → tool isolation, quotas → cost governance), а control plane становится новым foundation layer.

Оценка видео

Чем выше — тем больше пользы на минуту

4.2

средняя из 5

Актуальность информации 4.6

Надёжность автономных агентов — одна из центральных инженерных тем 2026 года, доклад бьёт точно в неё.

Содержательность 4.3

Очень плотно для семи минут, но формат — конспект слайдов с перечислениями, без глубокого разбора каждого пункта.

Инновационность идей 3.8

Сильный фрейминг («великое несоответствие», agentic control plane), но многое — перенос зрелых distributed-systems паттернов.

Практическая применимость 4.1

Даёт ясные архитектурные принципы, но без кода, метрик и деталей реализации — это карта, а не инструкция.

Достоверность и баланс 4.4

Опирается на проверенные инженерные практики и честно отводит человеку постоянную роль, а не рисует полную автономию.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для платформенных и инфраструктурных инженеров 5 /5

Прямое попадание: весь доклад — про слой, который они и строят, от execution gateway до control plane.

Для SRE и инженеров по надёжности 4.7 /5

Distributed-паттерны (circuit breakers, rate limits, quotas, observability) переносятся на агентов почти без изменений.

Для ML- и AI-инженеров 4.4 /5

Помогает вынести ответственность с модели на платформу и разорвать циклы невалидных повторов у своих агентов.

Для архитекторов ПО 4.2 /5

Даёт готовое разделение proposal → validation → policy → execution и понятие управляющего слоя для автономных систем.

Для технических директоров и CTO 4 /5

Отвечает на вопрос, куда инвестировать: не в лучший промпт, а в надёжную инфраструктуру как источник преимущества.

Для продакт-менеджеров ИИ-продуктов 3.3 /5

Объясняет, почему эффектное демо не равно продакшену и какие вопросы задавать инженерам про надёжность.

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 Узкое место ИИ-агентов — не интеллект, а надёжность 0:20

Годы гонки за размером моделей приучили думать, что прогресс — это «умнее». Но как только агент начинает действовать в продакшене, фронт смещается ниже слоя модели: побеждает не тот, чей агент умнее, а тот, чья система реже падает.

02 Галлюцинации — самый скучный тип сбоя 1:53

Когда слышат «сбой ИИ», думают про выдумки модели. На практике аварии — инфраструктурные: зацикленные рассуждения, тупики workflow, отравление контекста и памяти, взрыв расходов. Модель ошибается один раз, инфраструктура превращает это в аварию.

03 Неконтролируемые повторы — главный риск агентных систем 2:29

Агент вызвал инструмент неверно, получил ошибку и вместо восстановления сгенерировал чуть другой, но всё ещё невалидный запрос. Цикл повторяется, глубина рассуждений растёт, потребление GPU — тоже. Это не баг модели, а отсутствие тормозов в платформе.

04 Мультиагентные сбои — это чаще проблемы консистентности 4:38

Как только несколько агентов делят состояние, всплывают классические болезни распределённых систем: устаревшие чтения, конфликтующие обновления, дрейф контекста. Это выглядит как «агент плохо думает», а на деле — рассогласованное состояние.

05 Человек в контуре — постоянная роль, а не временный костыль 4:55

Распространён взгляд, что люди нужны, пока модели не дозреют. Автор возражает: успешные системы останутся под надзором человека навсегда, просто человек становится обработчиком исключений — разбирает неоднозначное и даёт калибровочный сигнал.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«Проблема больше не в интеллекте. Проблема — в надёжности.»
Nishant Gupta 0:20
«Эти системы принципиально вероятностны. Инфраструктуре быть такой не позволено.»
Nishant Gupta 0:38
«Мы пытаемся запускать автономные системы на инфраструктуре, спроектированной под детерминированные workflow. Это я и называю великим несоответствием.»
Nishant Gupta 1:15
«Модель совершает ошибку, но именно инфраструктура превращает эту ошибку в аварию.»
Nishant Gupta 2:11
«То, что началось как мелкая ошибка API, стало compute-инцидентом.»
Nishant Gupta 2:47
«Модель лишь предлагает — платформа решает.»
Nishant Gupta 3:08
«Многие мультиагентные сбои на деле — это сбои консистентности, маскирующиеся под сбои рассуждения.»
Nishant Gupta 4:38
«Будущее ИИ выиграют не лучшие промпты. Его выиграют лучшие системы.»
Nishant Gupta 7:05

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Никогда не давай модели напрямую управлять продакшеном

на уровне архитектуры одна ошибка модели перестаёт быть аварией

Модель должна только предлагать действие. Отдельные слои проверяют его, одобряют по политике и исполняют. Так система остаётся надёжной, даже пока модель вероятностна.

Что делать

  1. 1 Заведи явный шаг: вывод модели = предложение, а не команда.
  2. 2 Поставь между предложением и действием валидатор схемы и прав.
  3. 3 Добавь policy engine, который одобряет или отклоняет по правилам.
  4. 4 Исполняй только через шлюз, который принудительно применяет ограничения.
2

Поставь лимиты на повторы и глубину рассуждений

полдня мелкая ошибка API не превратится в счёт за GPU

Retry amplification — когда каждый повтор жрёт больше compute, чем предыдущий. Ограничь число ретраев, глубину и общий бюджет одной задачи, чтобы цикл не рос экспоненциально.

Что делать

  1. 1 Задай максимум повторов на один вызов инструмента.
  2. 2 Ограничь глубину рассуждений и общее время на задачу.
  3. 3 Введи бюджет по токенам/долларам с жёстким обрывом при превышении.
3

Трассируй решения, а не только логи

неделя сможешь дебажить «почему», а не только «что»

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

4

Строй безопасность слоями

итеративно каждый слой ловит свой класс сбоев

Безопасность нельзя свести к одному компоненту. Складывай контроль на уровне промпта, права на инструменты, валидацию политик, человеческие подтверждения и аудит — это тот же defense in depth, что и в классической безопасности.

5

Заранее реши, где именно нужен человек

полдня контроль без узкого горлышка из людей

Цель — не убрать человека и не согласовывать у него всё подряд, а направить внимание туда, где оно даёт максимум: неоднозначные ситуации, калибровка, разбор исключений. Остальное платформа тянет сама.

6

Переиспользуй паттерны распределённых систем

зависит от стека не изобретаешь инфраструктуру заново

Многое уже решено десятилетиями. Circuit breakers становятся изоляцией инструментов, rate limits — лимитами агентов, resource quotas — управлением расходами, observability — трассировкой агентов.

7

Относись к инференсу как к планированию кластера

на уровне платформы нагрузки на минуты не убивают бюджет и латентность

Агентные workflow идут минутами, а не миллисекундами, спрос всплесковый, требования к ресурсам скачут. Это задача про GPU-эффективность, размещение нагрузок и эластичную ёмкость, а не только про модель.

Сценарии применения

Как разные люди применяют это на практике

Я как Платформенный инженер

Проблема: агенты валят прод неожиданными способами, а не там, где ждали ошибок модели

Хочу: построить надёжный слой, где сбой модели не пробивает наружу

Поможет: получает готовую схему control plane и разделение предложение/валидация/исполнение

Я как SRE

Проблема: штормы повторов агента внезапно съедают GPU-квоту кластера

Хочу: ограничить каскады и вернуть предсказуемость расходов

Поможет: видит, как лимиты ретраев и tool isolation по мотивам circuit breakers это гасят

Я как ML-инженер

Проблема: агент зацикливается на чуть изменённых, но всё ещё невалидных вызовах

Хочу: разорвать цикл, не переучивая модель

Поможет: понимает механику retry amplification и почему валидировать нужно предложения, а не веса

Я как Технический директор

Проблема: непонятно, во что вкладывать — в модели помощнее или в инфраструктуру

Хочу: найти, где реальное конкурентное преимущество

Поможет: получает тезис «следующий фронтир — инфраструктура» как ориентир для бюджета

Я как Разработчик мультиагентной системы

Проблема: агенты видят рассогласованное состояние и «спорят» друг с другом

Хочу: добиться консистентности общей памяти

Поможет: узнаёт, что это сбои консистентности под маской ошибок рассуждения, и куда смотреть

Я как Инженер по безопасности ИИ

Проблема: как ограничить автономного агента, не убив его пользу

Хочу: многоуровневый контроль без единой точки отказа

Поможет: берёт готовую раскладку defense in depth и роль человека как обработчика исключений

Я как Продакт-менеджер ИИ-продукта

Проблема: демо восхищает, а в проде агент нестабилен

Хочу: понять, что отличает витрину от рабочей системы

Поможет: получает язык, чтобы спрашивать команду про надёжность, восстановление и стоимость масштаба

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Фокус ИИ сместился с моделей на надёжность 0:20

    Годы говорили про размер и рассуждения моделей, но при переходе к автономным агентам главным становится надёжность.

  2. Аргумент Агенты нарушают допущения облачной инфраструктуры 0:58

    Короткие запросы, детерминизм, известные пути, ограниченные сбои — агенты stateful, долгие и недетерминированные. Это «великое несоответствие».

  3. Пример Пример: retry amplification 2:29

    Невалидный вызов → ошибка → чуть другой невалидный вызов → цикл → экспоненциальный рост потребления GPU. Мелкая ошибка стала инцидентом.

  4. Аргумент Вывод: модель не должна управлять продом напрямую 3:08

    Модель предлагает, инфраструктура валидирует, policy engine одобряет, gateway исполняет. Платформа решает — не модель.

  5. Аргумент Возникает agentic control plane 3:24

    Как контейнеры дали Kubernetes, агенты дают управляющий слой: планирование, память, политики, мониторинг, маршрутизация — ОС для автономного ИИ.

  6. Пример Проблемы не новы: distributed-паттерны переносятся 6:13

    Circuit breakers → tool isolation, rate limits → agent limits, quotas → cost governance, observability → agent tracing.

  7. Вывод Промпты и модели коммодитизируются 6:31

    Сначала различали промпты, потом модели; оба быстро становятся commodity. Следующий фронтир — инфраструктура.

  8. Вывод Будущее выиграют лучшие системы, а не лучшие промпты 7:05

    Агентов надо строить как распределённые системы: модель стохастична, инфраструктура детерминирована, наблюдаемость обязательна.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Стоит ли смотреть целиком

Да, если вы строите или эксплуатируете ИИ-агентов в продакшене. Это плотные семь минут инженерного взгляда от человека из Meta Superintelligence Labs: не про то, как сделать модель умнее, а про то, как окружить её инфраструктурой, которая не даст её вероятностной природе прорваться в аварию. Главная ценность — не рецепт, а смена рамки: перестать чинить модель и начать проектировать платформу вокруг неё.

Ядро доклада укладывается в одну связку. Агенты нарушают почти все допущения классической облачной инфраструктуры — это «великое несоответствие». Отсюда реальные сбои не галлюцинации, а инфраструктурные: retry amplification, тупики, отравление памяти, взрыв расходов. Лечится это архитектурно: модель лишь предлагает действие, а валидация, политики и шлюз исполнения решают, что реально произойдёт. Над этим вырастает agentic control plane — управляющий слой, который автор называет операционной системой для автономного ИИ.

Чего в докладе нет

Формат конференции задаёт жанр: это карта, а не инструкция. Нет кода, метрик, конкретных порогов ретраев и примеров реализации — как именно валидировать предложения модели или измерять «надёжность», остаётся за кадром. Спорны и два громких тезиса: что галлюцинации «скучны» (для продуктов доверия они центральны) и что инфраструктурный слой даст устойчивое преимущество (он может коммодитизироваться так же быстро, как модели и промпты). Но как рамка для проектирования агентной платформы доклад работает: он даёт правильный список вопросов, даже если не отвечает на них до конца.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 6

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 8 Верно: 0
  1. 1. Что автор называет главным узким местом при переходе от чатботов к автономным агентам?

  2. 2. Что такое «великое несоответствие» (the great mismatch)?

  3. 3. Какой тип сбоя автор называет наименее интересным?

  4. 4. Что происходит при retry amplification?

  5. 5. В чём главный архитектурный принцип доклада?

  6. 6. С чем автор сравнивает agentic control plane?

  7. 7. Чем на самом деле чаще всего оказываются мультиагентные сбои?

  8. 8. Какую роль человека в успешных системах предсказывает автор?

Словарь терминов

Понять незнакомое простым языком

Показать 10 терминов
Детерминированная / недетерминированная система
Детерминированная выдаёт один и тот же результат на одинаковый ввод; недетерминированная (как LLM) может каждый раз выбирать разный путь и ответ.
Retry amplification
Усиление повторов: агент снова и снова пробует невалидное действие, и каждая попытка тратит всё больше вычислений, пока мелкая ошибка не станет крупным инцидентом.
Agentic control plane
Управляющий слой для агентов: планирование, координация памяти, применение политик, оценка, мониторинг и маршрутизация нагрузок. По сути «операционная система» для автономного ИИ.
Execution gateway
Шлюз исполнения — компонент, через который только и может совершаться реальное действие агента, принудительно применяя ограничения и права.
Policy engine
Движок политик: проверяет предложенное моделью действие на соответствие правилам и одобряет или отклоняет его до исполнения.
Observability / трассировка
Наблюдаемость: способность видеть не только «что случилось» (логи), но и «почему» — цепочку планов, вызовов инструментов, обращений к памяти и смен состояния.
Defense in depth
Эшелонированная защита: несколько независимых слоёв контроля, каждый ловит свой класс сбоев, чтобы не было единой точки отказа.
Circuit breaker
Предохранитель из распределённых систем: автоматически размыкает вызовы к сбойному компоненту, чтобы отказ не каскадировал. У агентов превращается в изоляцию инструментов.
Context corruption / memory poisoning
Порча контекста и отравление памяти: в рабочую память или контекст агента попадают ошибочные или вредные данные, искажая последующие решения.
Cluster scheduling / resource orchestration
Планирование кластера: распределение вычислительных ресурсов между всплесковыми, разными по длительности нагрузками — то, чем всё больше становится инференс агентов.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Упрощение

Аналогия «ИИ-агенты = распределённые системы» проведена слишком прямолинейно

Недетерминизм LLM качественно иной, чем сетевые сбои или гонки данных: модель может быть «уверенно неправа» осмысленным образом. Не все distributed-паттерны переносятся 1:1, и валидация предложения модели — задача сложнее, чем таймаут или ретрай.

Преувеличение

«Галлюцинации — наименее интересный режим сбоя»

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

Спорно

Тезис «control plane даёт устойчивое конкурентное преимущество»

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

Однобоко

Доклад целиком концептуален

За семь минут — ни одного конкретного примера реализации, метрики или числа. Как именно валидировать предложения модели, где ставить пороги ретраев, чем измерять «надёжность» — остаётся за кадром, поэтому тезисы трудно проверить на практике.

Спорно

«Человек навсегда останется обработчиком исключений»

Утверждение подано как данность, но это спорно на фоне тренда к росту автономности: сегодняшняя роль человека может оказаться переходной фазой, а не постоянной. Автор не приводит аргументов, почему граница автономии зафиксируется именно здесь.

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

На стыке областей

Надёжность вокруг ненадёжного оператора уже освоена в авиации и медицине

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

Смежная область

Финансовые системы уже построили execution gateway

Биржевые risk engines с position limits, kill switch и предторговыми проверками — это ровно «модель предлагает, платформа решает и ограничивает». Готовый пласт практик по управлению рисками автономных действий можно переносить в агентную инфраструктуру.

Другой угол

А что если детерминированная обвязка душит пользу агента?

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

Другой угол

Control plane — это продукт, а не внутренняя утилита

Если это действительно «ОС для автономного ИИ», то выиграет не тот, кто построит её для себя, а тот, кто продаст платформу всем — как AWS продал инфраструктуру. Настоящая ставка может быть не в надёжности своих агентов, а в том, чтобы стать стандартом для чужих.

Похожие разборы

Разбор

Строй системы, а не код: как проектировать агентов инженерными навыками

Проектирование агентов — это не новая дисциплина, а те же инженерные навыки: системное мышление, декомпозиция, контракты, управление состоянием и безопасность. Разница только в примитивах — вместо классов и сервисов у вас промпты, скиллы, скрипты и сабагенты, но дисциплина ровно та же.

Читать →
Разбор

Агент со 100 инструментами — это ловушка: почему точность падает и как её вернуть роутингом

Если сваливать в промпт все определения инструментов сразу, агент тонет в контексте: на 741 инструменте точность выбора падает до 13,6%, а промпт раздувается до 127 000 токенов ещё до вопроса пользователя. Лечится это семантическим роутингом — ретривом 3–5 релевантных инструментов под конкретный запрос, который держит точность выше 83% и режет токены на инструменты почти на 99%.

Читать →
Разбор

Domain-specific агенты: почему будущее за роем узких ИИ, а не за одним всемогущим

Компании пытаются интегрировать ИИ, навешивая на один большой агент всё больше MCP и skills — и упираются в раздувание контекста и хрупкость. Автор доказывает, что будущее за композицией: рой узких доменных агентов, каждый со своей моделью, инструментами и памятью, координируемых на обычном языке — это дешевле, безопаснее и масштабируется.

Читать →
Разбор

RL-агент для упавших ETL-пайплайнов: восстановление за минуты и дисциплина вовремя остановиться

Агент ловит событие о сбое ETL, собирает улики из логов и схемы, классифицирует поломку и выбирает одно ограниченное действие — повторить, привести схему, откатить, изолировать, эскалировать или залогировать — а внешний слой безопасности проверяет решение до исполнения. Главный вывод честен до неприятного: надёжность дали структура состояния, простая логика и внешние ограничители, а не сам RL, который на компактном пространстве лишь сравнялся с написанной вручную политикой.

Читать →