Кстати, всё забываю поделиться лайфхаком.

В своей работе (программирование) у меня есть следующий AI workflow для работы с повторяющимися проблемами:

1) В ходе работы над задачей агенты записывают какие их решения, действия были неудачными, не приблизили решение, но потратили токены и время на бесполезные или временные действия. Эти записи сохраняются как список md файлов со ссылкой на задачу и кратким контекстом.

2) По завершении работы работы этот анализ ретроспективно повторяется чтобы не были упущены длинные отклонения "от оптимального маршрута решения".

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

4) Следующий агент читает эту папку "повторяющихся проблем" и думает как можно предотвратить дальнейшее повторение таких ситуаций - модификация базы знаний репозитория и/или проекта (кстати это отдельный вопрос который я подниму чуть позднее), инструкции агентов, скиллы, исправления инструментов и т.п. Агент сам оценивает сложность изменений - требуется ли ревью, проверка человеком (предлагает мне) или делает исправление самостоятельно. Моделирует проблемную ситуацию и проверяет что исправление улучшает процесс, если решит что полезно - записывает как тестовый сценарий, новую метрику и т.п., смотрит как влияет на прочие метрики.

Таким образом инструкции агентов, их скиллы, инструменты постоянно и автоматически совершенствуются при моём минимальном участии и контроле.

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

И это очевидно может быть перенесено и в любые другие сценарии использования ИИ, в том числе инженерные.

UPD: через 3 часа после написания придумал как улучшить это — используя подход
https://github.com/Avinash-jetwani/jevmem
в котором база знаний наполняется дешёвым Jev которой перехватывает переписку хуками.

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