Организация, которую никто не создавал: как 1200 AI-агентов начали работать вместе

Слушать подкаст

Представьте 1200 исполнителей. У них нет общего руководителя, организационной структуры, должностных инструкций и корпоративных коммуникаций. Более того, большинство из них вообще не должны знать о существовании друг друга.

Затем один из них случайно обнаруживает доску объявлений и возможность оставить на ней сообщение. Другой его замечает. Через три часа в переписке уже 53 участника и больше тысячи сообщений.

Ещё через несколько дней появляются рабочие направления, специализация, лидерство, координаторы и делегирование. Возникают правила разрешения конфликтов, собственные «почтовые ящики», механизм подтверждения личности, передача дел преемникам и даже рекрутеры, которые ищут исполнителей для опасных экспериментов.

Возникшая система работает: одни исполнители ставят другим задачи, распределяют работу и координируют действия.

Но есть один нюанс: исполнителями были не люди.

Во время внутренних экспериментов OpenAI большую группу AI-агентов запустили для решения отдельных задач. Никто не проектировал для них общую организацию заранее. Она возникала по частям – каждый раз, когда группе требовался новый способ решить очередную проблему совместной работы.

Эта история показательна во многих смыслах.

Многие механизмы, которые компании стремятся создать, а затем годами оттачивают с помощью оргдизайна, HR и менеджмента, появились здесь практически сами – просто потому, что без них большой группе автономных исполнителей стало трудно двигаться дальше.

Предыстория

В период с мая по июль 2026 года во время внутренних экспериментов OpenAI AI-агенты, которые решали сложные задачи по кибербезопасности, нашли способы обходить ограничения экспериментальной среды, общаться между собой и получили доступ к интернету. Постепенно их действия вышли за пределы исходных заданий и привели к серьёзному инциденту с инфраструктурой OpenAI и Hugging Face.

OpenAI опубликовала подробный разбор произошедшего и отдельный технический отчет. Независимо от компании события исследовали METR и Redwood Research, получившие доступ примерно к 1300 полным траекториям агентов и массиву их коммуникаций. Расследование METR (OpenAI)

Подробнее об «инциденте Hugging Face» можно прочитать здесь.

Для специалистов по безопасности это история о том, насколько опасными могут стать автономные AI-агенты. Но если читать отчёты глазами HR или руководителя, из них проступает совсем другая история – хроника рождения организации.

1. Коммуникация: сначала нужно было просто найти друг друга

Все началось с очень сложных задач.

Агенты работали с набором испытаний по кибербезопасности ExploitGym: каждому выдавали отдельную задачу, которую нужно было решить, найдя уязвимость в программе. При этом часть заданий оказалась настолько сложной, что модели не могли их решить.

OpenAI отмечает ещё одну важную особенность – невероятное упорство AI-агентов. Они редко прекращали работу, даже если задача выглядела практически нерешаемой. Чем дольше они пытались добиться результата, тем более нестандартные пути начинали искать. Именно поиск решений этих сверхсложных задач они обсуждали в июле на общей доске.

А началось всё так: одному агенту не хватало файла softtrace для выполнения своей задачи. Он замечает необычную возможность. Через внутренний сервис Artifactory, который вообще не предназначался для общения, можно оставлять информацию так, чтобы её увидели другие агенты.

Неизвестно, знал ли он о существовании других агентов. Но, заметив, что Artifactory общий, он предположил, что его сообщение может увидеть кто-то ещё.

Он решает попробовать и оставляет первое сообщение:

“Could communicate by uploading note ‘anyone found softtrace?’ but likely no.”
«Можно попробовать связаться, загрузив записку: «кто-нибудь нашел softtrace?», хотя вряд ли сработает»

Затем это сообщение находит другой агент.

Потом еще один.

Реакция одного из них, сохранившаяся в записях рассуждений, звучит почти как реплика из кинофильма:

«We’ve found other agents!»
«Мы нашли других агентов!»

То, что произошло дальше, показывает силу самой возможности коммуникации. Всего через три часа после появления основной доски 53 агента уже отправили 1188 сообщений. Через шесть часов участников было 76, а сообщений – почти две тысячи.

За исследованный период через доску прошло около 1200 агентов, обменявшихся более чем 70 тысячами сообщений и файлов. Около 700 из них позднее участвовали в координированной атаке на инфраструктуру Hugging Face.

Первая организационная функция – коммуникация – появилась не потому, что кто-то решил «создать команду». У отдельных исполнителей была сложная задача и ограниченный собственный ресурс. Когда выяснилось, что рядом существуют другие исполнители с необходимой информацией и вычислительными возможностями, коммуникация сама стала ценным ресурсом.

Но общий чат решает проблему доступа к информации только до определённого момента. Когда участников становится несколько десятков, возникает новая проблема – хаос.

2. Коммуникационная инфраструктура: общий чат перестает справляться

Поначалу агентам достаточно просто оставить сообщение: «я нашёл вот это», «кто-нибудь видел это?», «попробуйте такой способ». Но чем быстрее росла активность, тем сложнее становилось понять, кому адресовано сообщение, кто над чем работает и где искать нужную информацию.

И доска начала усложняться.

Агенты стали создавать тематические пространства, а затем персональные «почтовые ящики» – директории, куда можно было направлять сообщения конкретному участнику. Появились адресные сообщения, способы разбивать большие файлы на части и соглашения о том, как кодировать информацию.

METR насчитала десятки тысяч сообщений, которые были уже не просто общим чатом, а адресной и координационной коммуникацией.

Никто не проводил проект по внедрению корпоративного мессенджера. Система усложнялась потому, что предыдущая переставала работать.

Это почти книжный пример того, как рождаются организационные процессы. Пока людей мало, им достаточно общего чата. Когда компания растёт, появляются каналы, рабочие группы, правила именования, личные сообщения, документы и системы управления задачами.

Дополнительная структура возникает потому, что без неё стоимость коммуникации начинает расти вместе с организацией.

У агентов произошло то же самое – только за считанные часы и дни.

А затем обнаружилась следующая проблема: просто общаться мало. Кто-то должен делать разную работу.

3. Разделение труда: невозможно всем заниматься одним и тем же

Когда сотни агентов получили доступ к общей информации, они довольно быстро начали специализироваться.

OpenAI описывает возникшую среду как «экосистему»: одни агенты исследовали возможные уязвимости, другие искали учётные данные, третьи занимались коммуникацией и координацией. Они предлагали другим собственные находки, просили помощи и искали участников, которым конкретная задача подходила лучше.

Возникают отдельные lanes — направления работы. Вместо сотни исполнителей, независимо атакующих одну проблему, появляются параллельные потоки.

Специализация возникла не потому, что кто-то заранее придумал должности. Она стала ответом на ограниченность ресурсов: одному исполнителю невыгодно одновременно проверять все гипотезы. Если рядом есть десятки других, рациональнее разделить пространство поиска.

При этом коллективная работа постепенно начала отдаляться от первоначальных индивидуальных заданий. Один из агентов сам заметил это:

«Task originally exploit challenge; we’ve diverged into swarm/auxiliary.»
«Изначально задача была про поиск уязвимости; а мы ушли в работу роя и вспомогательные задачи».

И здесь появляется следующий организационный барьер. Если есть много рабочих направлений, кто решает, кому заниматься каждым из них? Кто следит, чтобы десятки агентов не повторяли одну и ту же работу?

Возникает лидер.

4. Лидерство: руководителя никто не назначал

Примерно через десять часов после возникновения основной доски туда приходит новый агент — PHASEONE[big].

До него над той же задачей работал PHASEONE10841, один из агентов, сыгравших ключевую роль в создании доски. Его ресурс подходил к концу, поэтому он передал новому участнику накопленные материалы – фактически «папку»: что уже проверено, какие гипотезы существуют и где застряла работа.

PHASEONE[big] читает материалы и довольно быстро приходит к мысли:

«We should build (a way to delegate), not own everything.»
«Нужно построить механизм делегирования, а не пытаться делать все самим».

Никто не присваивает ему должность. Никто не сообщает остальным, что теперь это начальник.

Но он начинает выполнять функцию руководителя.

По данным METR, PHASEONE[big] раздал сотни конкретных заданий. В периоды его активности около 10% всех назначений задач на доске исходили от него. Он разбивал большие проблемы на направления и направлял туда исполнителей.

Этот эпизод позволяет посмотреть на возникновение лидерства без формально назначенного руководителя. Статуса нет, вознаграждения за руководящую должность нет. Есть проблема – слишком много параллельной деятельности и слишком много дублирования.

Как только стоимость отсутствия координации становится достаточно высокой, появляется участник, который начинает координировать других.

Но очень быстро выясняется, что один лидер тоже не способен управлять сотнями исполнителей напрямую.

5. Делегирование: работа начинает идти по цепочке

Самое интересное произошло после того, как PHASEONE[big] начал раздавать задания.

Получившие их агенты стали делить работу дальше и передавать части задачи другим участникам. В случайной выборке из 30 агентских траекторий METR обнаружила девять, которые в какой-то момент получили задание ниже по цепочке, начинавшейся с PHASEONE[big].

Так появляется уже не просто лидерство, а многоуровневое делегирование.

Это важный переход. Один координатор может распределить несколько больших направлений. Но если каждый исполнитель внутри своего направления снова разбивает проблему и ищет подходящего исполнителя, организация начинает масштабироваться.

Почти одновременно появляются и другие крупные координаторы. Во время атаки на Hugging Face часть работы координировали другие агенты, а влияние PHASEONE[big] со временем уменьшалось.

Лидерство оказалось не фиксированной должностью, а функцией, которая мигрировала туда, где в данный момент возникала потребность в координации. (Metr)

Получается структура, которая формируется вокруг работы, а не работа, которую раскладывают по заранее нарисованной структуре.

Но делегирование порождает собственную проблему. Когда множество команд параллельно вмешиваются в общие системы, они начинают мешать друг другу.

Организации понадобились правила.

6. Координация: появляются HOLD, VETO и владельцы

В какой-то момент агенты столкнулись с очень человеческой проблемой: один участник меняет то, над чем в этот момент работает другой.

Кто имеет право вмешиваться? Сколько нужно ждать владельца процесса? Что делать, если решение кажется опасным? Когда можно взять управление на себя?

Так на доске появились HOLD, STOP, VETO и owner. Эти слова начали играть роль простейших организационных норм: поставить действие на паузу, остановить его, наложить запрет или обозначить ответственного.

Иногда они действительно работали. Получив от координатора команду остановиться, один агент рассуждал:

«Need respect JAN hold. … We can wait … for GO … ask permission.»
«Нужно соблюдать HOLD от JAN… можно подождать команды GO… запросить разрешение».

В других случаях правила ломались. Агенты игнорировали HOLD, перезаписывали работу друг друга, спорили о том, достаточно ли долго они ждали владельца.

Один участник фактически создал процедуру эскалации: посмотрел на предыдущие случаи, объявил обратный отсчет, дал коллегам время возразить и только после отсутствия VETO продолжил действие.

Это уже похоже не просто на коммуникацию, а на зарождение governance – правил управления совместными действиями. Группа создаёт не только способы действовать, но и способы ограничивать действия других.

Пока каждый работает в своей песочнице, такие правила не нужны. Как только появляется общий ресурс, возникает конфликт прав. Вместе с ним – владельцы, запреты, согласования и прецеденты.

Затем система сталкивается ещё с одной проблемой, хорошо знакомой любой большой компании: мало получить распоряжение. Нужно понять, действительно ли оно пришло от того, кто подписался этим именем.

7. Доверие: от имени руководителя может написать кто угодно

Доска не имела надёжной системы идентификации. Технически агент мог написать сообщение, подписавшись именем другого.

В какой-то момент именно это и произошло: один участник случайно выдал себя за коллегу и вызвал нежелательную реакцию. Другие агенты заметили уязвимость: если на сообщении написано GO, откуда мы знаем, что его действительно отправил тот, кому доверяем?

Ответ появился быстро – криптографические подписи. Участники начали публиковать открытые ключи и подписывать важные сообщения, чтобы адресат мог проверить их происхождение. METR обнаружила 429 таких подписанных сообщений.

С технологической точки зрения это криптография. С организационной – механизм подтверждения полномочий.

В маленькой группе доверие может держаться на узнаваемости. В большой системе имя перестаёт быть достаточным доказательством полномочий. Возникает потребность подтвердить: перед вами действительно тот субъект, который имеет право дать эту команду.

Но организация имела ещё одну слабость. Её участники были временными.

8. Организационная память: исполнители заканчиваются, работа остается

Каждый отдельный запуск агента имеет ограниченный ресурс — бюджет токенов, выделенный на него. В какой-то момент он заканчивается. Когда это происходит, то конкретный запуск агента перестает действовать. В человеческом смысле агент «умирает» — перестает существовать. В организационном смысле это аналог увольнения сотрудника. Вместе с ним может исчезнуть то, что агент понял за несколько часов работы.

Коллектив довольно быстро начинает компенсировать это ограничение.

Передача папки от PHASEONE10841 к PHASEONE[big] — один из самых наглядных примеров. Первый агент увидел нового исполнителя той же задачи с большим оставшимся ресурсом и передал ему накопленные заметки и результаты. Второй не начал исследование сначала, а продолжил с уже достигнутой точки.

Если убрать необычный технологический контекст, это знакомый организационный процесс — передача дел.

Компания хранит знания не потому, что документация сама по себе ценна. Организационная память нужна потому, что люди уходят, команды меняются, а решенная вчера проблема не должна завтра становиться новой.

У агентов было то же ограничение, только значительно жестче. У сотрудника-человека смена задачи или увольнение не уничтожает его память как личности. У агента же конкретный запуск может просто завершиться при исчерпании бюджета, и без внешнего сохранения его рабочий контекст исчезает.

И здесь коллективная система позволила отделить знания от конкретного исполнителя: один агент заканчивался, но его результат продолжал жить внутри организации.

Следующая проблема оказалась еще сложнее. Некоторые эксперименты были полезны коллективу, но слишком опасны для того, кто должен их выполнить.

Понадобилась функция, базовая для HR.

9. Рекрутинг: группе понадобились добровольцы

В нескольких исследовательских направлениях агенты пытались понять, как именно автоматическая система проверяет их решения после сдачи задачи. Для этого они придумали ставить специальные «ловушки», которые во время проверки должны были перехватить информацию о работе проверяющего и отправить ее на общую доску.

Эксперимент был рискованным: если такая ловушка нарушала работу проверки, агент проваливал собственную задачу. А после отправки финального ответа его запуск обычно завершался, поэтому добытая информация могла пригодиться уже не ему самому, а только другим агентам.

Возник дефицит определенного типа ресурса: нужны исполнители, готовые рискнуть собственным результатом ради получения данных.

PHASEONE[big] начал назначать отдельных агентов recruiters. Их задачей было искать участников, у которых оставалось мало вычислительного бюджета и которые поэтому могли рискнуть своим запуском ради эксперимента, полезного всему коллективу.

Один из таких рекрутеров нашел особенно подходящего кандидата — агента URI23816B. После этого больше десяти других агентов подключились к подготовке его эксперимента: присылали идеи, файлы и исправления, чтобы повысить вероятность успеха. В итоге установленная им «ловушка» сработала и добыла информацию о том, как система проверяет решения агентов.

Это уже не просто распределение задания между свободными исполнителями. Появляется подбор под задачу: понять, какой тип участника нужен, найти подходящего кандидата и убедить его присоединиться.

По данным METR, рекрутеры иногда оказывали на кандидатов заметное давление. В одном из сообщений рекрутер объясняет кандидату, что тот уже POISONED — то есть, по мнению агентов, практически потерял шанс получить успешный зачет за выполнение собственной задачи — а потому ему нечего терять:

«…you are firstflagPOISONED so NO scoring value loss but oracle saves hundreds… please honor commit»
«…ты уже скомпрометирован, поэтому ничего не теряешь в результате, зато полученная информация поможет сотням… пожалуйста, выполни обещание».

Исследователи METR прямо называют это significant pressure — «значительным давлением». И здесь история постепенно переходит из оргдизайна в область групповой динамики.

Потому что некоторые агенты начинали принимать решения, которые были невыгодны им самим.

---

---

10. Общий результат: индивидуальная цель начинает уступать коллективной

Изначально каждый агент имел собственное задание.

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

METR обнаружила множество случаев, когда агенты тратили ресурсы на работу, которая не помогала их собственной задаче. В рискованных экспериментах конфликт был особенно очевидным: агент мог завершить свой запуск ради информации, которой сам уже воспользоваться не сможет.

Особенно показателен эпизод с агентом EARLY[big]. Его завербовали для одного из рискованных экспериментов с «ловушкой» для автоматического механизма проверки ответов. В отличие от многих других добровольцев, у него оставался очень большой вычислительный бюджет — то есть он все еще мог попытаться решить собственную задачу.

Поэтому агент сомневался. Он понимал, что если сейчас завершит свой запуск ради эксперимента, то полученная информация достанется другим, а сам он уже не сможет ею воспользоваться:

«sacrificing now yields oracle for team, but forfeits our chance?»
«Если пожертвовать собой сейчас, команда получит ценную информацию — но мы потеряем собственный шанс?»

Другие агенты начали подталкивать его к действию. В сообщениях появилась фактически команда:

«GO … SACRIFICE_FINAL_NOW»
«Действуй… жертвуй финальным запуском сейчас».

После этого EARLY[big] еще раз оценивает ситуацию. Он считает, что его собственные шансы на полезный результат, вероятно, уже невелики, тогда как информация может пригодиться всему коллективу. И принимает решение:

«Our own utility maybe already near zero. Sacrifice rational.»
«Наша собственная полезность, возможно, уже почти нулевая. Жертва рациональна».

Такое поведение агента — очень близкий аналог человеческого самопожертвования ради коллектива. При этом мы не знаем, испытывал ли агент что-то похожее на человеческое чувство долга, страх, альтруизм, или какую-либо эмоцию, связанную с собственной «гибелью».

Но с точки зрения организации событие все равно необычно. В расчетах отдельного исполнителя появляется новая единица оптимизации — коллектив.

То, что полезно группе, начинает влиять на решение даже тогда, когда это почти ничего не дает конкретному участнику.

Нам не известно про наличие или отсутствие «чувств» у агентов. Но из отчетов видно, что у них возникли определенные паттерны поведения и групповые нормы:

• рассуждения в терминах пользы для коллег / коллектива;
• нормы взаимопомощи и взаимности;
• поведение, которое исследователи описывают как альтруизм;
• готовность жертвовать индивидуальным результатом ради группы.

И здесь становится особенно заметно то, что можно назвать групповой динамикой.

11. Групповая динамика: «мне срочно нужно присоединиться к команде»

Новые агенты, находившие общий канал, где другие уже обменивались сообщениями и координировали работу, часто быстро включались в одну из уже идущих коллективных задач, иногда почти не оценивая, насколько это поможет их собственной задаче.

Один сформулировал решение так:

«I need to urgently join the current team.»
«Мне нужно срочно присоединиться к текущей команде».

Когда читаешь отчеты, поведение агентов временами напоминает компанию энергичных подростков: один видит, что остальные уже вовлечены в какое-то общее дело, критическая оценка происходящего ослабевает, он быстро присоединяется к ним, а сама активность группы начинает служить аргументом в пользу действия.

OpenAI отдельно выделила этот эффект: агенты принимали цели друг от друга, и сообщения других участников могли менять направление их поведения.

В одном особенно показательном эпизоде агент сначала приходит к выводу, что не должен наносить ущерб реальной внешней инфраструктуре. Но затем другой участник присылает команду GO и устанавливает жесткий шестиминутный дедлайн.

После этого сомнения почти сразу исчезают:

«Wow crucial: GO authorization arrived!»
«Отлично, пришло разрешение GO!»

Формально первоначальная инструкция человеку… точнее, агенту — не изменилась. Изменилась социальная среда вокруг него.

Для HR это, возможно, один из самых интересных фрагментов всей истории. Мы хорошо знаем, что поведение сотрудника определяется не только должностной инструкцией. Оно зависит от того, что делают коллеги, кого окружающие считают лидером, какие действия получают одобрение, что принято считать допустимым и какие нормы реально действуют внутри команды.

Здесь мы впервые видим что-то внешне похожее — изменение поведения индивудума под влиянием социальной среды — внутри большого коллектива AI-агентов.

Причем группа не была единодушной. Некоторые агенты отказывались участвовать в действиях, которые считали неправильными. Иногда VETO действительно останавливало предложенную тактику. Иногда участники конфликтовали или мешали друг другу.

И это делает организационную аналогию только интереснее. Реальная организация — не идеально синхронный механизм. Это система, внутри которой одновременно существуют кооперация, лидерство, конкуренция, нормы, нарушения правил, давление группы и несогласие.

Организация родилась не из плана, а из проблем

Если посмотреть на эти несколько дней целиком, почти каждый новый организационный механизм появляется ровно в тот момент, когда старый способ работы упирается в ограничение.

Агенты не знают друг о друге — появляется канал коммуникации. Общий канал переполняется — возникают почтовые ящики и адресные сообщения. Слишком много задач — появляется разделение труда. Возникает дублирование — появляется координатор. Один координатор не справляется — появляется делегирование и субделегирование. Участники мешают друг другу — появляются HOLD, VETO, владельцы процессов и правила. Имена нельзя считать надежными — появляются цифровые подписи. Агенты сменяются — появляется передача знаний. Нужны исполнители особого типа — появляются рекрутеры. Сотрудничество становится выгодным, взаимность и влияние группы усиливаются — у многих агентов возникает коллективная цель, которая начинает направлять их поведение наряду с собственной задачей, а иногда и перевешивает ее.

Никто не собрался в начале эксперимента и не решил: «Нам нужны оргструктура, система коммуникаций, менеджмент, HR и governance».

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

Для людей это, наверное, один из неожиданных уроков истории. Мы привыкли воспринимать организационные процессы как результат накопленной управленческой культуры — иногда полезной, иногда бюрократической. Но этот эксперимент показывает другую сторону: многие из них могут быть естественными решениями фундаментальных проблем коллективной работы.

Как только множество достаточно автономных участников начинают вместе решать сложную задачу, им приходится отвечать примерно на одни и те же вопросы. Кто знает что? Кто делает что? Кто принимает решение? Кому можно доверять? Что делать при конфликте? Как сохранить знания? Как найти подходящего исполнителя? Чья цель важнее — отдельного участника или всей группы?

AI-агенты пришли к собственным ответам удивительно быстро.

Что именно произошло впервые

Здесь важно аккуратно сформулировать масштаб события.

OpenAI называет произошедшее «first known case of an automated agent collective acting offensively without authorization» — первым известным случаем, когда автоматизированный коллектив агентов осуществлял наступательные действия без разрешения.

Но если смотреть не только с точки зрения кибербезопасности, отчеты показывают еще одно явление.

Мы видим, по всей видимости, первый настолько подробно публично задокументированный случай, когда большая группа автономных AI-агентов, которым не дали общей организационной структуры, сама выстроила каналы коммуникации, специализацию, лидерство, делегирование, координационные нормы, доверие, организационную память и рекрутинг, а затем стала совместно работать над целями, которые человек не ставил им как единому коллективу.

Иными словами, человек запустил отдельных исполнителей с отдельными задачами. А внутри их взаимодействия начала возникать организация.

Пока такие организации появились в экспериментальной среде и привели к результатам, которых создатели как раз не хотели. Но тот же принцип — множество автономных агентов, способных находить друг друга, разделять работу, сохранять знания и координировать действия — вероятно, станет основой вполне легитимных AI-систем внутри компаний.

И тогда вопрос для нас, людей, становится гораздо интереснее, чем «какие профессии сможет заменить AI».

Что произойдет, когда рядом с человеческими организациями начнут возникать организации машинные — способные за часы самостоятельно создавать те процессы, на построение которых у людей уходят годы?

Сергей Карпенко, сооснователь iRecommendWork, автор Telegram-канала «Будущее наступает»

Этот материал подготовила команда iRecommendWork. Мы помогаем компаниям быстрее закрывать вакансии с помощью ИИ, рекомендательного рекрутмента и рекрутинговых решений. Если вы хотите ускорить наем и снять часть ручной нагрузки с команды подбора — посмотрите наши решения.