Как построить компанию из одного человека и ИИ-агентов

В мире LLM мы привыкли мерить прогресс по отдельным героям: кто лучше пишет код, кто аккуратнее работает с сайтами, кто увереннее вызывает инструменты. Но как только задача становится длинной, многослойной и по-настоящему «рабочей» — с зависимостями, проверками, переделками и разными ролями — магия одиночного агента быстро заканчивается. Нужна не просто группа ботов, а что-то большее: структура, управление, память об ошибках, механизм найма и увольнения. И вот именно в этот зазор попадает работа OneManCompany, или OMC.

Когда агентам уже мало быть просто «умными»

Авторы предлагают смотреть на мультиагентные системы не как на чат нескольких ролей, а как на полноценную ИИ-организацию. С «гендиректором», кадровиком, операционным директором, рынком специалистов, задачами в очереди и даже формальными процедурами вроде проверки результата и плана улучшения производительности. И, что важнее, это не просто красивая метафора. На бенчмарке PRDBench система показывает 84,67% успешных решений — это на 15,48 процентного пункта выше прежнего лучшего результата.

Что именно предлагают авторы

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

OMC пытается взять лучшее из мира реальных компаний и перенести это в ИИ-системы. У них три основных опоры:

1. Управление сотрудниками: агент — это не просто промпт, а оформленный «сотрудник» с ролью, инструментами, историей и средой исполнения.

2. Декомпозиция и контроль задач: работа разбивается на дерево подзадач с зависимостями и обязательной проверкой результата.

3. Эволюция организации: агенты и сама «компания» учатся на опыте, а не начинают с нуля в каждой новой сессии.

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

Агент как сотрудник: талант плюс контейнер

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

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

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

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

На практике это решает сразу несколько хронических болей мультиагентных систем:

Сюда же добавляется и рынок талантов — каталог проверенных агентов, которых можно нанимать по требованию. Это важный момент: вместо того чтобы «выдумывать» нового специалиста одним промптом, OMC старается привлекать уже собранные и проверенные агентные пакеты. Иначе говоря, не «представь, что ты архитектор», а «вот реальный агент-архитектор с инструментами, настройками и историей качества».

Как OMC решает задачи: исследовать, выполнить, проверить

Сердце статьи — механизм с немного громоздким названием Explore-Execute-Review, который авторы сокращают как E²R. По-русски это примерно «исследуй — выполни — проверь».

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

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

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

Авторы даже вводят конечный автомат состояний задачи: ожидание, исполнение, завершение, принятие, сбой, блокировка и так далее. Самое важное правило: переход из «выполнено» в «принято» требует явной проверки. То есть результат не может самопроизвольно считаться валидным и разблокировать последующие ветки.

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

Почему результаты на PRDBench выглядят серьезно

Основная количественная проверка — бенчмарк PRDBench, где нужно решать проектные задачи по разработке программного обеспечения на основе продуктовых требований. Это не маленькие задачки «допиши функцию», а более реалистичный сценарий: понять ТЗ, разложить работу, написать решение и пройти автоматическую оценку.

OMC в режиме одной попытки без итеративной помощи человека показывает 84,67% успеха. Это выше, чем у сильных одиночных систем и коммерческих агентов, приведенных в статье. Прирост относительно лучшего базового решения — 15,48 процентного пункта.

Что за этим, по мнению авторов, стоит?

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

Во-вторых, обязательный контур проверки. Непроверенный результат не идет дальше.

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

Ценой за это становится стоимость: около 345,59 доллара за 50 задач, то есть примерно 6,91 доллара на задачу. Для простых запросов это дорого. Но авторы и не утверждают, что OMC нужен для каждого чата с моделью. Их тезис другой: если задача проектная и цена ошибки высока, организационный слой может окупаться.

Самое интересное — не цифры, а кейсы

Если честно, именно кейсы делают статью живой. Авторы показывают, что OMC умеет не только писать код. Например, система по одной фразе собирает команду для подготовки еженедельного обзора популярных репозиториев, нанимает исследователя и автора, собирает данные, пишет текст и отправляет письмо. Стоимость — около 4,49 доллара.

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

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

Что объединяет все кейсы? Не конкретные модели, а одинаковая управленческая логика: нанять, разложить работу, назначить, проверить, сохранить опыт. Именно это и есть главный аргумент статьи в пользу «организационного» взгляда на агентов.

Где здесь слабые места

Работа сильная, но не без вопросов.

Первое ограничение — основная количественная оценка пока только на задачах разработки. Да, кейсы шире, но систематического бенчмарка за пределами программирования пока нет.

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

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

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

Почему эта статья действительно важна

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

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

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

Вывод

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

На PRDBench это дает сильный выигрыш по качеству. В кейсах — впечатляющую гибкость: от контентных задач до игр и исследовательских обзоров. Да, подход дорогой, громоздкий и пока не везде проверен. Но в нем есть то, чего не хватает многим агентным работам: не просто очередной оркестратор, а попытка ответить на вопрос, как ИИ-системам работать как коллектив.

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