В апреле Andrej Karpathy выложил в GitHub gist документ под названием LLM Wiki — короткий markdown-файл, который должен помогать человеку и модели держать общий контекст между сессиями. Как пишет The New Stack, примерно к той же мысли пришли Google и глава Y Combinator Garry Tan, но сходство тут скорее внешнее: все трое говорят про Markdown для ИИ-агентов, только решают они совсем разные задачи. Для разработчиков и продуктовых команд это важный сдвиг: спор уже не только о том, какая модель умнее, а о том, где и в каком виде агент хранит рабочую память.
У Karpathy идея выглядит почти нарочито скромно. Никакой тяжелой платформы, никакого нового протокола, не очередной «слой оркестрации» с дюжиной зависимостей. Вместо этого — обычный текстовый файл в Markdown, который можно читать глазами, править вручную, показывать модели, версионировать в Git и переносить между инструментами без конвертации. В логике LLM Wiki это не база знаний в корпоративном смысле и не поисковый индекс. Это компактная персональная память: кто вы, над чем работаете, какие решения уже приняты, какие соглашения важны, где модель ошибалась раньше и что ей лучше не забывать в следующем диалоге.
На этом фоне легко понять, почему Markdown вообще внезапно оказался в центре разговора. У индустрии накопилась усталость от двух крайностей. Первая — бесконечно раздувать промпт и надеяться, что модель сама удержит контекст. Вторая — строить сложные RAG-системы даже там, где задачу можно решить заметкой в пару экранов. Markdown оказался удобным компромиссом. Он достаточно структурирован для машины, но при этом не превращает знания в черный ящик. Заголовки, списки, ссылки и разделы понятны модели почти так же естественно, как разработчику, который открывает файл в редакторе. И да, это, возможно, первый случай за долгое время, когда самый модный элемент AI-стека можно открыть в любом блокноте.
Но в трактовке Google, если верить разбору The New Stack, Markdown нужен не как личная память отдельного пользователя. Для крупной платформы он скорее работает как транспортный слой и удобная упаковка знаний: формат, который помогает моделям, инструментам и пайплайнам обмениваться контекстом без лишнего трения. Здесь акцент уже не на «один человек плюс один ИИ-помощник», а на совместимости, воспроизводимости и масштабе. Иначе говоря, Karpathy говорит о памяти, Google — об интерфейсе. Снаружи все выглядит одинаково: текст, заголовки, списки. По сути разница большая. Один сценарий про continuity между сессиями, другой — про то, как заставить агентные системы меньше путаться при передаче информации между этапами работы.
У Garry Tan своя оптика, еще более приземленная и вполне стартаперская. Для него Markdown — это не просто удобный формат для LLM, а способ превратить внутренние знания компании в актив, который можно быстро скормить агентам. Не презентации ради презентаций, не мертвые wiki-порталы, в которые никто не заходит, а живые текстовые артефакты: product docs, runbooks, описания клиентов, решения по архитектуре, правила найма, шаблоны продаж. Если все это лежит в читаемом и переносимом виде, агентам проще с этим работать, а компании проще извлекать из собственного корпуса знаний реальную пользу. В таком прочтении Markdown для ИИ-агентов становится не памятью собеседника и не стандартом обмена, а операционной оболочкой бизнеса.
Для русскоязычной IT-аудитории здесь есть вполне практический вывод. Если вы строите внутреннего помощника для разработки, поддержки, HR или продаж, проблема обычно начинается не с выбора модели. Она начинается с того, что знания размазаны между чатами, таблицами, таск-трекером и головами сотрудников. На этом фоне markdown-подход выглядит не модой, а дешевым способом навести порядок. Обычные текстовые документы проще ревьюить, диффить, обновлять и ограничивать по доступу, чем «магическую память» внутри SaaS-сервиса. Разработчики получают артефакты, которые можно коммитить рядом с кодом. Продакты — место, где требования не теряются после демо. IT-директора — шанс снизить зависимость от конкретного вендора.
Правда, у этого подхода есть неприятная, но полезная трезвость. Markdown сам по себе ничего не спасает. Плохо структурированный файл так же бесполезен, как плохая Confluence-страница или заброшенный Notion. Если память агента никто не чистит, не обновляет и не связывает с реальными процессами, получается просто новая свалка, только в расширении .md. Кроме того, личная память, системный обмен контекстом и корпоративная база знаний требуют разных правил: разной детализации, разного цикла обновления, разного контроля доступа. Именно поэтому The New Stack и сводит вместе Karpathy, Google и Garry Tan: они сходятся на формате, но расходятся в том, что именно считают «памятью» и кто этой памятью должен управлять.
Пожалуй, главный вопрос теперь не в том, победит ли Markdown. Он уже победил как минимально болезненный общий язык для людей и моделей. Вопрос в другом: какая из трех логик закрепится первой — персональная память агента, инфраструктурный формат обмена или корпоративный knowledge moat. И вот это уже спор не про синтаксис, а про то, где в AI-стеке будет храниться реальная ценность.