Очередь задач и orchestration

Почему одной задачи мало

Один агент на одной задаче — это только начало. Реальная работа живёт в backlog: там есть epic, зависимости, shared files, ownership, review gates и задачи, которые нельзя запускать одновременно.

Orchestration layer отвечает за практический вопрос: что можно отдать агентам сейчас, что должно ждать и где нужен человек.

Workflow или autonomous loop

Не каждая многошаговая задача требует автономного агента.

Подход	Когда использовать	Что контролирует команда
Deterministic workflow	Путь известен заранее: validate -> search -> approve -> execute -> confirm.	Порядок steps, required gates, rollback, compliance.
Autonomous loop	Количество steps заранее неизвестно: coding bugfix, research, debugging, exploratory refactor.	Stop conditions, budget, tools, checks, escalation.
Hybrid	Критичные gates фиксированы, а внутри отдельных steps нужен flexible search/execution.	Graph boundaries: где model решает, а где код.

Для ALGI это значит: «сформировать clinician summary» может быть autonomous coding task внутри sandbox, но «отправить summary врачу» должен идти через deterministic workflow с approval, audit и delivery confirmation.

Сначала нарисуйте task graph

Task graph должен явно показывать:

• epic;
• child tasks;
• dependencies;
• ready tasks;
• blocked tasks;
• shared files или ownership boundaries;
• safe parallelism;
• required review gates.

Пример: epic «ALGI pain diary»

Так выглядит декомпозиция по deliverable behavior (не по слоям кода) с явными зависимостями:

Первые две задачи этого графа — реальные task contracts lab-цепочки: algi-01-pain-diary.json (T1) и algi-02-clinician-report.json (T2). Обратите внимание на T4: задача blocked не из-за зависимости в коде, а из-за required review gate. Это нормальное состояние графа, а не сбой.

Когда задача попадает в ready queue

Задача ready, если:

• есть task contract;
• dependencies закрыты;
• context pack подготовлен;
• sandbox и permissions определены;
• testing plan есть и исполним;
• нет known blocker;
• blast radius понятен.

Когда можно запускать параллельно

Параллельный запуск безопасен, если задачи:

• не меняют одни и те же файлы;
• не требуют несовместимых migrations;
• имеют независимые tests;
• не конфликтуют за external state;
• имеют отдельные worktrees, branches или sandboxes.

Когда нужен multi-agent

Multi-agent полезен не потому, что «несколько моделей умнее одной». Он оправдан, когда второй agent приносит новую информацию или изоляцию:

• reviewer запускает tests или visual checks, которых author-agent не видел;
• search sub-agent обследует большой codebase и возвращает короткий finding;
• security agent смотрит только structured tool calls, а не persuasive prose из trajectory;
• parallel agents работают в отдельных worktrees над независимыми slices.

Если несколько agents просто спорят над одним и тем же текстом без новых signals, часто дешевле и надёжнее один хороший agent + external checks. Multi-agent без ownership, budgets и merge strategy быстро превращается в дорогую версию chaos.

На что не соглашаться

• Разбивать epic на задачи по слоям кода, а не по deliverable behavior.
• Запускать параллельно tasks с одним ownership surface.
• Не фиксировать dependencies.
• Не иметь blocked state.
• Путать scheduler, runner и agent backend.

Что сделать руками

Разбейте фичу ALGI или harness-фичу на epic + task graph. Успех выглядит так: зависимости явные, ready queue понятна, blocked state не считается ошибкой, parallelism не ломает качество.