СейчасОргсхема показывает власть, граф показывает работу
- Оргсхема показывает власть, граф показывает работу
- Два слоя одной организации
- Из чего состоит граф задач
- Результат
- Задачи и зависимости
- Возможности исполнителей
- Данные и доступы
- Контроль и возврат
- Маршрут зависит от свойств работы
- Роль становится контекстом задачи
- Что меняется в работе руководителя
- Где модель ломается
- С чего начать без реорганизации
- Когда второй слой полезен
- Источники
- Следующий шаг
- Связанные материалы
Прямо при подготовке этой статьи два независимых ИИ-исследователя получили разные задания. Один проверял опубликованные материалы pimenov.ai и искал возможный дубль. Второй собирал первичные источники об оркестрации агентов и динамическом распределении работы. У каждого были своя цель, границы, ожидаемый результат и условие остановки. Затем оба вернули результаты в управляющую задачу, где я сопоставил доказательства и принял редакционные решения.
Эти исполнители не относились ни к одному отделу. Работа собралась вокруг результата, исполнители подключились на тех участках, где подходили их возможности и доступы.
Оба исследовательских потока дали наблюдаемый результат. Первый подтвердил, что прямого дубля на pimenov.ai нет, и нашёл опубликованные материалы для продолжения темы. Второй обнаружил данные Google о том, что многоагентная схема может снижать качество на последовательных задачах. Из-за этого исходная формула «что приходит на смену отделам» стала точнее: речь пойдёт о втором рабочем слое организации, который дополняет формальную структуру.
Этот пример показывает один возможный способ организации работы. Формальная оргсхема остаётся прежней, однако реальный путь задачи проходит через людей, ИИ-агентов, сервисы, базы данных и контрольные точки. Если смотреть только на отделы и должности, значительная часть этого маршрута становится невидимой.
Оргсхема показывает власть, граф показывает работу
Классическая организационная схема отвечает на устойчивые вопросы: кто кому подчиняется, где находится бюджет, кто имеет право подписи и кто отвечает за функцию. Она хорошо описывает вертикаль полномочий.
Для движения конкретной задачи этого мало. Чтобы выпустить материал, согласовать договор или обработать обращение клиента, нужно увидеть другой набор связей:
- какое событие запускает работу;
- какой результат должен появиться;
- от каких данных и предыдущих действий он зависит;
- какие компетенции нужны на каждом участке;
- кто или что может выполнить действие;
- какие доступы потребуются;
- кто проверит результат;
- когда процесс обязан вернуться человеку.
Так возникает граф задач: карта узлов и переходов, по которым собирается результат. Узлом может быть задача, исполнитель, набор данных, проверка или решение. Связь показывает зависимость: «требует», «передаётся», «проверяется», «блокирует», «возвращается владельцу».
Это рабочая модель организационного проектирования, пока не претендующая на статус стандарта. Её ценность в том, что она делает видимой координацию между сотрудниками, агентами и системами.
Два слоя одной организации
Противопоставлять граф задач и отделы было бы слишком просто. Компании нужен устойчивый слой, в котором сохраняются профессиональные стандарты, развитие людей, бюджет, право доступа и юридическая ответственность. Маркетинг, финансы, производство и разработка могут продолжать существовать как центры компетенций и полномочий.
Над этим основанием появляется подвижный слой исполнения. В нём работа собирается под конкретный результат и срок. Состав участников меняется вместе с задачей: в одном контуре агент ищет данные, сотрудник интерпретирует их, сервис рассчитывает показатель, руководитель принимает решение. В другом контуре участвуют уже другие люди и инструменты.
Организацию можно описать через два слоя:
- Стабильный контур ответственности. Здесь живут деньги, полномочия, политика доступа, профессиональные стандарты и владелец результата.
- Динамический граф исполнения. Здесь задача разлагается на части и передаётся по маршруту, который зависит от компетенций, контекста, доступности и риска.
Отдел в такой модели перестаёт быть единственным каналом движения работы. Он остаётся домом компетенции и ответственности, исполнение при необходимости пересекает несколько функций.
Из чего состоит граф задач
Минимальная схема включает пять типов узлов.
Результат
Работа начинается с наблюдаемого результата: подготовлен договор, исправлена ошибка, собран отчёт, клиент получил ответ. Формулировка «заняться аналитикой» плохо маршрутизируется, потому что не задаёт состояния, в котором задачу можно принять.
Задачи и зависимости
Результат раскладывается на действия. Одни можно выполнять параллельно, другие требуют строгой последовательности. Исследование источников и поиск внутренних материалов допускают параллельную работу. Финальная редактура начинается после того, как доказательства собраны и противоречия разрешены.
Возможности исполнителей
Маршрут выбирается по способности выполнить действие. Исполнителем может быть сотрудник, ИИ-агент, внешний эксперт или программный сервис. Название должности здесь менее информативно, чем набор подтверждённых возможностей: получить данные, написать код, проверить договор, согласовать бюджет.
В исследовании адаптивного распределения задач для смешанных команд людей и роботов назначение зависит от различий в способностях, текущего состояния и неполной информации. Работа выполнена в симуляции мониторинга среды и не доказывает применимость модели к офисной компании. Для организационного дизайна она полезна как проверяемая аналогия: маршрут должен учитывать состояние задачи и исполнителя, а не только первоначальное назначение.
Данные и доступы
Даже подходящий исполнитель не должен получать все корпоративные данные. Для каждого перехода нужно определить минимально необходимый контекст и права. Эта логика совпадает с принципом наименьших привилегий: доступ выдаётся под действие, а не под общее обещание «помочь процессу».
Контроль и возврат
У задачи есть критерий приёмки, владелец и точка остановки. Если результат не проходит проверку, граф должен вернуть работу на конкретный участок или передать её человеку. Без такого возврата динамическая маршрутизация превращается в конвейер, который умеет двигаться только вперёд.
Маршрут зависит от свойств работы
Современные агентные фреймворки уже используют похожую логику. В практическом руководстве OpenAI описаны централизованная оркестрация и передача управления между агентами. В отдельном описании Agents SDK выделены исполнители, передачи, защитные ограничения и трассировка действий.
Из этого не следует, что каждой компании нужен рой агентов. Исследование Google Research на 180 конфигурациях показало, что несколько агентов могут улучшать результат на параллелизуемых задачах и снижать качество на последовательных. Независимые исполнители без механизма сверки также способны усиливать ошибки, тогда как централизованный оркестратор ограничивает их распространение.
Anthropic сообщает, что её многоагентная исследовательская система превзошла одиночного агента на 90,2% во внутренней оценке. Авторы одновременно отмечают высокую стоимость по токенам и слабую пригодность подхода для задач с плотными зависимостями и общим контекстом. Это результат конкретной системы и внутреннего теста, поэтому переносить цифру на обычные бизнес-процессы нельзя.
Маршрут следует проектировать по характеру работы. Параллельное исследование можно раздать нескольким исполнителям. Последовательную операцию с общей памятью лучше держать в одном контуре. Чем выше цена ошибки и необратимость действия, тем раньше задача возвращается владельцу.
Рабочая статья Multi-Agent AI Systems are Organizations предлагает рассматривать координацию ИИ-агентов через классические организационные вопросы: разделение труда, контроль и разрешение конфликтов. Авторы анализируют 1 642 трассы выполнения, однако публикация пока имеет статус working paper. Поэтому здесь она служит исследовательской рамкой, а не установленным законом.
Роль становится контекстом задачи
В привычной структуре роль часто прикреплена к человеку надолго. В графе задач один и тот же человек может быть владельцем результата в одном процессе, проверяющим в другом и источником экспертного решения в третьем. ИИ-агент также получает роль только внутри конкретного задания.
Это не отменяет должности. Модель просто добавляет более точный операционный уровень. Вместо общего «аналитик готовит отчёт» появляется контракт:
- триггер: наступил конец отчётного периода;
- результат: готов отчёт с проверенными источниками данных;
- исполнитель: агент сбора данных;
- необходимые возможности: запросы к разрешённым системам и нормализация таблиц;
- доступ: только чтение заданных источников;
- критерий приёмки: суммы сверены, расхождения перечислены;
- владелец: руководитель финансового процесса;
- условие остановки: источник недоступен или расхождение превышает установленный предел.
Такой контракт можно передать сотруднику, агенту или смешанной команде. Ответственность при этом не мигрирует автоматически вслед за исполнением. В предыдущем материале о работе ИИ-агентов я подробно разбирал, почему у результата должен оставаться человеческий владелец.
Что меняется в работе руководителя
В спроектированной таким образом системе руководитель может передать часть ручной маршрутизации правилам и сосредоточиться на качестве этих правил. Ему нужно определить, какие результаты считаются принятыми, какие исполнители подходят для разных классов задач и где проходит граница автономии. Реальную экономию времени ещё предстоит доказать на пилоте.
Появляется новая управленческая работа:
- поддерживать каталог возможностей людей и агентов;
- описывать зависимости между действиями;
- устанавливать правила маршрутизации;
- ограничивать доступы на каждом переходе;
- видеть журнал движения задачи;
- разбирать причины возвратов и остановок.
NIST AI Risk Management Framework рекомендует документировать роли, линии коммуникации, мониторинг и пересмотр решений в конфигурациях «человек — ИИ». Документ представляет рамку управления рисками и не задаёт готовую оргструктуру. Из этих требований я вывожу для графа задач принцип наблюдаемости: организация должна уметь восстановить, кто инициировал действие, почему был выбран исполнитель, какие права он получил и кто принял результат.
Где модель ломается
Граф не исправляет плохо поставленную работу. Если результат не определён, зависимости неизвестны, а критерии приёмки отсутствуют, автоматическая маршрутизация лишь быстрее размножит неопределённость.
Есть ещё четыре ограничения.
Плотный общий контекст. Некоторые задачи трудно разделить без потери смысла. Несколько исполнителей начинают повторять работу или расходиться в предположениях.
Локальная оптимизация. Каждый узел может успешно выполнить свою часть, пока итоговый процесс становится медленнее или дороже. Нужны метрики результата целиком; одной скорости отдельных шагов недостаточно.
Скрытая цена координации. Передачи требуют упаковки контекста, проверки и разрешения конфликтов. Большое число агентов не делает эту цену нулевой.
Размывание власти. Динамический маршрут легко спутать с отсутствием владельца. Деньги, доступ, юридические обязательства и необратимые решения должны оставаться в явном контуре полномочий.
Рабочая гипотеза поэтому звучит осторожно: часть операционной координации перейдёт от постоянной иерархии к наблюдаемому графу задач. Масштаб этого перехода будет разным для каждого процесса.
С чего начать без реорганизации
Для первого эксперимента не нужно менять штатное расписание. Выберите обратимый процесс без критичных денежных операций, юридических решений и записи в основные данные. Заранее ограничьте пилот сроком или числом однотипных задач.
- Зафиксируйте исходные показатели прежнего маршрута: время цикла, число передач, возвратов и ошибок, а также стоимость выполнения.
- Назовите событие, которое запускает работу, и результат, которым она заканчивается.
- Разложите путь на действия и отметьте зависимости.
- Для каждого действия перечислите нужные возможности, данные и доступы.
- Укажите возможных исполнителей: людей, агентов и сервисы.
- Добавьте критерии приёмки, владельца и условия остановки.
- Проведите заранее установленное число задач по новому маршруту и сохраните журнал переходов.
- Сравните показатели с исходным процессом и проверьте, где возникли очередь, дублирование, лишняя передача или потеря контекста.
- Примите одно из трёх решений: оставить маршрут, изменить конкретные переходы или остановить эксперимент.
После такого прохода становится видно, какие участки действительно готовы к агентам, а какие пока держатся на неявном знании конкретного сотрудника.
Когда второй слой полезен
Оргсхема ещё долго будет нужна. Она хранит устойчивые договорённости о власти, компетенции и ответственности. Но рядом с ней появляется другая карта, более подвижная и ближе связанная с реальной работой.
На этой карте организация состоит из результатов, задач, возможностей, доступов и решений о передаче. Люди и агенты подключаются к ней по мере необходимости, а владелец видит весь маршрут и сохраняет право остановить процесс.
Моя рабочая гипотеза состоит в том, что компании будут добавлять к формальной структуре второй слой. В нём работа движется по наблюдаемому графу задач, при этом полномочия и ответственность остаются явными. Пилоты должны показать, для каких процессов такая модель действительно быстрее, дешевле или надёжнее прежнего маршрута.
Источники
- OpenAI: A practical guide to building agents
- OpenAI: New tools for building agents
- Anthropic: How we built our multi-agent research system
- Google Research: Towards a science of scaling agent systems
- NIST AI Risk Management Framework: Govern
- NIST: AI Risk Management and Human-AI Interaction
- Adaptive Task Allocation in Multi-Human Multi-Robot Teams
- Multi-Agent AI Systems are Organizations
Следующий шаг
Продолжите с материалом «Кто отвечает за результат, если работу сделали ИИ-агенты?», чтобы связать динамическое исполнение с владельцем результата, проверкой и точками остановки.
Связанные материалы
- Смерть компании: что такое организационная сингулярность
- Paperclip — open-source платформа, которая собирает AI-агентов в компанию
- Action-Based Workflow Engine: архитектурный паттерн
Такой разбор полезен компаниям, которые уже передают агентам реальные участки работы и хотят сделать маршруты задач наблюдаемыми и управляемыми.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
Если хотите разобрать свою задачу — напишите мне Если хотите разобрать свою задачу — напишите мне.
Можно прийти с идеей, черновым контекстом или уже живой задачей. Помогу быстро понять, где реальный следующий шаг, а где лишний шум.
Обычно хватает 2–3 сообщений, чтобы понять, могу ли я здесь реально помочь и в каком формате лучше двигаться дальше.
Дальше по теме
Консультации, аудит процессов, работа с контентом и сайтами, сессии для команд и решения под конкретную задачу.