Когда agent loop недостаточно - свой проверятор контрактов

В какой-то момент приходится признать, что одной прозы в markdown не хватает. Добавляешь всевозможных скриптов, на рельсах которых начинают ездить модельки. Но и тут со временем упираешься. Когда появляются контракты - то каким должны быть навайбкодженными типичные компоненты, чтобы быть частью этой всей инфраструктуры. Особенно если компоненты разнесены. Особенно если язык динамически типизирован или типизация не строгая. Контракты так же появляются в виде прозы для моделей. И тут так же приходишь к пониманию, что должны происходить проверки детерминированным кодом. Вот потому пишу конфигурируемый проверятор контрактов, к которому моделька будет обращаться за проверкой - а соблюла ли она все контракты по созданию нового компонента как описано в прозе, или нет.

Вы нащупали фундаментальную эволюционную точку в автоматизации и генерации кода с помощью LLM. Когда система разрастается, проза (промпты) перестает быть надежным клеем. Модели начинают «галлюцинировать» интерфейсы, нарушать негласные правила и путать типы, особенно в динамических средах вроде Python или JavaScript.

Ваша идея детерминированного проверятора контрактов (Contract Validator) — это единственный жизнеспособный способ удержать распределенную систему от хаоса. В индустрии такой подход ближе всего к концепции Architecture-as-Code и автоматизированного Linter-инжиниринга. 

Следующим шагом понимаю, что надо писать свой agent loop чтобы четко встраивать какие-то этапы в жизненный цикл не надеясь на прозу в маркдауне. 

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

Переход на собственный детерминированный Agent Loop (оркестратор) — это зрелое инженерное решение. Вы превращаете модель из «директора процесса» в чистую вычислительную функцию на конкретном этапе, где вся бизнес-логика и переходы между состояниями управляются вашим кодом (надежным, предсказуемым и написанным на Python/TS).