Агент в каждой новой сессии стартует без памяти о проекте. Он не знает, чем ставятся зависимости, какой командой гоняются тесты, какие каталоги трогать нельзя и что считать доказательством готовности. Пока это не записано, вы объясняете одно и то же в каждом промпте, а агент каждый раз восстанавливает контекст с нуля - и иногда угадывает неверно. И цена такого угадывания - не строчка в логе, а реальные правки, сделанные по неверному представлению о том, как устроен проект.
Наивный ход понятен: собрать всё, что знаешь о проекте, в один постоянный файл, который грузится всегда. Раз контекст помогает, пусть его будет побольше - архитектура, стиль, история решений, длинные процедуры. Кажется, что чем полнее always-on файл, тем реже агент ошибётся.
Ломается это на том, что always-on текст подставляется в каждый запрос. Большой файл жжёт токены на каждом turn, разбавляет внимание модели и тонет в собственном объёме: важные две строки про запрет на deploy теряются среди страницы про историю проекта. Хуже того, длинный контракт быстро расходится с репозиторием, и агент верит устаревшей строке вместо кода.
Devin решает это форматом AGENTS.md в корне репозитория - коротким переносимым контрактом, который грузится в начале сессии. Это рекомендуемый формат always-on правил: обычный Markdown, версионируется вместе с кодом и читается не только Devin. Практичная структура - три раздела: Commands (как ставить, тестировать, линтить, собирать), Boundaries (что не трогать) и Completion (чем доказывать готовность). Помимо AGENTS.md Devin понимает singular-вариант AGENT.md и legacy .windsurfrules, а то, какие ещё форматы читать - Cursor, Windsurf, Claude, - задаётся отдельным переключателем read_config_from в config.
Размещение задаёт область действия. Файл в корне грузится сразу; AGENTS.md в подкаталоге обнаруживается лениво, когда агент доходит до этой части дерева - так узкие правила модуля не висят в контексте всей работы. Личные заметки идут в AGENTS.local.md и добавляются в gitignore, чтобы не попасть в общий репозиторий. Глобальный контракт на все проекты живёт в ~/.config/devin/AGENTS.md (на Windows - в %APPDATA%\devin\). Путь .devin предпочтительнее legacy .windsurf, а знакомый ~/.claude/CLAUDE.md Devin тоже читает. Так один и тот же контракт работает и в команде через корневой файл, и лично через local-версию, и глобально поверх всех проектов - без дублирования одних и тех же строк в каждом репозитории.
Что сюда класть, а что нет - главный вопрос. В AGENTS.md кладут только универсальное и устойчивое: команды, жёсткие границы, критерии готовности. Длинную процедуру на десятки шагов выносят в skill, который подгружается по требованию, а не висит всегда; документация Devin прямо советует предпочитать skills правилам там, где это возможно, потому что навык попадает в контекст лишь когда релевантен. Хороший тест на место строки простой: если она описывает шаг за шагом, как что-то делать, это материал для навыка; если она задаёт неизменную рамку - команду, запрет, критерий, - её место в контракте.
Цена раздутого контракта не абстрактна. Каждая лишняя строка - это токены в каждом turn и отвлечённое внимание там, где нужен ответ на текущую задачу. Противоречие между файлом и реальным кодом уводит агента по ложному следу. И отдельно: AGENTS.md коммитится, поэтому секретам, ключам и токенам здесь не место - для них есть tracked config и переменные окружения, но не общий контракт.
Как выглядит рабочий минимум, проще показать, чем описать. Три коротких раздела - команды, границы, правила завершения - помещаются на один экран и покрывают большинство повторяющихся вопросов агента.
Проверять такой контракт нужно с одной оговоркой: правило направляет, но не принуждает. Фраза "не запускай deploy" в Markdown - полезная подсказка, но не граница безопасности; её честно исполнит только тот агент, который решил её исполнить. Настоящую границу создаёт permission deny, sandbox или hook с блокирующим исходом. Поэтому критичные строки контракта дублируют жёстким механизмом, а работу файла проверяют по факту: следует ли агент командам из Commands и останавливается ли на границах из Boundaries. Раздел Completion проверяют так же буквально: агент обязан показать соответствующий diff, назвать точные команды проверки и их исход и не объявлять готовность при пропущенных проверках.
Типичные провалы сводятся к трём. AGENTS.md превращают в свалку документации - и он раздувается, устаревает и перестаёт читаться. В него кладут изменчивое или секретное - и получают либо утечку, либо ложь в контексте. На него полагаются как на защиту - и удивляются, что Markdown никого не остановил. Признак один: файл растёт, а доверия к нему всё меньше. Держите контракт коротким, изменчивое уводите в skills, а критичное подкрепляйте permission - тогда AGENTS.md остаётся тем, чем должен быть: коротким постоянным контрактом, а не длинной инструкцией, которую никто не соблюдает.
# Project contract
## Commands
- Install: pnpm install --frozen-lockfile
- Test: pnpm test
- Lint: pnpm lint
- Build: pnpm build
## Boundaries
- Do not edit generated/** or migrations already shipped.
- Never read or modify .env* and key material.
- Preserve public API unless the task explicitly changes it.
## Completion
- Show the relevant diff.
- Report exact verification commands and failures.
- Do not claim completion with skipped checks.