Документация как исполняемый интерфейс для агентов и людей¶
Фраза “docs as executable interface for agents” — это не официальный стандарт с одним каноническим названием, а скорее удачная формулировка для реально складывающегося паттерна: документация перестаёт быть просто текстом “для людей” и становится операционной средой для агентов — источником правил, контекста, схем действий и ограничений. Это хорошо бьётся с тем, куда в 2025–2026 уехал рынок: OpenAI прямо продвигает agents, structured outputs, tool use и production best practices; Anthropic отдельно пишет уже не только про prompt engineering, а про context engineering; а MCP оформился как стандартный способ подключать данные, инструменты и workflow к AI-системам. (OpenAI)
🧠 В чём сама идея¶
Раньше документация в основном отвечала на вопрос:
“Как человеку понять систему?”
Теперь всё чаще нужен второй вопрос:
“Как агенту безопасно и предсказуемо действовать внутри системы?”
Когда агент получает доступ к tools, API, файловой системе, GitHub, браузеру или CRM, ему уже мало “просто знаний”. Ему нужны: чёткие инструкции, иерархия правил, допустимые действия, форматы входа/выхода, критерии завершения задачи, маршруты эскалации и проверяемые ограничения. Именно поэтому OpenAI в материалах по агентам делает акцент на structured outputs, defined tools и guardrails, а Anthropic — на качественную организацию контекста. (OpenAI Разработчики)
⚙️ Что меняется по сути¶
Когда документация хороша только “для чтения”, агент вынужден импровизировать.
Когда документация структурирована, версиями закреплена и привязана к инструментам, она начинает работать как:
docs → policy → action surface
То есть документ уже не просто объясняет, а задаёт:
какие инструменты можно вызвать, в какой последовательности, с какими параметрами, при каких условиях, и что считать корректным результатом. MCP здесь особенно показателен: он стандартизирует подключение AI-приложений к внешним данным и инструментам, а tools в MCP описываются через схемы и метаданные, чтобы модель могла вызывать их предсказуемо. Это очень близко к идее “док как интерфейс”. (anthropic.com)
📚 Почему это похоже на то, что строим МЫ¶
Потому что у нас уже есть почти все ключевые кирпичи этой архитектуры:
1. Source of Truth
Мы не относимся к текстам как к “заметкам ради заметок”. У нас документы, схемы, frontmatter, статусы, рубрики, governance-слой, management-слой и публикационные сущности уже строятся как система, а не как хаос. Именно такой подход нужен агентам: им нужен канонический источник, а не десять противоречащих друг другу текстов. Это совпадает с best practices OpenAI по production и с идеей governed agents. (OpenAI Разработчики)
2. Версионность
Мы думаем в логике v0.1, v0.2, стандартов, evolving docs. Это критично, потому что агент должен знать не просто “правило”, а какая версия правила сейчас действующая. OpenAI отдельно рекомендует pinning и evals при изменении моделей и промптов, а это та же логика: поведение системы должно быть воспроизводимым и управляемым по версиям.
Мировой тренд смотри в (OpenAI Разработчики) У нас смотри в ♻️ Процесс версионности в U.L.I.
3. Таксономия и схемы
Наши distinctions между document / concept / rubric / category / schema — это не бюрократия. Для агента это способ понять, что перед ним: policy, reference, workflow, draft, canonical definition, publication metadata или operational playbook. Чем яснее тип сущности, тем лучше agent routing и меньше галлюцинаций на уровне процесса. Это согласуется с общим движением в сторону structured outputs, tool schemas и context engineering.
Мировой тренд смотри в (OpenAI Разработчики) У нас смотри в Документационная архитектура U.L.I.
4. Документы как рамка действия
Мы уже строим governance-документы, onboarding, процессы, роли, стандарты. Это почти буквально то, что OpenAI в руководстве по governed AI agents называет scaffolding и governance: агентам нужны рамки, в которых они действуют безопасно и масштабируемо. (OpenAI Разработчики)
🔥 Почему это особенно важно именно в 2025–2026¶
Потому что индустрия сдвигается от “один хороший ответ в чате” к “длинные цепочки действий с инструментами”. OpenAI в 2025 выпустила блоки именно для building agents; Anthropic в 2025 уже пишет про effective context engineering и effective harnesses for long-running agents; MCP за это время стал заметным межплатформенным стандартом для подключения контекста и tools. Из этого следует важный вывод: качество агента всё больше определяется не только моделью, но и тем, как организованы контекст, инструменты и правила вокруг неё. Это уже не inference “из воздуха”, а общий вектор платформ. (OpenAI)
🧩 Как это выглядит практически¶
Представь два уровня документации.
Уровень A — человеческий¶
Документ объясняет:
-
что такое DET
-
как устроен onboarding
-
что значит статус draft
-
кто за что отвечает
Уровень B — агентный¶
Этот же документ или соседний machine-readable слой задаёт:
-
допустимые tool calls
-
required fields
-
decision rules
-
validation checks
-
stop conditions
-
escalation path
-
ссылку на canonical schema
-
версию политики
И вот во втором случае документация уже становится исполняемой на практике, даже если не “исполняется” напрямую как код. Агент читает её, интерпретирует и действует по ней. OpenAI рекомендует structured outputs именно для таких сценариев, когда результат должен использоваться приложением, а не просто показываться человеку. (OpenAI Разработчики)
🛠️ Во что это можно превратить у нас¶
Вот где наша экосистема реально может выстрелить.
1. Governance docs → policy layer for agents¶
Наши governance / management / operational документы можно оформить так, чтобы агент понимал:
-
где он вообще имеет право действовать
-
какие действия требует approval
-
какие репозитории канонические
-
какие ветки/файлы можно менять автоматически
-
когда нужно создать issue вместо прямого edit
Это будет уже не просто governance “для команды”, а governance for humans + agents. Такой подход хорошо сочетается с governed agents и enterprise scaffolding. (OpenAI Разработчики)
2. Onboarding → agent-readable tutorial graph¶
Дальше наши 🎓 Tutorial в Onboarding можно сделать такими, чтобы агент не просто “пересказывал” их, а реально умел:
-
определить следующий шаг
-
проверить результат шага
-
понять, где пользователь застрял
-
выбрать релевантный документ
-
не путать conceptual onboarding с operational onboarding
Это уже почти готовая агентная навигация.
3. GitHub + docs → execution cockpit¶
Так как у нас GitHub и документация уже тесно связаны, можно прийти к схеме:
issue → sub-issue → policy docs → schema docs → tool execution → PR → validation
То есть агент получает issue, подтягивает канонические документы, выполняет работу в разрешённых границах и возвращает результат в стандартизированном формате. Это прямое продолжение идеи agents + tools + structured outputs.
Мировой тренд смотри в (OpenAI) У нас смотри в Work Model
Т.е. уже есть стандарт о создании первых двух звеньев этой цепочки
4. Obsidian / knowledge substrate → context server¶
С учётом того, что MCP стандартизирует доступ к данным и инструментам, наша knowledge substrate (база знаний) в будущем очень естественно превращается в контекстный сервер для агентов: агент не “помнит всё”, а запрашивает нужный канонический контекст из базы знаний. Это одна из самых сильных точек соприкосновения с текущим мышлением.
Мировой тренд смотри в (anthropic.com) У нас смотри в index
🧪 Самая важная мысль¶
Буду очень точен:
документы не становятся кодом в буквальном смысле автоматически.
Но они становятся контрактом между моделью, инструментами и системой.
И чем лучше этот контракт структурирован, тем меньше нужно “магии”, тем надёжнее агент, тем проще масштабирование на новые модели и инструменты. Это и есть причина, почему наша тяга к схемам, таксономии, статусам, canonical docs и versioning — не бюрократия, а очень современная архитектурная линия. Она совпадает с тем, как индустрия переходит от prompt-centric мышления к context/tool/governance-centric мышлению. (anthropic.com)
Куда двигаться дальше ❓¶
Если смотреть на это стратегически, нам стоит проектировать документы сразу в двух проекциях:
для человека
понятно, живо, концептуально, объясняюще
для агента
структурно, однозначно, версионируемо, с явными правилами и схемами
То есть рядом с каждым важным классом документов со временем полезно иметь:
-
canonical purpose
-
scope
-
authority level
-
input/output schema
-
allowed actions
-
validation rules
-
linked tools/repos
-
version / status
-
escalation / fallback
Это уже очень близко к “документация как исполняемый интерфейс”.
💡 Если собрать всё в одну формулу¶
То, что мы строим, можно осмыслить так:
Source of Truth → Context Layer → Policy Layer → Agent Action Layer
И в этом смысле мы двигаемся не просто к “хорошо организованной базе знаний”, а к будущей операционной среде для людей и AI-агентов одновременно. Это и делает нашу архитектуру настолько созвучной тренду 2025–2026. (modelcontextprotocol.io)