Открыть workspace
IAM AGENT · WEB · DESKTOP · CLI

Дайте задачу команде AI-агентов.

IAM Agent строит план, распределяет работу между ролями и моделями, показывает каждый маршрут и останавливается на контрольных точках — в Web, Desktop и CLI.

Открыть Web workspace CLI и SDK
Production Core Cloud Human approvals Provider-neutral routes Web / Desktop / CLI Stage-first releases
Agent run proof running
goal
Подготовить релиз 2.4: собрать changelog, прогнать тесты и получить review-подтверждение.
plan · 4 tasks
  1. Coordinatorплан и распределение задач route ready
    provider iam-router · model sonnet-4.6
    executor core-cloud · policy ask
    next ожидает подтверждения плана
  2. Developerсборка changelog · node-a running
    provider cursor-sdk · model composer-2.5
    executor node-a (customer) · policy ask
    next результат в артефакт
  3. QAожидает артефакт от Developer waiting
    provider iam-router · model haiku-4.6
    executor node-b (customer) · policy read-only
    next запуск 18 тестов после артефакта
  4. Reviewerevidence gate перед завершением approval required
    действие подтвердить evidence релиза
    эффект задача переходит в completed
    next решение человека
Рискованное действие ждёт решения: Reviewer · evidence gate
evidence
3 файла изменено · 18 тестов пройдено · review passed
  1. Цель: подготовить релиз 2.4.
  2. План: 4 задачи.
  3. Coordinator — маршрут готов.
  4. Developer — выполняется на node-a.
  5. QA — ожидает артефакт.
  6. Reviewer — требуется подтверждение человека.
  7. Evidence: 3 файла, 18 тестов, review пройден.
Операционная модель

Разница не в модели, а в контуре

Мы сравниваем операционные модели, а не маркетинговые формулировки.

Обычный AI assistant

  • Один чат на все задачи
  • Одна модель без выбора маршрута
  • Действия инструментов неочевидны
  • Нет ролей и распределения работы
  • «Готово» означает сгенерированный текст

IAM Agent

  • План задач с зависимостями
  • Явные роли: coordinator, developer, QA, reviewer
  • Выбранный provider, модель и исполнитель видны
  • Approval и review как контрольные точки
  • Задача завершена после review, не после генерации
Жизненный цикл

Цель → план → маршруты → approval → выполнение → review → evidence

Каждый шаг показывает: что делает система, что видит человек, что может заблокировать прогресс и какое evidence остаётся.

система
Разбирает формулировку, определяет scope и требования
человек видит
Композер цели с ограничениями и критериями
может заблокировать
Нет критериев приёмки или недоступен workspace
evidence
Запись цели и ограничений в задаче
система
Coordinator формирует задачи и зависимости
человек видит
Список задач, назначенные роли, готовность промптов
может заблокировать
Незаполненный промпт роли или циклическая зависимость
evidence
Версия плана с назначениями
система
Подбирает маршрут по capability fit и политике
человек видит
RouteRationaleCard с обоснованием и fallback-цепочкой
может заблокировать
Нет доступного узла, provider недоступен, policy запрещает
evidence
Зафиксированное решение маршрутизации
система
Проверяет готовность плана, маршрутов и лимитов
человек видит
Чеклист запуска и оставшиеся блокеры
может заблокировать
Незакрытый пункт чеклиста или отсутствие лизы узла
evidence
Кто и когда разрешил запуск
система
Выполняет задачи на назначенных исполнителях
человек видит
Board lanes, статусы воркеров, расход токенов
может заблокировать
Ошибка инструмента, потеря узла, исчерпание лимита
evidence
Таймлайн событий задачи
система
Останавливается и запрашивает решение по политике
человек видит
Карточку запроса: действие, цель, эффект, риск
может заблокировать
Истечение срока запроса или отказ
evidence
Решение, автор и комментарий
система
Собирает артефакты и результаты верификаторов
человек видит
Ledger: файлы, тесты, решения, состояние задачи
может заблокировать
Непройденный верификатор или отклонённый review
evidence
Полный след выполнения задачи
Один продукт, четыре поверхности

Разные ответственности, один контур

Web управляет Swarm и fleet. Desktop выполняет локальную работу. CLI автоматизирует серверный контур. SDK встраивает управление в ваш продукт.

Hosted Web

production

Проектное пространство и управление командой агентов.

  • boards и Work Inbox
  • approvals и review
  • Swarms и Fleet
  • schedules, policies, metrics
composer → launch readiness
board · approval queue · evidence

Desktop

проверка manifest

Локальные файлы, код и эта машина как исполнитель.

  • Chat, Cowork, Code, Browser
  • локальные инструменты
  • персональные сессии
  • this machine as executor
ModeSidebar · timeline
local workspace · executor node-local
Fleet и Swarm — в Web Command Center

CLI

release channel

SSH, серверы, CI и автоматизация без GUI.

  • JSON / JSONL вывод
  • workflows
  • node runtime
  • диагностика
iam-agent workflow start "Prepare the release"
--template development_orchestrator

SDK

package docs

Встраивание управления агентами в свой продукт.

  • route preview до запуска
  • approval handlers
  • session automation
  • task timeline integration
await iam.previewSessionLaunch({
agentId: "developer"
})
Режимы работы

Пять режимов под разные задачи

Chat

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

turn user → agent
tool read · attach · memory
timeline · usage tokens

Cowork beta

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

plan → artifacts → action items
scope project task work

Code

Задачи в границах workspace: файлы, shell, git-контекст и approvals. Отображение diff и терминала зависит от текущей сборки.

workspace bound
files · shell · git context
approval для write / execute

Browser

Автоматизация браузера и локальный превью. Внешние хосты требуют явной конфигурации и разрешения.

local preview
external hostexplicit permission

MultiWork Local Swarm workflow

Локальный движок workflow для ролевой фазовой работы через CLI и Desktop. Групповое управление fleet и Swarm остаётся в Hosted Web.

phases → roles → tasks
group controlHosted Web
Swarms

Одна цель. Несколько ролей. Один контрольный контур.

Coordinator создаёт план, ролевые агенты выполняют задачи, воркеры работают на конкретных исполнителях. Оператор управляет Swarm из Web, CLI инспектирует headless, Desktop показывает только работу этого исполнителя.

swarm goal
Реализовать contract-first API для платёжного модуля
4
роли
7 / 11
задачи
3
узла
1
approval
  • ANAnalyst
    done
    contract · node-a
    iam-router · sonnet-4.6
  • DVDeveloper
    running
    implementation · node-b
    cursor-sdk · composer-2.5
  • QAQA
    waiting
    tests · node-c
    ждёт артефакт Developer
  • RVReviewer
    approval
    evidence gate
    решение человека
checkpoint brief
ОжидаетReviewer · evidence gate
Route coverage4 / 4 роли · fallback настроен
Ограничение ёмкости3 узла · role caps · leases
Группаpause · resume · cancel из Web
Coordinator ├─ Analyst contract ├─ Developer implementation ├─ QA tests └─ Reviewer evidence gate

Ёмкость ограничена узлами, лизами, role caps и политикой — произвольного параллелизма нет.

Прозрачность маршрута

До запуска видно, кто и где выполнит задачу.

Route rationaledispatch allowed
Источникplan task · developer step 2
Агентdeveloper
Providercursor-sdk
Модельcomposer-2.5
Fallback chaincursor-sdkiam-routerollama local
Reasoning modestandard
Executor / nodenode-b · customer worker
Capability fitcode edit · shell · git
Permission profileask (write / execute)
Причинаcapability match + доступная лиза узла
IAM Router
Каталог моделей, маршрут и доступ к провайдерам.
OpenAI-совместимые endpoints
Стандартный контракт для внешних провайдеров.
Локальный Ollama
Возможности зависят от настроенной модели и runtime.
Внешние CLI / ACP runtimes
Поддерживаемые агентские среды через явные контракты.
Поддержка различается

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

Контроль человека

Автономность задаётся политикой

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

1
Подтверждение плана
Оператор проверяет задачи, роли и маршруты до запуска.
2
Разрешение инструмента
Write, execute и network-действия проходят через профиль разрешений.
3
Уточнение
Агент задаёт вопрос вместо догадки, когда данных недостаточно.
4
Review задачи
Результат проверяется до перехода в completed.
5
Решение о продолжении
Возобновление сессии после паузы или смены поверхности.
6
Эскалация
Просроченный или спорный запрос передаётся выше.
7
Прерывание и отмена
Оператор останавливает задачу или Swarm целиком.
Требуется решениеexpires 12 мин
Действиеshell execute
Цельnode-b · workspace/payments
Командаnpm run migrate:apply
Эффектизменение схемы БД в staging
Рискнеобратимо в рамках среды
Эскалацияrelease-manager через 12 мин
Комментарийукажите причину при отказе

Мы не утверждаем, что человек подтверждает каждое read-only действие: политики намеренно допускают разные уровни автономности.

Evidence и наблюдаемость

Задача завершена после review, не после генерации текста

Ledger различает источник каждой записи: сводка модели, результат инструмента, решение reviewer, проверенный верификатор и здоровье платформы.

Execution evidence ledgertask · payments-contract-api
model summaryСформирован contract-first спек для 4 endpoint'ов. Сводка модели — не подтверждение факта.14:02
tool resultEdit · 3 файла изменено · +148 −22 · node-b14:11
verifiedVerifier · 18 / 18 тестов пройдено · exit 014:19
model usagecomposer-2.5 · 42.1k токенов · spend risk в пределах лимита14:19
route fallbackcursor-sdk недоступен 8s → fallback iam-router · выполнение продолжено14:22
reviewer decisionReviewer подтвердил evidence · задача completed14:26
platform healthnode-b healthy · node-c degraded → задача переназначена14:27

Скрытая цепочка рассуждений не отображается. Вместо неё — ограниченные сводки статуса и причины.

Локальная работа и суверенный путь

Где выполняется работа и что пересекает границу

Managed control plane
  • состояние задач, политика, аудит
  • управление маршрутами и расписаниями
Customer executor
  • файлы workspace
  • инструменты и shell
  • локальный runtime

Cloud control + customer executors

Управляющий контур управляется нами, работа выполняется на подключённых узлах.

production

Customer-managed workers

CLI/Desktop node runtime, workspace остаётся на машине заказчика.

вне managed uptime

Local model path

Ollama или поддерживаемый локальный провайдер; возможности зависят от модели.

по конфигурации

Self-hosted / dedicated

Требуется архитектурная сессия. Не все интеграции работают air-gapped.

qualification
API-ключи шифруются at rest
OS keychain-backed material там, где поддерживается
Файловые инструменты ограничены
только настроенный workspace_root
Shell в платформенном sandbox
macOS sandbox-exec · Linux bwrap · Windows отдельно
Профили разрешений
read / write / execute / network раздельно
WASM / WASI executors
opt-in и capability-gated
Журнал аудита
события выполнения и approvals
Границы формулировок
  • Мы не заявляем «код никогда не покидает устройство» — это зависит от маршрута, модели и телеметрии
  • Sandbox-реализации macOS и Linux не покрывают Windows автоматически
  • Подписанные бандлы можно требовать, но доверие каталога зависит от конфигурации
  • Режим bypass, выбранный пользователем, не является границей безопасности
IAM интеграции

Опциональные связи, а не обязательный стек

IAM.Router

Каталог моделей, маршрут и доступ к провайдерам.

optionalhostedcurrent

IAM.Secure

Инспекция и политика там, где настроено.

optionalhostedcurrent

IAM.Identity

Hosted SSO и идентичность тенанта.

required для hostedhosted

IAM Marketplace

Поиск и установка пакетов агентов.

optionalpreview

IAM.Hosting

Доверенный runtime для hosted-агентов.

optionalactive dev

IAM.Core

MCP, инструменты и композиция продуктов.

optionalactive dev

External MCP / ACP

Инструменты и агентские runtimes через явные контракты.

optionallocal / hosted

Граница

Marketplace и Hosting расширяют IAM Agent — они не являются режимами Desktop.

Сценарии

Как это выглядит в работе

Поставка ПО

стартHosted Web
ролиdeveloper · QA · reviewer
approvalплан и evidence gate
результатреализация + пройденные тесты

Release operations

стартCLI по расписанию
ролиcoordinator · QA
approvalоператор перед production
результатstaging-first прогон + evidence

Исследование и анализ

стартWeb или Desktop
ролиanalyst ×N · reviewer
approvalreview синтеза
результатсводка с цитатами источников
Цитаты не гарантируют фактическую корректность

Обслуживание fleet

стартHosted Web + CLI
ролиoperator · remediation agent
approvalreason-gated действия
результатздоровье узлов и журнал

Enterprise workflow

стартSDK в своём продукте
роликастомные
approvalчерез ваш обработчик
результатуправление агентами внутри портала
Разработчикам

Контракты и точки интеграции

bash · проверка среды и задача
iam-agent doctor
iam-agent code "Summarize the current changes" --output jsonl

# ролевой workflow
iam-agent workflow start "Prepare the release" \
  --template development_orchestrator

Показаны только команды, подтверждённые текущим CLI reference.

typescript · route preview до запуска
const preview = await iam.previewSessionLaunch({
  agentId: "developer",
  text: "Check the route before creating a session.",
  provider: "cursor-sdk",
  modelId: "composer-2.5",
  permissionProfileId: "ask",
});

Также доступны approval callbacks и сводка завершения задачи. API — из текущего пакета @iam/agent-sdk.

mcp · внешние серверы инструментов
{
  "mcpServers": {
    "filesystem": { "command": "npx", "args": ["@modelcontextprotocol/server-filesystem"] }
  }
}

Инструменты внешних MCP-серверов подключаются через явные контракты.

acp · сессии внешних агентских runtimes
profile: strict
permissions: routed through IAM approval
session: external agent runtime

Strict-профиль направляет разрешения через IAM approval — внешний runtime не обходит контроль.

node runtime · подключение исполнителя
Managed control plane
  └─ lease → node-a (workstation)
             node-b (server / CI)

Сервер или рабочая станция подключается как executor. Managed uptime не покрывает инфраструктуру заказчика, если это не оговорено договором.

Trust и release evidence

Что подтверждено сейчас

Commercial evidence
  • Production Core Cloud — управляющий контур развёрнут в production
  • 22 / 22 release checks — полный гейт на staging и production
  • Stage-first promotion — продвижение только после staging
  • PostgreSQL HA + backup evidence — реплики Web/API и БД
  • External authenticated probes — внешние read-only проверки
release candidate 2026-08-03
gate staging 22/22 · production 22/22
replicas Web/API multi-replica
db PostgreSQL HA + verified backup
probes external authenticated · read-only
policy stage-first promotion required
SLA scope
Pro Core Cloud — 99.5%
Базовая доступность после договорной активации.
Desktop и CLI
Отдельный scope поддержки; зависит от подписанных артефактов и Order Form.
Customer workers
Инфраструктура заказчика вне managed uptime, если не оговорено договором.
Сторонние провайдеры
Доступность внешних моделей и runtimes не входит в наш SLA.

Enterprise 99.9% не предлагается.

Доступность поверхностей

Surface availability · статус читается из release manifest
ПоверхностьСтатусДействие
Core Cloud WebproductionОткрыть workspace
Desktop macOSmanifest check
Desktop Windowsmanifest check
Desktop Linuxmanifest check
CLIrelease channelДокументация
SDKpackage docsSDK docs
Self-hostedqualificationОбсудить внедрение

Статус релиза не выводится из того, что исходный код собирается.

Формы планов

Core Cloud

hosted control plane
  • Web-контур управления
  • управляемое состояние тенанта, сессий и досок
Открыть workspace

Team / Pro

order form activated
  • активация коммерческим Order Form
  • 99.5% baseline после активации
Запросить условия

Enterprise / Dedicated

custom scope
  • развёртывание, поддержка, identity
  • scope customer workers по договору
Обсудить внедрение

Desktop / CLI

signed artifacts
  • статус зависит от подписанных артефактов
  • поддержка по Order Form
Выбор поверхности

Где должна выполняться работа?

Enterprise

Архитектурная сессия

Обсудим поверхности, расположение исполнителей, требования к моделям и identity. Развёртывание уточняем по продукту.

Мы не запрашиваем
  • API-ключи и production secrets
  • URL репозитория с credentials
  • исходный код
Укажите корпоративный email
Укажите компанию
Опишите сценарий

Запрос получен

Мы изучим сценарий и вернёмся с предложением по поверхностям и расположению исполнителей.

FAQ

Прямые ответы

Обычный чат — это один поток с одной моделью. IAM Agent строит план задач, назначает роли, показывает выбранный provider, модель и исполнителя до запуска, останавливается на approval для рискованных действий и завершает задачу только после review. Результат — не текст, а evidence: артефакты, изменённые файлы, результаты верификаторов и решения людей.
Web — проектная работа команды: доски, Work Inbox, approvals, Swarms, fleet, расписания и политики. Это единственная авторитетная поверхность для группового управления. Desktop — локальные файлы и код, персональные сессии, эта машина как исполнитель. CLI — серверы, SSH, CI и автоматизация с JSON/JSONL-выводом.
Swarm — управляемая группа ролевых агентов под одной целью с групповым контролем из Hosted Web. MultiWork — локальный движок workflow для ролевой фазовой работы через CLI и Desktop; внешнее название — «Local Swarm workflow». Групповое управление fleet и Swarm остаётся в Web, а не в Desktop.
Продукт спроектирован provider-neutral: IAM Router, OpenAI-совместимые endpoints, локальный Ollama и поддерживаемые внешние CLI/ACP runtimes. Набор провайдеров различается по поверхности и сборке — мы не публикуем статичное обещание «поддерживается любая модель везде». Актуальный список уточняется для вашей конфигурации.
Да. Управляющий контур может быть managed, а выполнение — на подключённых узлах через CLI/Desktop node runtime. Workspace остаётся на машине заказчика. Managed uptime не покрывает инфраструктуру заказчика, если это не оговорено договором. Полностью self-hosted вариант требует архитектурной сессии.
Файловые инструменты ограничены настроенным workspace_root. Shell выполняется в доступном платформенном sandbox с политикой команд: macOS использует sandbox-exec, Linux — bwrap; для Windows механизм отличается и указывается отдельно. Профили разрешений разделяют read, write, execute и network/destructive-действия. WASM/WASI executors — opt-in и capability-gated.
Это определяет политика, а не универсальное правило. Обычно approval требуется для write-, execute-, network- и необратимых действий, а также для подтверждения плана и review результата. Мы не утверждаем, что человек подтверждает каждое read-only действие — политики намеренно допускают разные уровни автономности. Режим bypass, выбранный пользователем, не является границей безопасности.
Состояние задач и сессий живёт в управляющем контуре, поэтому задачу можно наблюдать и продолжать из Web, инспектировать из CLI и выполнять локально в Desktop. Возобновление — это явное решение человека, а не автоматическая передача. Полный cross-device handoff мы не заявляем как готовую функцию: возможности зависят от текущей сборки и конфигурации.
IAM.Router даёт каталог моделей и маршрут (опционально). IAM.Secure добавляет инспекцию и политику там, где настроено (опционально). IAM.Identity обеспечивает hosted SSO и идентичность тенанта — требуется для hosted-контура. Marketplace и Hosting расширяют IAM Agent, но не являются режимами Desktop. Каждая интеграция помечена как optional/required и current/preview.
Pro Core Cloud: 99.5% после договорной активации. Desktop, CLI, customer workers и сторонние провайдеры имеют отдельный scope поддержки. Доступность внешних моделей и runtimes не входит в наш SLA. Enterprise 99.9% не предлагается.
Кнопка загрузки Desktop появляется только при наличии подписанного release manifest для платформы; иначе доступна заявка на beta. Статус CLI читается из release channel. Мы не выводим статус релиза из того, что исходный код собирается, и не заявляем store-распространение, подписанное авто-обновление, офлайн-режим, голосовой ввод или биометрическую разблокировку без подтверждающего release evidence.
Self-hosted и dedicated варианты обсуждаются в рамках архитектурной сессии. Мы не даём общего обещания, что каждая интеграция работает air-gapped: часть возможностей зависит от внешних провайдеров и сетевых контрактов. Локальный путь моделей через Ollama или поддерживаемый локальный провайдер возможен, но возможности определяются настроенной моделью и runtime.
Через @iam/agent-sdk: предпросмотр маршрута до запуска (previewSessionLaunch), обработчики approval, автоматизация сессий и интеграция таймлайна задач в свой портал. Это позволяет показать пользователям план, маршрут и контрольные точки внутри вашего продукта, сохранив контур контроля IAM Agent.
Следующий шаг

Выберите способ начать

Начать в Web

Откройте workspace и запустите первую управляемую задачу.

Открыть Web workspace

Работать локально

Локальные файлы, код и эта машина как исполнитель.

Развернуть для команды

Поверхности, узлы, identity и scope поддержки.

Обсудить внедрение
CLI docs SDK docs Архитектура
Открыть Web workspace