Вашому ШІ-агенту не потрібен більше контексту. Йому потрібний мозок, якому він може довіряти.

Уявіть собі, що о 02:14 спрацьовує пейджер. Ви відкриваєте посібник — він виглядає чудово: існують пронумеровані кроки, діаграма, чіткі ознаки того, що хтось приділив цьому увагу. Ви виконуєте крок 4, але все зазнає невдачі. У нижній частині сторінки ви бачите дату останньої зміни: чотирнадцять місяців тому.

Кожне речення в ньому було правильним у день написання. Але не було жодних ознак того, що він вже застарів.

Ось у чому справжня проблема. Це не відсутність документації чи її погана якість. Це документація, яка виглядає такою ж надійною у свій найгірший момент, як і в перший. Протягом сорока років програмне забезпечення випускалося за правилом, що документація — це проза, і читач сам оцінює її. Потім репозиторії потрапили до агентів, які не можуть нічого оцінити та які читають кожне слово з абсолютною впевненістю.

Що змінилося

Штучний інтелект-агент не має власної пам’яті. Він є безстановим, і щоразу під час нового кроку вся розмова надсилається знову з початку. У документації Anthropic це сформульовано прямо: щоразу потрібно надсилати повну історію розмови.

Отже, документ з архітектурою на 4 000 токенів, який завжди завантажується агентом, не читається лише один раз. Під час сесії з сорока кроками він читається сорок разів. А його завантаження може погіршити роботу агента.

Дослідження Chroma щодо зміни контексту перевірило 18 передових моделей, серед них GPT, Claude, Gemini та Qwen, і показало, що точність знижується зі збільшенням обсягу вхідних даних — у деяких випадках з 95% до 60%. Важливо знати, що це не ефект, близький до межі можливостей; погіршення спостерігалося на кожному рівні обсягу даних, який вони вимірювали. Якщо ці результати будуть підтверджені, навіть вікно обсягом у мільйон токенів почне погіршувати свою роботу вже на рівні п’ятдесяти тисяч токенів, адже проблемою є шум, а не обмежена ємність.

Anthropic описує це як бюджет уваги: контекст — це обмежений ресурс із зменшуваними граничними вигодами, а метою є використання найменшої можливої кількості токенів із високою інформативністю. Це залишає два погані варіанти.

• Завантажувати все. Агент знає систему, але його продуктивність на кожному завданні значно знижується, а кожна зміна документа скасовує весь кеш запитів та змушує перезавантажувати його.
• Не завантажувати нічого. Агент залишається ефективним, але нічого не знає, тому змушений імпровізувати. Він вигадує кроки для виконання завдання або запускає команду, яка вже була відмінена у березні.

Команди обирають один із варіантів, стикаються з проблемами, а потім переходять на інший. Приблизно так справи виглядають у галузі сьогодні.

Вже існує діагноз у одному реченні

У квітні 2026 року Андрій Карпати опублікував короткий опис, який назвав файлом ідеї. Це не був продукт чи бібліотека. У ньому описувався один підхід: модель перетворює сировий матеріал на організований, структурований Markdown-вікі, і з того моменту запитання надсилаються до цього вікі замість до оригіналів.

Рядок у ньому, який має значення, не має нічого спільного з ШІ: люди покидають вікі тому, що труднощі з їхнім утриманням зростають швидше, ніж їхня корисність.

Кожен, хто бачив, як гине простір у Confluence, це упізнає. Люди не кидали це через складність написання тексту. Вони кидали через складність підтримки, а підтримка полягає переважно у бюрократичних діях: оновити посилання, оновити резюме, позначити, що ця сторінка тепер суперечить іншій, виправити індекс. Саме ця робота перестала бути трудомісткою, адже ШІ не втомлюється, не забуває про перелінкування та може обробити п’ятнадцять файлів за один прохід. Його розподіл роботи простий: ви читаєте, а ШІ пише.

Суть цього швидко поширилась. Через два місяці Google Cloud оприлюднила специфікацію, яка, за їхніми словами, формалізує патерн wiki з використанням ШІ у форматі, здатному до переміщення та взаємодії. Основна діагнозика залишається діагнозикою Карпаті, і саме тому все це тепер працює, а у 2019 році — ні.

OKF за півхвилини

OKF, формат відкритих знань, був оприлюднений командою Data Cloud Google Cloud у червні 2026 року у вигляді чернетки (v0.2) та є формалізацією цього формату. Технічно це каталог файлів Markdown із YAML-передметом, і це все.

У специфікації його суть описана так: будь-хто, хто може використовувати команду cat для читання файлу, може читати OKF, а будь-хто, хто може виконати команду git clone для копіювання репозиторію, може його поширювати.

Єдине обов’язкове поле — type. Файл, який містить лише значення type, вважається відповідним формату. У цьому процесі не використовуються реєстри схем, бази даних, пайплайни вбудовування, обмеження від постачальників чи SDK.

okf/
  index.md                  ← table of contents
  billing/
    index.md
    invoice-retries.md      ← one file, one answerable question
  flows/
    customer-offboarding.md

Якщо ваша реакція — «Отже, папка з Markdown», то це точно. Формат не є найцікавішою частиною, і цілком обґрунтованою є думка, що папці не потрібні специфікації. У оголошенні Google є відповідь: вікі Карпаті, вікі команди та експорт каталогу постачальника можуть виглядати однаково — з Markdown, frontmatter та перехресними посиланнями — але жоден з них не був створений для взаємодії. Саме тому потрібні специфікації. Усі незалежно дійшли до однакової структури, що зазвичай означає, що ця структура правильна, а потім кожна реалізація винайшла власні назви полів. Формат перетворює кілька приватних конвенцій на щось, що агент може прочитати будь-де.

Основна ідея: документація стає станом

Ось зразок документа:

---
type: Playbook
title: Invoice retry policy
status: stable                      # draft | stable | deprecated
stale_after: 2026-11-01             # stale when today >= this date
generated: { by: "human:dana", at: 2026-08-10 }
verified:  [{ by: "human:sam",  at: 2026-08-11 }]
sources:
  - resource: services/billing/retry.go
    last_modified: 2026-07-15
not:
  - term: "restart the worker to clear the queue"
    why: "in-flight jobs are lost, they are not re-queued"
    instead: "drain first, then restart"
---

П’ять з показаних полів походять із специфікації. Шосте є найціннішим та знову з’являється нижче.

Шухляда просто зберігає документи. Мозок також знає, що він містить, наскільки впевнений у цьому та які помилки щось йому навчили. Наведені нижче елементи відповідають цьому:

Тепер прочитайте цей фронтматер так, як це зробила б машина. stale_after — це дата закінчення терміну дії. Це не позначка „останнє оновлення“, яку потрібно інтерпретувати. Це абсолютна дата, яка перетворює питання старіння на просте порівняння — today >= stale_after. Цю перевірку може виконувати що завгодно: агент, який читає файл, запланована задача чи ваш CI.

Зупиніться на цьому. Проблема старіння документації є культурною проблемою з моменту створення вікі. Постійні нагадування, щомісячні перевірки, квартальні аудити, а також сторінка „Стандарти документації“, яка сама вже застаріла. Усе це ґрунтується на соціальному тиску, і нічого з цього неможливо примусово впровадити. За допомогою stale_after старіння стає причиною невдачі тесту, у тій самій категорії, що й зламаний процес будування. Він або пройде, або ні, і ніхто не мусить почуватися погано.

Інші поля працюють так само. sources перелічує шляхи до коду, які описує документ, щоб скрипт міг нарешті відповісти на запитання, на які вікі ніколи не могли: цей pull request змінив файл, який, за твердженням трьох документів, має його пояснювати, тож чи хтось їх оновив? verified фіксує тих, хто підтвердив документ, окремо від тих, хто його написав, адже, за словами специфікації, той, хто створив концепцію, не обов’язково має бути тим, хто її підтвердив. Розробка проєкту агентом та затвердження старшим інженером — це два окремі етапи, які більшість інструментів для документації ніколи не фіксують. Рівні довіри визначаються за допомогою префіксу виконавця та не зберігаються, оскільки збережений бал є суб’єктивним, непортативним між користувачами та з часом устаріває.

status: deprecated дозволяє зберегти старе визначення замість його видалення. Коли два панелі керування не погоджуються щодо показника „дохід“, причиною часто не є погані дані, а два різні визначення, одне з яких було тихо замінено без позначки. Збережіть обидва, позначте один, і цифри за минулий квартал все одно будуть доступні.

Ось у чому зміна: не просто кращий формат для тексту, а текст разом із можливістю запитування стану. Документи можна аналізувати, тестувати та перевіряти.

Арифметика токенів

Ці показники були виміряні за допомогою оприлюдненого прикладу від Google, тож їх можна перевірити:

Обробка одного факту від початку до кінця коштує близько 950 токенів та стягується лише за запити, які це потребують. Частина, яка працює постійно, належить до рівня 0: 60 токенів, одне речення.

Порівняйте це з типовим підходом: посібник обсягом 1 600 токенів додається до кожного запиту, хоча, можливо, лише кожен десятий запит це потребує. Знання залишаються тими самими, середній рахунок становить приблизно одну десяту, а документ може рости без обмежень, оскільки додаткова довжина більше не впливає на непов’язані розмови в репозиторії. Специфікація створила index.md саме з цією метою та назвала її прогресивним розкриттям інформації: спочатку переглядається те, що вже є, а документи відкриваються пізніше.

Що OKF не є

OKF не функціонує як захисний бар’єр. Файл у форматі Markdown не може завадити агенту виконати щось руйнівне. Фактичний контроль має здійснюватися за допомогою коду — наприклад, списків заборон та хуків перед виконанням, які блокують дію незалежно від вибору моделі. Що б ви ще не пам’ятали, не робіть висновку, що просте записування небезпеки означає вашу захищеність.

Те, що насправді надає OKF, — це агент, який знає правила. У специфікації також визначений тип обчислень Attested Computation, у якому агент може передавати параметри, але ніколи не може писати чи змінювати сам процес обчислень, що є максимально можливим підходом до заборони переписування перевірки безпеки. Слідкуйте за цим, але поки що не будуйте на цьому: у специфікації зазначено, що цей інтерфейс буде впроваджений у наступній версії.

Пам’ятайте також, що це лише чернетка. Перехід від v0.1 до v0.2 вже призвів до перейменування двох конструкцій, тому використовуйте лише вісім полів, які вам потрібні. Будь-яке подальше перейменування можна здійснити за допомогою функції пошуку та заміни.

Почніть з малого, додавайте механізми контролю там, де це доцільно

Це не проєкт — це один файл.

1. Напишіть один документ про те, що нещодавно забрало у когось півдня часу, вказавши type, title, description та stale_after.
2. Створіть файл index.md, у якому буде перелік цього документа з колонкою „Коли читати“, та додайте okf_version: „0.2“. Кореневий індекс — це єдине місце, де має знаходитися це поле, і згідно зі специфікацією це єдиний фронтматер, який може містити індекс.

Додайте вказівник до вашого файлу, який завжди активний. Це коштує близько шістдесяти токенів та містить шлях та тригер, але ніколи не резюме, оскільки резюме як збільшує вартість постійної активності, так і змушує агента відкрити файл.

Цього достатньо, щоб розпочати роботу. Оскільки today >= stale_after — це просто порівняння, агент може оцінити його відразу після відкриття файлу. Що робити з застарілим документом, залежить від вас, що і є навмисно залишеним у специфікації.

Додайте автоматизацію тоді, коли хтось інший зможе зробити ваш документ недійсним без його читання. Це справжній критерій, і він стосується більше розміру команди, ніж її коректності. Якщо у вас лише п’ять документів, це буде помітно, і достатньо буде перевірки терміну дії з боку агента. У команді той, хто порушує умови документа, за визначенням — це той, хто ніколи його не відкривав, тож добрі наміри до нього не дійдуть, тому щось у процесі подання запиту мусить це зробити. Дешева версія — це запланована задача, яка повідомляє про закінчення терміну дії документів. Сильніша версія — це брандмауер для запитів, який блокує їх у разі закінчення терміну дії документа та попереджає, якщо код, описаний у документі, був змінений. Почніть з дешевшого варіанту.

Коротка версія

Те, що потрібно агенту, — це не більше вікна контексту. Йому потрібно знати, де шукати, а будь-який файл, який він відкриває, має чесно вказувати свою дату створення. Сімдесят токенів спочатку, решта за потребою, а також документ, який може зіпсувати процес обробки, як тільки його інформація стане неправдивою — що раніше було неможливим.

Додаткова література: специфікація OKF v0.2 та прикладні пакети, пост Google Cloud про цей формат, статті Anthropic про інженерію контексту, навички агентів та кешування запитів, а також дослідження Chroma щодо зміни контексту.

Пов’язана література

• Практичні нотатки: вашому агенту для кодування не потрібен більше контексту. Йому потрібна карта. — Покрокове керівництво з Практичних нотаток: вашому агенту для кодування не потрібен більше контексту. Йому потрібна карта: контракти, перевірки та слоти для вставки коду для команд, які використовують цю схему.
• Практичні нотатки: вашому агенту для кодування не потрібен кращий запит — Покрокове керівництво з Практичних нотаток: вашому агенту для кодування не потрібен кращий запит: контракти, перевірки та слоти для вставки коду для команд, які використовують цю схему.

Практичні нотатки: Israeli Tech Radar 2026-27: Інженерія в епоху агентів — Детальний огляд Практичних нотаток: Israeli Tech Radar 2026-27: Інженерія в епоху агентів: контракти, перевірки та шаблони коду для команд, які використовують цю модель.