Сначала решите workflow одним agent. Измерьте quality, latency, cost и failure modes. Multi-agent имеет смысл, если single agent упирается в context, parallelism, specialization или permission separation.
Research → summarize → format не требует трёх agents, если шаги простые и зависимые. Используйте deterministic code и обычные functions для predictable transformations.
Главный agent формулирует sub-tasks, выбирает specialists, собирает results и решает, завершён ли workflow. Specialist имеет узкий context, tools и output contract.
Review разных documents, independent market scans, несколько candidate analyses. Зависимые steps должны оставаться sequential, иначе agents работают на устаревшем state.
Каждый subagent получает task, inputs, constraints, expected schema и completion criteria. Свободный текст между agents увеличивает ambiguity.
Не позволяйте всем agents хаотично редактировать один документ или CRM object. Используйте orchestrator-controlled state, versioning и conflict resolution.
Research agents могут иметь broad read access, action agents — narrow write permissions. Это уменьшает blast radius и упрощает security review.
Каждый agent получает только tools, необходимые его job. Multi-agent система с одинаковыми admin permissions у всех компонентов теряет смысл разделения.
Orchestrator не должен «проголосовать» сам за high-risk action. Payment, deletion, large spend, customer-impacting changes требуют human approval независимо от числа agents.
Max retries, backoff, alternative tool, escalate. Бесконечный retry создаёт cost и потенциально повторяет опасное действие.
Каждое external action должно иметь request ID/idempotency key, где возможно. Если orchestrator повторит step после timeout, действие не должно дублироваться.
Если три subagents завершились, а один blocked, orchestrator должен решить: продолжить с caveat, retry, заменить agent или передать человеку. Не скрывайте incomplete result.
Ограничьте runtime, tool calls и token/cost budget каждого subtask. Complex orchestration без лимитов может быть экономически непредсказуемой.
Filtering, sorting, deduplication, arithmetic и merging structured results часто лучше делать программно. Model оставляйте judgement и synthesis.
Parent run → subagent runs → tool calls → outputs → merge → action. Без distributed trace невозможно понять, где появилась ошибка.
Research specialist, classifier, action agent и orchestrator должны иметь свои evals. Общий end-to-end score не показывает, какой component деградировал.
Помимо component evals, нужны real workflows с expected outcome. Multi-agent system может иметь сильные parts и слабую orchestration.
Для важных research/decision задач второй agent может критически проверить evidence и assumptions. Но reviewer должен иметь independent instructions, иначе он просто подтверждает first answer.
Три одинаковых agents могут повторить одну ошибку. Diversity полезна только при разных methods/data или independent reasoning.
Передавайте subagent только нужную часть task и data. После завершения возвращайте compact structured result. Это снижает context pollution.
Изменение number of agents, routing rule или tool permissions — production change. Храните version и regression eval.
Multi-agent может повысить quality, но увеличить latency/cost. Сравнивайте с single-agent baseline на том же eval set.
Человек может быть explicit node: approval, expert judgement, exception resolution. Не считайте human step архитектурной неудачей.
Completion rate, fallback, retries, cost, latency, high-severity failures, manual interventions. Alert на recursion/loop и tool error spikes.
Маркетинговая команда строит monthly market review. Single agent не справляется с объёмом: нужно одновременно анализировать конкурентов, customer signals и performance data. Orchestrator делегирует три независимых research tasks, получает structured outputs и объединяет их. Financial recommendation остаётся human-approved. Latency падает, а quality сравнивается с single-agent baseline, чтобы оправдать дополнительную сложность.
Handoff передаёт владение task другому agent; subagent выполняет ограниченный кусок и возвращает result orchestratorу. Для customer workflow handoff может быть естественным, а для research decomposition удобнее subagents. Выбор зависит от ownership и shared state.
Fan-out запускает несколько независимых workers; fan-in объединяет результаты. Задайте максимум parallel workers, deduplication и merge rule. Unlimited fan-out быстро увеличивает cost и noise.
Agent A не должен бесконечно делегировать B, который снова делегирует A. Храните depth limit, task lineage и запрещайте повторную delegation того же unresolved task.
Orchestrator не должен просто выбирать самый уверенный ответ. Используйте evidence, deterministic checks или reviewer agent. При irreconcilable conflict возвращайте uncertainty человеку.
Если specialist возвращает JSON schema v2, orchestrator должен понимать version. Breaking change в output contract требует coordinated deployment и regression tests.
Сравните quality gain и latency reduction с additional token/tool cost, operational complexity и new failure modes. Если multi-agent улучшает score на 1%, но удваивает cost и incident surface, single-agent может быть рациональнее.
Сымитируйте timeout subagent, stale tool result, conflicting data, unavailable service и malformed output. Orchestrator должен сохранять controlled behavior и корректно эскалировать.