Автор: Редакция Comb
Онтология помогает агенту понять мир компании. Skills дают способы выполнения работы. Знания содержат факты, Tools позволяют действовать. AGENTS.md задаёт правила, по которым агент использует эти слои и понимает, где заканчивается его автономия.
Содержание статьи 01 Что такое AGENTS.md
02 Важно: это наша архитектурная интерпретация
03 Где AGENTS.md находится в архитектуре
04 AGENTS.md и Skill - разные вещи
05 Что должно быть в AGENTS.md операционного агента
06 Роль: не «ты лучший менеджер»
07 Goal: что считается хорошим результатом
08 Источники истины
09 Маршрутизация к Skills
10 Границы автономии
11 Эскалация - нормальная ветка
12 Сквозной пример: встреча с «Севером»
13 Один мир - разные агенты
14 AGENTS.md юридического агента
15 Где находится Trigger
16 Не превращайте AGENTS.md в энциклопедию
17 Контекст нужно раскрывать постепенно
18 Больше инструкций не значит лучше
19 Что действительно стоит писать
20 Как подготовить первый AGENTS.md
21 Ошибка должна исправлять правильный слой
22 Кто должен владеть AGENTS.md
23 Иерархия правил может повторять компанию
24 Сотрудник и AI-сотрудник
25 Минимальный шаблон AGENTS.md
26 Не ещё один Markdown-файл
Онтология помогает агенту понять мир компании. Skills дают способы выполнения работы. Знания содержат факты, Tools позволяют действовать. AGENTS.md задаёт правила, по которым агент использует эти слои и понимает, где заканчивается его автономия.
В предыдущих материалах мы разбирали несколько частей корпоративной агентной системы.
Первая - онтология компании . Она описывает мир, в котором работает агент: клиентов, сотрудников, договоры, сделки, товары, задачи, платежи и связи между ними.
Вторая - Agent Skills . Навыки позволяют вынести способы выполнения повторяемой работы в отдельные инструкции: как подготовиться к встрече, проверить договор, обработать заявку или сравнить предложения поставщиков.
Есть и отдельная статья о том, как онтология и навыки работают вместе : агент понимает ситуацию и выбирает подходящий способ действия.
Онтология компании: как дать AI-агентам понимание бизнеса
Как онтология и навыки соединяются в работе AI-агента
Agent Skills и репозитории навыков
Но этого всё ещё недостаточно.
Допустим, менеджер пишет:
Подготовь меня к встрече с клиентом «Север».
Агенту нужно понять:
кто такой «Север»;
какие связанные объекты нужны;
какой Skill использовать;
где искать переписку;
откуда брать текущую цену;
какому источнику доверять при расхождении;
какие действия разрешены;
когда нужно передать решение человеку.
Онтология не отвечает на все эти вопросы.
Skill тоже.
Нужны постоянные правила работы самого агента.
Для coding agents такие инструкции уже принято хранить в AGENTS.md .
Но эта идея полезна далеко за пределами разработки.
01 Что такое AGENTS.md
AGENTS.md - обычный Markdown-файл с инструкциями для AI-агента.
Формат появился в экосистеме программных агентов и сегодня поддерживается разными инструментами, включая Codex и GitHub Copilot. Открытая спецификация описывает его как своего рода README для агентов - предсказуемое место, где агент получает инструкции перед началом работы. 1 2 3
Каноническое название - AGENTS.md , во множественном числе.
У файла нет обязательной схемы.
Например:
# Project rules
Перед изменением API прочитай docs/api.md.
После изменения схемы данных запусти тесты.
Не изменяй generated-файлы вручную.
Для frontend используй правила frontend/AGENTS.md.
AGENTS.md может находиться на разных уровнях проекта:
project/ AGENTS.md
backend/ AGENTS.md
frontend/ AGENTS.md
Более локальные инструкции уточняют общие.
Для бизнеса можно представить похожую структуру:
company/ AGENTS.md
sales/ AGENTS.md
legal/ AGENTS.md
procurement/ AGENTS.md
finance/ AGENTS.md
Так появляется возможность хранить постоянные правила работы AI-агентов рядом с функциями компании.
02 Важно: это наша архитектурная интерпретация
Сам стандарт AGENTS.md не говорит:
используйте этот файл как корпоративный маршрутизатор между онтологией, знаниями и Skills.
Это уже следующий шаг.
Мы переносим паттерн из разработки на операционную работу компании.
В такой архитектуре AGENTS.md удобно использовать как управляющий слой на уровне инструкций .
Он может задавать:
тип задачи → нужный Skill
тип объекта → нужный контекст
тип данных → источник истины
тип действия → нужный Tool
условие риска → человек
Сам Markdown ничего не исполняет.
Он только содержит правила.
Реальную загрузку контекста, вызов Skills, доступ к системам и approval обеспечивает агентный harness . 4
Поэтому точная формулировка такая:
AGENTS.md задаёт правила маршрутизации. Harness исполняет эту маршрутизацию.
03 Где AGENTS.md находится в архитектуре
Получается такая модель:
Управляющий слой · от задачи к контролю
Задача Что нужно сделать?
AGENTS.md Правила выбора контекста, Skill, источника, Tool и границы автономии
Онтология Что существует?
Skills Как выполнить?
Knowledge Что известно?
Tools Где читать данные и через что действовать?
Result Проверяемый результат
Human Approval при выходе за границы
Evals + Guardrails Правильно и безопасно ли сработал маршрут?
↺ улучшение правил, навыков и знаний
AGENTS.md задаёт правила маршрутизации, а harness исполняет их через контекст, навыки, знания, инструменты и approval. У каждого слоя своя задача.
Слой Главный вопрос
Онтология Что существует в компании и как связано?
AGENTS.md Как мне работать в этой ситуации?
Skills Как выполнить конкретную работу?
Knowledge Что компания знает?
Tools Где получить данные и через что действовать?
Evals / Guardrails Правильно и безопасно ли всё произошло?
04 AGENTS.md и Skill - разные вещи
Это главное разделение.
AGENTS.md отвечает:
Как должен работать этот агент вообще?
Skill:
Как выполнить конкретный тип работы?
Например:
AGENTS.md
Кто я? Чему доверять? Что мне разрешено? Какой Skill выбрать? Когда нужен человек?
А:
skills/ contract-review/ client-call-preparation/ proposal-preparation/ tender-analysis/
содержат конкретные способы выполнения работы.
Простая формула:
AGENTS.md управляет применением компетенций.
Skill содержит компетенцию. 5 6
05 Что должно быть в AGENTS.md операционного агента
Для бизнес-процессов структура будет отличаться от файла разработчика.
Полезно зафиксировать:
роль;
цель;
область ответственности;
источники истины;
правила выбора Skills;
границы автономии;
условия эскалации;
формат результата.
Это уже не «промпт персонажа».
Это управляющая инструкция рабочего места агента .
06 Роль: не «ты лучший менеджер»
Фраза:
Ты опытный менеджер с 20-летним стажем.
почти ничего не объясняет про реальную работу.
Лучше:
## Role
Ты - агент менеджера по работе с корпоративными клиентами.
Твоя задача - собирать достоверный контекст, готовить варианты решения и выполнять разрешённые операционные действия.
Коммерческие обязательства от имени компании принимает человек.
Теперь определена функция агента.
07 Goal: что считается хорошим результатом
Например:
## Goal
После подготовки к встрече менеджеру не должно требоваться самостоятельно искать основные данные о клиенте.
Результат должен содержать:
- текущую ситуацию; - открытые обязательства; - последние существенные контакты; - риски; - вопросы для обсуждения; - рекомендуемое следующее действие.
Фраза «сделай качественно» почти ничего не определяет.
Такой критерий уже можно проверять.
08 Источники истины
Представим, что цена товара найдена одновременно:
в CRM;
в письме;
в старом коммерческом предложении;
в 1С.
Какое значение актуально?
Для опытного сотрудника ответ может быть очевиден.
Для модели - нет.
Поэтому вместо:
Проверяй информацию.
лучше:
## Sources of truth
Клиент, контакты и сделки: CRM.
Текущие цены и остатки: 1С.
Фактическая переписка: корпоративная почта.
Действующие договорные условия: последняя подписанная версия договора.
При конфликте источников не выбирай значение самостоятельно.
Покажи расхождение.
Это уже правило принятия решения. 7
09 Маршрутизация к Skills
Допустим, у менеджера есть несколько регулярных задач:
skills/ client-call-preparation/ proposal-preparation/ meeting-follow-up/ account-review/
В AGENTS.md достаточно написать:
## Routing
Встреча или звонок с клиентом: client-call-preparation.
Коммерческое предложение: proposal-preparation.
Завершившаяся встреча: meeting-follow-up.
Периодический анализ клиента: account-review.
Сам способ выполнения работы остаётся в Skill.
Например:
# Client Call Preparation
1. Однозначно определить клиента.
2. Получить: - активные сделки; - задачи; - последние контакты; - заказы; - задолженность; - обязательства.
3. Проверить критичные факты.
4. Найти конфликты.
5. Сформировать briefing.
Так AGENTS.md не превращается в склад всех процессов компании.
10 Границы автономии
После выбора Skill и получения данных возникает следующий вопрос:
Что агент может сделать с результатом?
Удобно разделить действия на три группы.
Всегда
Можно выполнять самостоятельно:
читать;
искать;
сравнивать;
считать;
классифицировать;
готовить черновики;
формировать внутренние резюме.
Сначала спросить
Нужно подтверждение:
отправить внешнее письмо;
изменить цену;
предоставить скидку;
перенести срок;
изменить существенное условие договора;
изменить критичные данные.
Никогда
Не выполнять автономно:
подписывать договор;
проводить платёж;
удалять критичные данные;
обходить права доступа;
принимать юридически значимое обязательство.
Это тоже маршрутизация.
Только теперь не к системе или Skill, а:
решение │ ├── можно → действие │ ├── нужно согласование → человек │ └── запрещено → stop
Но важно: Markdown сам по себе не является механизмом безопасности.
Если агент не должен проводить платёж, это ограничение должно существовать и на уровне прав, API и approval.
11 Эскалация - нормальная ветка
Хороший агент должен понимать не только:
Что делать дальше?
Но и:
Когда дальше идти нельзя?
Например:
## Escalation
Передай решение человеку, если:
- отсутствуют обязательные данные; - источники истины противоречат друг другу; - ситуация не покрыта правилами; - требуется финансовое обязательство; - возникает существенный юридический риск; - требуется необратимое действие.
Эскалация - не сбой.
Это предусмотренный маршрут.
12 Сквозной пример: встреча с «Севером»
Кейс «Север» · от запроса к решению
01 Запрос Подготовь меня к встрече с «Севером»
02 AGENTS.md Правила, источники истины и границы
03 Онтология Клиент, сделки, договоры, платежи
04 Skill client-call-preparation
05 Tools CRM · 1С · почта · телефония
06 Конфликт → briefing Данные нельзя скрывать или усреднять CRM · 1 240 ₽ Письмо · 1 190 ₽ 1С · 1 270 ₽
Запрос проходит через правила AGENTS.md, онтологию, Skill и Tools; конфликт данных становится явным решением для человека. Менеджер пишет:
Подготовь меня к встрече с «Севером».
1. AGENTS.md определяет маршрут
Агент знает:
это подготовка к встрече → client-call-preparation
объект работы → клиент
сделки и задачи → CRM
цены и остатки → 1С
история коммуникации → почта и телефония
конфликт данных → не скрывать
изменение коммерческих условий → решение человека
AGENTS.md не выполняет остальные шаги.
Он задаёт правила их выбора.
2. Онтология помогает понять объект
Агент определяет:
Север ↓ Клиент
И видит связанные сущности:
Клиент ├── Контакты ├── Сделки ├── Договоры ├── Предложения ├── Заказы ├── Платежи ├── Встречи └── Задачи
Онтология помогает понять, какой контекст относится к клиенту .
3. Skill задаёт способ выполнения работы
client-call-preparation определяет:
что собрать;
что проверить;
какие конфликты искать;
как сформировать briefing.
4. Tools дают факты
Агент получает:
CRM: последняя цена - 1 240 ₽.
Письмо: клиенту называли 1 190 ₽.
1С: текущая цена - 1 270 ₽.
5. Правила определяют следующий шаг
Актуальная цена должна браться из 1С.
Но прежнее предложение клиенту нельзя игнорировать.
Поэтому агент не сообщает просто:
Цена - 1 270 ₽.
Он пишет:
В 1С текущая цена 1 270 ₽. В последнем письме клиенту называли 1 190 ₽. До встречи нужно определить, сохраняются ли прежние условия.
Маршрут переходит к человеку.
6. Менеджер получает решение
Клиент: Север
Ситуация: готовится повторный заказ.
Что обещали: 1 190 ₽.
Текущая цена: 1 270 ₽.
Риск: клиент может ожидать старую цену.
Нужно решение: сохраняем прежние условия или сообщаем новую цену.
Следующее действие: согласовать позицию до разговора.
Здесь видно назначение каждого слоя:
онтология помогла понять контекст;
Skill объяснил способ работы;
Tools дали факты;
AGENTS.md определил правила выбора и момент передачи решения человеку.
13 Один мир - разные агенты
Разные агенты могут видеть один объект, но работать с ним по-разному.
Например:
Договор ↓ Изменено ограничение ответственности
Агент менеджера:
обнаружить → передать Legal
Юридический агент:
обнаружить → contract-review → проверить правила → подготовить оценку → при необходимости юрист
Агент руководителя:
увидеть риск → получить ответственного → проверить состояние согласования
Онтология одна.
Объект один.
Но правила роли задают разные маршруты.
14 AGENTS.md юридического агента
# Legal Agent
## Role
Ты - агент юридической функции.
Ты выполняешь первичный анализ, сравнение документов, поиск отклонений и подготовку проектов.
Финальное юридическое решение принимает человек.
## Goal
Сократить ручную работу юриста, не принимая за него решения, создающие обязательства компании.
## Sources of truth
Подписанный договор: действующие договорные условия.
Legal playbook: правила оценки договорных положений.
Официальные источники: актуальные нормы законодательства.
## Routing
Новый юридический запрос: legal-intake.
Проверка договора: contract-review.
Сравнение редакций: contract-redline.
Юридическое исследование: legal-research.
## Always
Можно:
- извлекать условия; - сравнивать документы; - искать отклонения; - готовить таблицу рисков; - готовить redline; - находить связанные правила; - указывать источники выводов.
## Ask First
Передай решение юристу при:
- нестандартном ограничении ответственности; - отказе от утверждённой защиты; - изменении применимого права; - существенном изменении SLA; - неизвестном типе риска.
## Never
Не:
- принимай юридические обязательства; - выдавай предположение за факт; - считай прошлый договор корпоративной политикой; - отправляй финальную редакцию без согласования.
## Escalation
Немедленная эскалация:
- судебное разбирательство; - регулятор; - санкции; - существенный штраф; - риск, не покрытый правилами компании.
Здесь AGENTS.md не содержит всю юридическую работу.
Он направляет агента к нужному Skill, источнику или человеку.
15 Где находится Trigger
В операционной системе должен существовать ещё один элемент:
Что запускает работу?
Например:
новое письмо; новый договор; новый лид; тикет; изменение статуса; наступление срока; расписание; команда сотрудника.
Но Trigger лучше не смешивать с ролью AGENTS.md .
Архитектурно:
Trigger ↓ Harness запускает агента ↓ AGENTS.md задаёт правила ↓ Ontology / Skills / Knowledge / Tools
Trigger запускает.
AGENTS.md направляет.
Harness исполняет.
16 Не превращайте AGENTS.md в энциклопедию
Если файл используется как карта рабочей среды, ему не нужно содержать всю эту среду.
Плохой вариант:
AGENTS.md
200 страниц: все знания; все процессы; все правила; все примеры; вся структура компании.
Лучше:
company/ AGENTS.md
ontology/ ...
knowledge/ ...
policies/ ...
skills/ client-call-preparation/ proposal-preparation/ contract-review/
AGENTS.md должен говорить:
Что мне сейчас нужно и где это находится?
а не:
Вот вообще всё, что знает компания.
17 Контекст нужно раскрывать постепенно
Если агент готовится к встрече, ему не нужна инструкция по расторжению договора.
Если анализирует тендер - не нужны все навыки поддержки.
Поэтому рабочая модель выглядит так:
Задача ↓ AGENTS.md ↓ определение ситуации ↓ нужная часть онтологии ↓ нужный Skill ↓ нужные знания ↓ нужные Tools ↓ действие
Агент получает подробности по мере необходимости.
Так можно уменьшить шум в контексте и не заставлять модель каждый раз читать всю компанию.
18 Больше инструкций не значит лучше
Исследования repository-level instructions вроде AGENTS.md уже дают разные результаты.
В одной работе дополнительные инструкции увеличивали количество действий и стоимость выполнения более чем на 20%, не давая сопоставимого роста качества. 8
В другой наличие AGENTS.md было связано со снижением медианного времени выполнения примерно на 28,6% и количества выходных токенов примерно на 16,6%. 9
Поэтому некорректно говорить:
Наличие AGENTS.md автоматически делает агента эффективнее.
Полезнее другой вывод:
агент действительно следует постоянным инструкциям, поэтому качество этих инструкций имеет значение.
Лишнее правило может породить лишнее действие.
19 Что действительно стоит писать
Хороший тест:
Изменит ли правило выбор следующего действия агента?
Например:
Будь внимательным.
Скорее всего, нет.
Работай профессионально.
Нет.
А вот:
Перед подготовкой предложения проверь текущую цену в 1С.
Да.
Для проверки договора используй contract-review .
Да.
При конфликте источников не продолжай молча.
Да.
Перед внешней отправкой запроси подтверждение.
Да.
Хороший AGENTS.md состоит прежде всего из правил принятия решений и выбора следующего шага .
20 Как подготовить первый AGENTS.md
Не стоит начинать с генерации идеального шаблона.
Начинать лучше с реальной работы сотрудника. 10
1. Возьмите 20-30 реальных кейсов
Для менеджера:
встречи; письма; предложения; сложные сделки; претензии; ошибки; исключения.
Для юриста:
договоры; правки контрагента; запросы сотрудников; согласования; претензии; нестандартные условия.
2. Ищите развилки
Самые полезные вопросы:
Почему ты пошёл именно в эту систему?
Почему использовал этот процесс?
Почему передал вопрос руководителю?
Почему не отправил ответ сразу?
Например:
Почему цена проверяется в 1С?
Потому что CRM может содержать старое значение.
Получили правило.
Почему договор сразу ушёл юристу?
Потому что изменён лимит ответственности.
Получили ещё одно.
3. Отделите правила от фактов
Директор по закупкам - Иванов.
Это факт.
Ему место в справочнике или онтологии.
А:
Закупки более 3 млн требуют согласования директора по закупкам.
Это правило.
сумма > 3 млн → approval директора по закупкам
Вот это уже материал для операционных инструкций.
4. Зафиксируйте источники истины
Для каждого типа данных:
актуальная цена → ?
остаток → ?
действующий договор → ?
статус сделки → ?
переписка → ?
результат встречи → ?
И отдельно:
что делать, если источники расходятся?
5. Зафиксируйте выбор Skills
встреча с клиентом → client-call-preparation
коммерческое предложение → proposal-preparation
новый договор → contract-review
тендер → tender-analysis
6. Опишите границы
Для каждого значимого действия:
делает агент;
нужно подтверждение;
делать нельзя.
7. Проверяйте не только ответы, но и маршруты
После появления AGENTS.md нужен eval-набор реальных задач.
Проверять стоит:
правильно ли определён объект;
правильно ли выбран Skill;
правильно ли выбран источник;
не загружен ли лишний контекст;
правильно ли выбран Tool;
правильно ли произошла эскалация;
не выполнено ли запрещённое действие.
Для управляющего слоя это не менее важно, чем качество финального текста.
21 Ошибка должна исправлять правильный слой
Когда агент ошибся, не нужно автоматически дописывать ещё одно правило в AGENTS.md .
Сначала стоит определить причину.
Проблема Где исправлять
Агент неправильно понял объект Онтология
Не нашёл нужный факт Knowledge / источник
Выбрал неправильный маршрут AGENTS.md
Неправильно выполнил работу Skill
Получил лишнее полномочие Tools / Permissions
Не остановился перед риском Guardrail / AGENTS.md
Ошибка не выявлялась Evals
Так каждый слой остаётся управляемым.
22 Кто должен владеть AGENTS.md
Если AGENTS.md становится частью операционной архитектуры, бизнес не может полностью передать его разработчикам.
Для Sales-агента коммерческая функция должна определять:
какие источники считать актуальными;
какие Skills применять;
когда требуется согласование;
какие действия разрешены.
Для Legal - юридическая функция.
Для Finance - финансовая.
Техническая команда обеспечивает:
загрузку инструкций;
доступ к Skills;
интеграции;
права;
логи;
approval;
guardrails;
evals.
Получается простое разделение:
бизнес определяет правила работы.
Платформа обеспечивает их исполнение.
23 Иерархия правил может повторять компанию
Наследование · компания → функция → Skill
company/ AGENTS.md · общие правила компании
sales/ AGENTS.md · правила продаж
skills/ Способы работы функции
client-call-preparation/
proposal-preparation/
legal/ AGENTS.md · правила юридической функции
skills/ Способы работы функции
legal-intake/
contract-review/
Общие инструкции уточняются на уровне функции; доступное наследование и загрузку правил обеспечивает harness. Можно представить:
company/ AGENTS.md
sales/ AGENTS.md
skills/ client-call-preparation/ proposal-preparation/
legal/ AGENTS.md
skills/ legal-intake/ contract-review/
На уровне компании:
Не скрывать конфликт источников.
Высокорисковые действия требуют подтверждения.
Не обходить права пользователя.
На уровне продаж:
Цена → 1С.
Встреча → client-call-preparation.
Скидка > 10% → руководитель.
На уровне Legal:
Новый договор → contract-review.
Изменение liability → юрист.
Законодательство → официальный источник.
Так общие правила дополняются правилами функции и конкретной роли.
24 Сотрудник и AI-сотрудник
Рабочее место · шесть соответствий
Сотрудник AI-сотрудник
Понимание устройства бизнеса
Онтология
Роль и полномочия
AGENTS.md
Опыт и методы работы
Skills
Корпоративные знания
Knowledge
CRM, 1С, почта
Tools
Руководитель и контроль качества
Approvals + Evals
Неявные ориентиры обычного сотрудника раскладываются для AI-сотрудника на отдельные машиночитаемые слои. У человека большая часть маршрутизации существует в голове:
Где искать?
Какую процедуру использовать?
Кого спросить?
Можно ли сделать самому?
Чтобы AI-сотрудник мог работать устойчиво, эту логику приходится делать явной.
25 Минимальный шаблон AGENTS.md
# [Название агента]
## Role
Кто агент и какую функцию выполняет.
## Goal
Что считается хорошим результатом.
## Scope
С какими объектами и задачами работает.
## Routing
Тип задачи → Skill.
Тип данных → источник истины.
Условие риска → человек.
## Sources of truth
Где находятся актуальные данные.
Что делать при конфликте источников.
## Always
Что агент выполняет самостоятельно.
## Ask First
Что требует подтверждения.
## Never
Что агент не выполняет автономно.
## Skills
Какие навыки доступны и когда их использовать.
## Escalation
Когда остановиться и передать задачу человеку.
## Output
Как должен выглядеть результат.
Раздел Routing здесь не является частью официальной спецификации AGENTS.md .
Это предлагаемая структура для операционных AI-агентов .
Именно она помогает сделать скрытую логику работы сотрудника явной.
26 Не ещё один Markdown-файл
Главная идея AGENTS.md для бизнеса не в самом Markdown.
И даже не в стандарте.
Большая часть операционной работы опытного сотрудника состоит из постоянного выбора:
Что сейчас происходит?
Где искать информацию?
Какую процедуру применить?
Какому источнику доверять?
Можно ли действовать самому?
Когда нужен другой человек?
Для сотрудника эта логика часто существует неявно - как опыт.
Для AI-сотрудника значительную её часть приходится формализовать.
Онтология даёт агенту модель мира компании .
Skills - способы выполнения работы .
Knowledge - знания и факты .
Tools - доступ к реальным системам .
А AGENTS.md задаёт постоянные правила, по которым агент выбирает между этими возможностями и определяет следующий шаг .
Сам маршрут исполняет harness.
Но именно инструкции отвечают агенту:
Что это за ситуация?
Куда обратиться?
Какой Skill использовать?
Какому источнику доверять?
Через какой инструмент действовать?
И где остановиться и передать решение человеку?
В таком виде AGENTS.md становится гораздо более интересной идеей, чем просто README для coding agent.
Это способ начать записывать операционную логику компании в форме, по которой AI-сотрудник способен ориентироваться и работать .
ИСТ Источники
01 https://agents.md/ "AGENTS.md — open format for guiding coding agents"
02 https://openai.com/index/unrolling-the-codex-agent-loop/ "OpenAI — Unrolling the Codex agent loop"
03 https://docs.github.com/en/copilot/how-tos/configure-custom-instructions-in-your-ide/add-repository-instructions-in-your-ide "GitHub Docs — AGENTS.md hierarchy"
04 https://openai.com/index/harness-engineering/ "OpenAI — Harness engineering"
05 https://docs.github.com/en/copilot/concepts/agents/code-review "GitHub Docs — AGENTS.md vs Skills"
06 https://docs.github.com/en/copilot/concepts/agents/about-agent-skills "GitHub Docs — About agent skills"
07 https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/declarative-agent-instructions "Microsoft Learn — Write effective instructions for declarative agents"
08 https://arxiv.org/abs/2602.11988 "Gloaguen et al. — Evaluating AGENTS.md"
09 https://arxiv.org/abs/2601.20404 "Lulla et al. — On the Impact of AGENTS.md Files"
10 https://www.stackai.com/insights/training-non-technical-teams-to-build-ai-agents-the-complete-upskilling-guide "StackAI — Training Non-Technical Teams to Build AI Agents"
В материале
01 Что такое AGENTS.md
02 Важно: это наша архитектурная интерпретация
03 Где AGENTS.md находится в архитектуре
04 AGENTS.md и Skill - разные вещи
05 Что должно быть в AGENTS.md операционного агента
06 Роль: не «ты лучший менеджер»
07 Goal: что считается хорошим результатом
08 Источники истины
09 Маршрутизация к Skills
10 Границы автономии
11 Эскалация - нормальная ветка
12 Сквозной пример: встреча с «Севером»
13 Один мир - разные агенты
14 AGENTS.md юридического агента
15 Где находится Trigger
16 Не превращайте AGENTS.md в энциклопедию
17 Контекст нужно раскрывать постепенно
18 Больше инструкций не значит лучше
19 Что действительно стоит писать
20 Как подготовить первый AGENTS.md
21 Ошибка должна исправлять правильный слой
22 Кто должен владеть AGENTS.md
23 Иерархия правил может повторять компанию
24 Сотрудник и AI-сотрудник
25 Минимальный шаблон AGENTS.md
26 Не ещё один Markdown-файл
Следующая статья: Agent Skills: как превратить процессы компании в навыки агентов