ADR-0005: Niche Evaluation = DAG, не линейный pipeline
Status
proposed (будет accepted при старте реализации модуля)
Context
Niche Evaluation Pipeline (см. Niche-Evaluation-Module) объединяет 6 агентов (3 новых + 3 переиспользованных). Вопрос — какая топология оркестрации?
Варианты:
- Линейный pipeline: A → B → C → D → E → F
- DAG с параллелизмом где возможно
- Полностью параллельный fan-out + агрегация в конце
Текущая реализация AgentRunner поддерживает только parent-child с одним parent-ом, последовательное выполнение через child tasks. Fan-in (когда parent ждёт завершения N children) — заявлен в Orchestration-Model, но не реализован до Week 3.
Decision
Niche Evaluation — это DAG с тремя фазами:
- Phase 1 (параллельно): Scout + Researcher собирают market data.
- Phase 2 (параллельно, после Phase 1): FinancialModeler и GTMStrategist работают параллельно, используя выход Phase 1.
- Phase 3 (sequential, после Phase 2): RatingAgent агрегирует всё и выдаёт композитный score.
Это требует fan-out и fan-in, которые должны быть реализованы в Week 3 как часть orchestration v2.
Alternatives considered
Option A: Линейный pipeline
- Pros: Простейшая реализация, работает на текущей архитектуре.
- Cons: Duration ~2x больше (нет параллелизма), agents ждут друг друга без необходимости.
Option B: Полный параллельный fan-out
- Pros: Максимальная скорость.
- Cons: FinancialModeler и RatingAgent принципиально не могут работать без выхода Scout/Researcher. Нарушает data dependency.
Option C (chosen): 3-фазный DAG
- Pros: Правильный баланс — параллелим где можно, сохраняем зависимости где нужно.
- Cons: Требует fan-in реализации в orchestrator.
Consequences
Positive
- Duration примерно 40-50% от линейного pipeline.
- Clear data dependencies отражены в архитектуре.
- Паттерн переиспользуем для других будущих multi-agent workflows.
Negative / Trade-offs
- Нужен fan-in worker (поллит children status, триггерит parent когда все children done).
- Частичный failure: если один executor в Phase 1 failed — как вести себя? Требует explicit decision в логике директора.
- Usage sharding: сложнее считать общий cost одного evaluation когда вызовы параллельные.
Mitigations
- Реализовать fan-in в Week 3 как generic feature, не niche-specific.
- NicheEvaluationDirector имеет явную политику partial failure: если Scout failed — halt, если TrendAnalyst (future) failed — продолжаем.
- Добавить root_id aggregation в метрики для точного cost-tracking всего evaluation.
Follow-ups
- Week 3: реализовать fan-in в AgentRunner / отдельный BlockedTaskWorker.
- Week 3: generic DAG описание в task payload (list of phases + dependency map).
- Module M1: implement NicheEvaluationDirector поверх DAG infra.