Движок процессов — опишите любую команду обычными словами

Что он делает

Вы пишете бриф вроде такого:

«Мне нужен Алекс как PM, чтобы задать требования, Сэм — чтобы собрать материал, Джордан — чтобы проанализировать результаты, Райли — чтобы написать пост. Алекс управляет всеми переходами и проверяет каждую передачу».

Forge разбирает его (на любом языке), собирает WorkflowSpec из именованных ролей, переходов и управляющего агента, даёт вам отредактировать и подтвердить, а затем запускает. Вывод каждой роли становится коммитом в ветке вашего git-репозитория. Алекс — управляющий агент — проверяет каждую передачу и решает: пропустить к следующей роли, вернуть текущую с инструкциями по доработке или эскалировать вам на разбор.

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

Три примера процессов на одном движке

Контентный процесс — Алекс/Сэм/Джордан/Райли:

Доставка софта — самый зрелый архетип:

Процесс триажа поддержки:

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

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

stateDiagram-v2
    [*] --> AwaitingHandoff
    AwaitingHandoff --> Validating: предыдущая роль закончила
    Validating --> Advancing: вердикт = пропустить
    Validating --> Enriching: вердикт = доработать (в пределах лимита)
    Validating --> Escalating: вердикт = эскалировать (или лимит исчерпан)
    Enriching --> AwaitingHandoff: перезапуск предыдущей роли
    Advancing --> [*]
    Escalating --> OperatorReview
    OperatorReview --> Advancing: оператор пропускает принудительно
    OperatorReview --> [*]: оператор прерывает

Три опоры

1. Сборка процесса из естественного языка

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

2. Паттерн управляющего агента

Каждый переход между ролями проходит через назначенного управляющего агента (обычно роль вида PM, но это может быть любой персонаж). На входе: передача предыдущей роли, исходный бриф и накопленный контекст. На выходе — вердикт: пропустить, доработать или эскалировать.

• Пропустить — передача хороша, следующая роль стартует сразу.
• Доработать — в передаче конкретные пробелы; предыдущая роль перезапускается с явными инструкциями. Лимит повторов ограничен.
• Эскалировать — пробелы, которых круг с моделью не закроет; оператор получает уведомление на разбор.

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

3. Git как слой хранения

Каждая роль пишет свой вывод в ветку, привязанную к процессу:

1
2
3
4
5
6
7
8

forge/workflow/{workflowId}/run/{runId}
├── .workflow/spec.json          ← спецификация процесса (самоописательная)
├── .workflow/brief.md           ← исходный бриф на естественном языке
├── .agents/alex/handoff.json   ← структурированный вывод Алекса
├── .agents/alex/handoff.md     ← свободный вывод Алекса
├── .agents/sam/handoff.json   ← сводка ресёрча Сэма
├── .agents/sam/handoff.md
└── .agents/<остальные роли>/...

Два режима:

• Подключённый репозиторий — процесс коммитит в репозиторий клиента. Клиент может в любой момент сделать git fetch ветки и всё изучить. PR по завершающей передаче — по желанию.
• Общий репозиторий — связи нет; Forge держит скрытый репозиторий на организацию (forge-shared-workflows-{orgId}). Оператор смотрит передачи через интерфейс. Переезд в репозиторий клиента — в одно нажатие.

В обоих случаях ветка и есть журнал аудита. Комплаенс-аудитору достаточно выдать git log.

Чем это не является

Forge относится к категории общего агентного инструментария. Мы прямо говорим, чем не являемся:

• Не персональный ИИ-ассистент. С Forge можно общаться из Telegram — ставить задачи, задавать вопросы и даже менять конфигурацию, и он помнит переписку. Но отвечает он как команда вашей организации, а не как ваш личный ассистент: доступны ему процессы и персонажи вашей организации, в заданных границах и с аудитом.
• Не no-code конструктор приложений — Lovable, Bolt, v0 собирают приложения для конечных клиентов. Мы собираем процессы для команд.
• Не интеграционная iPaaS — Zapier, n8n, make.com идут от интеграций. Мы идём от процессов.
• Не набор библиотек для агентов — LangGraph, AutoGPT, CrewAI — библиотеки, которые инженеры связывают сами. Мы — управляемый продукт, который настраивает и неинженер.
• Не копилот в IDE — Cursor, Copilot помогают инженерам, которые уже есть. Мы убираем необходимость в инженерах в конкретных командных процессах.

Сравнение с альтернативами

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

Продуктовый путь намеренно короткий — без JSON, терминала и скриптов:

1. Откройте «Новый процесс» в панели Forge.
2. Опишите, что нужно, обычными словами. Forge понимает любой язык.
3. Нажмите «Собрать процесс». Forge сопоставит именованные роли из брифа с персонажами вашего состава. Для роли без подходящего персонажа Forge сгенерирует его на месте — с учётом подсказки роли, ваших прошлых процессов и брифа. Проверьте черновик, поправьте, примите.
4. Появится визуальная схема: персонажи карточками с аватарами, переходы стрелками, управляющий агент подсвечен. Нажмите на узел, чтобы изменить, перетащите, чтобы переставить, замените персонажа одним нажатием.
5. Запустите сейчас или поставьте на расписание по cron (каждый понедельник в 9 утра, в конце спринта, по срабатыванию webhook). Остальное сделает Forge.

Другие входы

• Метка forge-pipeline на задаче GitHub — точка входа в разработку. Пресет из пяти ролей запускается сам и выпускает отревьюенный PR. (Страница конвейера разработки. )
• API процессов — для CI-скриптов и интеграций: POST /api/v1/workflows/from-brief принимает тот же бриф программно.
• Входящий webhook — готовые интеграции для упоминаний в Slack, событий GitHub и внешних инструментов, которые должны запускать процесс.

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