Это часть серии об ИИ-компании — о том, как ИИ-агенты меняют ответственность, структуру, экономику и практику управления.
Организационная схема хорошо отвечает на вопрос, кто числится в компании. Она гораздо хуже показывает, как конкретная работа проходит от запроса до результата.
Клиенту нужен договор. Руководителю — прогноз. Сайту — новый материал. Продукту — исправленная ошибка. Для каждого результата приходится собирать временную конфигурацию из людей, данных, полномочий, программ и всё чаще ИИ-агентов. Формальная должность участника сообщает лишь небольшую часть того, что нужно для выполнения задачи.
Поэтому название «компания без должностей» здесь намеренно провокационное. Я не предлагаю отменить трудовые отношения, карьеру или постоянные команды. Речь о втором слое организации, в котором работа распределяется через временные роли с явным результатом, сроком и границами полномочий.
Должность и роль отвечают на разные вопросы
Должность остаётся относительно устойчивой. Она связывает человека с компанией и обычно определяет место в структуре, уровень полномочий, оплату, область профессиональной ответственности и отношения с руководителем.
Роль существует внутри конкретной работы. Она отвечает на другие вопросы:
- какой результат нужно получить;
- кто выполняет эту часть маршрута;
- какие данные и инструменты доступны;
- какие решения исполнитель может принимать самостоятельно;
- кто проверяет результат;
- когда роль заканчивается.
Например, должность человека может называться «руководитель маркетинга». В одном процессе он выступает владельцем результата, в другом — экспертом, в третьем — проверяющим, а в четвёртом вообще не участвует. ИИ-агент тоже может временно занять роль исследователя, редактора, диспетчера или проверяющего, если для неё описан исполнимый контракт.
В статье «Организация как граф задач» я описывал компанию как два связанных слоя. Устойчивая структура удерживает бюджеты, доступы и ответственность. Динамический граф проводит конкретную задачу между исполнителями и контрольными точками. Временная роль соединяет эти слои: получает полномочия от структуры и место в маршруте от задачи.
В модели десяти контуров ИИ-компании эта конструкция находится на пересечении исполнения, идентичности, доступа и ответственности. Здесь я хочу увеличить масштаб и разобрать её минимальную единицу — временную роль.
Четыре сущности, которые полезно разделить
Ниже я предлагаю авторскую модель, которую сейчас применяю к собственным рабочим процессам. Это не принятый стандарт организационного проектирования, а конструкция, которую можно проверять на реальных задачах. В ней есть четыре разных объекта.
Должность — устойчивое место человека в организации.
Возможность — то, что человек, агент или сервис в принципе умеет делать при заданных условиях.
Роль — временная функция внутри процесса с определённым результатом и полномочиями.
Исполнитель — конкретный человек, агент, сервис или их связка, получившие эту роль для одного запуска.
Это разделение избавляет от двух распространённых ошибок. Первая — автоматически направлять любую задачу человеку с подходящим названием должности. Вторая — считать, что мощный универсальный агент может получить широкие доступы и самостоятельно решить, где его использовать.
Вместо этого система сначала определяет необходимую роль, затем подбирает исполнителя по возможностям, доступности, стоимости и допустимому уровню риска.
В технических системах уже существуют отдельные элементы такого подхода. В OpenAI Agents SDK передача работы позволяет одному агенту направить задачу специализированному агенту и отдельно описать входные данные для такой передачи. В протоколе Agent2Agent карточка агента описывает его возможности, навыки, поддерживаемые интерфейсы подключения и схемы аутентификации, а сама задача имеет идентификатор, состояние и жизненный цикл. Эти механизмы ещё не образуют модель компании, но показывают, как отдельные элементы маршрутизации можно представить технически.
Из чего состоит контракт временной роли
Под контрактом роли я понимаю не трудовой или гражданско-правовой договор, а исполнимое описание конкретной части работы: результата, входных данных, полномочий, критериев приёмки, передачи и срока действия.
В общей модели документы вложены друг в друга. Паспорт контура описывает процесс целиком: цель, владельца, источники, риски, наблюдаемость и откат. Контракт результата определяет, что должно быть получено и кто это принимает. Контракт роли описывает один участок исполнения. А задание исполнителю становится конкретным экземпляром этого контракта для одного запуска.
Фраз «пусть агент исследует тему» или «подключим юриста» для этого недостаточно. Исполнимый контракт роли можно описать восемью полями.
1. Результат
Что именно должно появиться после работы: документ, решение, изменение в системе, проверенный набор данных или переданный следующему участнику пакет.
2. Условие запуска
Какое событие активирует роль: новая заявка, утверждённая структура статьи, ошибка мониторинга, наступивший срок или решение владельца процесса.
3. Вход и контекст
Какие данные получает исполнитель, где находится актуальная версия и какие прежние решения нужно учитывать.
4. Возможности и инструменты
Что исполнитель должен уметь и какими средствами может пользоваться. Здесь описывается функция, а не имя заранее выбранного человека или агента.
5. Полномочия
Что разрешено читать, создавать, изменять, отправлять и подтверждать. Полномочия выдаются на конкретный контур и по возможности ограничиваются временем его выполнения.
6. Критерии приёмки
Как владелец или проверяющий поймёт, что результат достаточен. Проверяется полезность и корректность результата; одного появившегося файла недостаточно.
7. Передача и остановка
Кому уходит результат, в каких случаях работа возвращается на исправление и при каком событии исполнитель обязан остановиться и привлечь человека.
8. Срок жизни
Когда роль прекращает существование, права отзываются, а незавершённая работа получает нового владельца или закрывается.
Такой контракт можно выдать сотруднику, внешнему специалисту или ИИ-агенту. От природы исполнителя зависят проверки и уровень автономности, однако каркас задачи остаётся общим.
Как роль появляется и исчезает
Работа с временными ролями выглядит как короткий жизненный цикл:
- Появляется задача с ожидаемым результатом.
- Процесс определяет необходимые роли и последовательность передач.
- Для каждой роли подбирается исполнитель с подходящими возможностями.
- Исполнитель получает контекст и ограниченные полномочия.
- Ход работы фиксируется, а результат проходит проверку.
- Владелец принимает результат или возвращает его на доработку.
- После завершения роль закрывается, временные доступы отзываются.
Маршрут может быть заранее задан кодом или собираться динамически. Anthropic называет один из таких технических паттернов схемой «оркестратор — исполнители»: центральная модель разбивает сложную задачу на подзадачи, назначает их специализированным агентам и собирает результат. Авторы отдельно отмечают, что схема полезна для задач, состав которых нельзя полностью предсказать заранее.
Для компании одной технической оркестрации мало. Должны сохраниться владелец результата, правила назначения, наблюдаемость, стоимость и право человека остановить маршрут.
Один результат — один владелец
В предлагаемой модели для каждого принимаемого результата должен быть назван один владелец. Временная роль не должна размывать ответственность. Наоборот, она позволяет отделить выполнение от владения результатом.
Исполнителей может быть несколько. Они могут меняться по ходу задачи. Один агент собирает источники, другой готовит текст, человек проверяет позицию, технический процесс размещает материал в CMS. При этом у результата остаётся один явно названный владелец, который принимает итог и отвечает за выданные полномочия.
В GitLab похожий принцип оформлен через DRI — непосредственно ответственного участника. Он назначается на конкретный проект, инициативу или активность. В команде GitLab Distribution одна из ролей DRI передаётся между инженерами по недельной ротации. Это полезный пример того, что ответственность может быть устойчивой в момент выполнения, даже если её носитель меняется от периода к периоду.
В агентном процессе этот принцип становится ещё важнее. В предлагаемой модели ИИ способен выполнить роль, но владельцем результата остаётся человек или организация, которые дали ему полномочия. Подробнее эту границу я разбирал в статье «Кто отвечает за результат, если работу сделали ИИ-агенты?».
Как это уже выглядит в работе pimenov.ai
В редакционном процессе pimenov.ai один материал проходит несколько ролей:
- исследователь собирает источники и отмечает ограничения;
- автор превращает фактуру в полный текст;
- проверяющий ищет неподтверждённые утверждения, смысловые провалы и ошибки;
- визуальный исполнитель готовит обложку и иллюстрации;
- оператор CMS создаёт черновик после отдельного подтверждения;
- владелец материала принимает решение о публикации;
- технический контур проверяет, что страница действительно доступна читателю.
Некоторые роли выполняет агент, некоторые остаются за мной. Один исполнитель может последовательно занимать несколько ролей, но переходы между ними сохраняются. Подготовленный текст ещё не разрешает запись в Notion. Черновик в Notion не разрешает публикацию. Статус «Опубликовано» в CMS сам по себе не доказывает, что страница появилась на сайте.
Такое разделение кажется избыточным, пока всё работает. Его ценность проявляется при ошибке: можно установить, какая роль получила неверный контекст, кто выдал полномочия, где должна была сработать проверка и какое состояние нужно восстановить.
Где модель ломается
У временных ролей есть собственные риски.
Роль без владельца. Все выполнили свою часть, а за итог никто не отвечает.
Слишком короткий горизонт. Люди начинают оптимизировать локальный результат и перестают развивать знания, отношения и инфраструктуру.
Скрытая постоянная работа. Организация называет роль временной, хотя функция нужна ежедневно. В этом случае временный контракт лишь маскирует потребность в устойчивой команде.
Каталог возможностей без доказательств. Человеку или агенту приписывают навык по самоописанию, не проверяя его на реальной задаче.
Полномочия переживают роль. Задача закончилась, а доступ к данным, деньгам или публикации остался.
Алгоритмическая бесхозность. Система сама назначает исполнителей, но никто не отвечает за правила маршрутизации и их последствия.
Поэтому компания с временными ролями всё равно нуждается в постоянных элементах: стратегии, культуре, развитии людей, владельцах систем, правилах безопасности и юридической конструкции. Динамический слой не отменяет организацию. Он делает движение работы видимым и управляемым.
С чего начать без реорганизации
Для проверки модели не нужно переписывать штатное расписание. Достаточно выбрать один повторяющийся процесс и описать одну роль внутри него.
Возьмите задачу, которую регулярно передают между людьми или уже частично выполняют с помощью ИИ. Заполните восемь полей контракта. Для первого наблюдения я бы провёл как минимум три запуска и сохранил:
- кто получил роль;
- какие входы и права были выданы;
- сколько заняло выполнение;
- какие проверки не прошли;
- сколько потребовалось ручного вмешательства;
- был ли результат принят владельцем.
Это ещё не репрезентативная выборка, но её обычно достаточно, чтобы увидеть первые разрывы: неявные входы, лишние полномочия, слабые критерии приёмки и знания, которые существуют только в голове одного человека. После этого можно решать, существует ли роль как отдельная единица работы, можно ли менять её исполнителя и какие условия требуют дополнительной проверки.
Что приходит на смену жёсткой привязке работы к должности
В предлагаемой модели должности сохраняются. Рядом с ними появляется более точный язык исполнения:
- задача описывает требуемое изменение;
- роль задаёт контракт части работы;
- возможность показывает, кто способен её выполнить;
- исполнитель получает роль на ограниченный срок;
- владелец принимает результат и сохраняет ответственность.
Чем больше в процессах ИИ-агентов, тем полезнее это разделение. Организация перестаёт спрашивать только «кто у нас за это отвечает по должности?» и начинает видеть, какой результат нужен, какая роль должна возникнуть и кому можно безопасно её доверить.
Следующий шаг
Как подготовить компанию к ИИ-агентам за 30 дней
Связанные материалы
- Статья: Кто отвечает за результат, если работу сделали ИИ-агенты?
- Блог: Соберите план — остальное сделают агенты
- База знаний: Права доступа и роли: почему агенту нельзя давать все ключи от квартиры
Если вы хотите проверить эту модель в своей компании, начните с одного процесса и одного контракта роли. Такой разбор особенно полезен собственникам и руководителям, которым нужно соединить людей и агентов без потери ответственности.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov