Некоторые роли повторяются из задачи в задачу: проверить изменения публичного API, пройтись по diff на предмет регрессий, осмотреть код без права его трогать. Встроенные профили субагентов универсальны, а такая роль - узкая и постоянная, и каждый раз описывать её заново в промпте расточительно и ненадёжно.

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

Ломается это на дрейфе объёма. Универсальный агент, которому дали задачу ревьюера, всё равно вооружён записью и exec; стоит инструкции чуть ослабнуть - и он выходит за роль, потому что технически может. Роль, живущая только в словах промпта, не имеет границы: она держится на дисциплине формулировки, а не на механизме, и потому ненадёжна ровно там, где важна.

Профессиональный механизм - вынести роль в отдельный файл-профиль субагента. Project-профиль живёт в .devin/agents/<name>.md или .devin/agents/<name>/AGENT.md; поддерживается и кросс-инструментальный путь .agents/agents/. Во frontmatter - имя, описание и allowed-tools, в теле - собственно инструкции роли. Такой профиль лежит в репозитории, читается на ревью и переносится вместе с проектом.

Ключевая деталь здесь - allowed-tools. Это не пожелание в тексте, а граница исполнения: субагент с allowed-tools из read, grep и glob физически не может писать в файлы, как бы ни была сформулирована его задача. Роль перестаёт держаться на дисциплине промпта и начинает держаться на списке разрешённых инструментов - то есть на том же принципе, что и вся permission-модель Devin Local.

Как это выглядит на практике, показывает короткий профиль ревьюера контракта API. Frontmatter задаёт имя, человекочитаемое описание и три read-only инструмента; тело формулирует узкую задачу - осмотреть diff без изменения файлов, проверить status codes, схему запроса и ответа, обратную совместимость и негативные случаи, вернуть findings с указанием file:line и severity. Ничего сверх этого профиль сделать не даст.

Формат таких профилей на дату среза экспериментальный, и это диктует стиль. Держите определения маленькими и по одной ясной роли на файл; не закладывайте в них много логики, которая может не пережить смену формата, и сверяйтесь с changelog, прежде чем полагаться на конкретное поле. Маленький профиль легче и проверить, и починить, когда формат сдвинется.