Forward-deployed значит, что я работаю внутри вашего репозитория и вашего стека, а не в стороннем Slack-канале. Я пишу и довожу до прода код, который закрывает разрыв между рабочим демо и системой, которую можно оставить включённой. Обычно это retrieval grounding, покрытие evals, границы инструментов и путь отката. Артефакт работы - коммиты и runbook, а не слайды.
Нужна, когда задача проходит через несколько инструментальных поверхностей, не помещается в один контекст модели или требует подписанного аудита по каждому шагу. Лишняя, когда один правильно настроенный агент с жёсткими границами инструментов уже справляется. Bernstein сделан под первый случай. Если ваш workflow - это один промпт и один инструмент, вам нужен не оркестратор, а нормальные evals.
Демо-запросы дружелюбные, а реальный трафик нет. Поисковик молча возвращает правдоподобный, но неверный контекст, модель пишет уверенный текст вокруг него, и ничто в стеке этого не ловит. Что обычно чиню: гибридный retrieval, форма ответа со ссылками на страницы и eval-набор с состязательными запросами, которые фиксируют реальные сбои, а не те, что воображает фреймворк.
Когда нагрузка касается регулируемых данных, изолированной сети или LLM-шлюза на стороне клиента, мимо которого вы пройти не можете. Bernstein держит состояние в файлах, расписание детерминированное, доступы scoped по агенту - всё внутри вашего периметра. Никаких неавторизованных исходящих вызовов. Тот же оркестратор работает на ноутбуке, в CI и на закрытой VM - обычно именно это хочет увидеть compliance.
Каждое изменение уезжает с gold-набором входов, детерминированным судьёй и fail-closed гейтом в CI. Новые сбои фиксируются как eval-кейсы до того, как уезжает фикс, чтобы регрессия не вернулась незаметно. Оркестратор записывает каждый шаг агента, и когда метрика проседает, можно проиграть тот самый прогон. Без релизов на ощущениях.
