Why We Killed Our Multi-Agent Pipeline — Subbiah Sethuraman and Abhilash Asokan, ZS Associates

한 줄 핵심

멀티 에이전트로 분석 업무를 쪼개면 겉보기엔 그럴듯해도 맥락 손실과 책임 분산 때문에 오히려 결론이 어긋나므로, 결정적 부분은 분리하고 하나의 에이전트가 끝까지 추론을 소유하게 재설계해야 한다.

시간별 요약

1. 0:01
   이 영상은 제약·헬스케어 상업 분석 업무를 에이전트로 모사하려다 실패한 경험을 바탕으로, 신호 감지-원인 규명-조치-전망의 흐름을 어떤 구조로 다시 짜야 하는지 설명한다. 특히 기존 분석가의 업무 절차를 그대로 에이전트 분업으로 옮겼을 때 생기는 문제를 실제 사례로 보여준다.
2. 3:00
   초기 멀티 에이전트 파이프라인은 신호, 원인, 조치, 전망을 각각 다른 에이전트가 맡았지만 결과물은 서로 맞물리지 않았다. 원인은 맞게 찾았는데 조치는 payer/insurance 맥락을 반영하지 못했고, 그 결과 전망까지 일관성을 잃으면서 단일한 책임 주체가 없는 구조의 한계가 드러났다.
3. 6:01
   해결의 첫 단계는 에이전트가 맡지 말아야 할 결정적 작업과 맡아야 할 탐색 작업을 분리하는 것이었다. 신호 감지는 통계적 방법과 threshold, guardrail이 있는 deterministic workflow로 옮기고, 에이전트는 큐에 올라온 signal을 조사하는 역할로 제한했다.
4. 8:01
   두 번째 단계는 분산된 추론을 줄이고 하나의 메인 에이전트가 reasoning을 끝까지 소유하도록 바꾸는 것이었다. 반복적인 함수 작성과 DB 조회는 공통 tool로 묶고, 매우 좁은 작업만 sub-agent에 위임하되 판단과 최종 결론은 메인 에이전트가 책임지게 했다.
5. 10:01
   세 번째 단계는 도메인 지식을 knowledge graph로 구조화해 에이전트의 탐색 범위를 통제하는 것이었다. graph는 단순 조회용 저장소가 아니라 어떤 경로를 조사할지, 어떤 가설을 검증할지 결정하는 control plane이 되었고, loop는 graph 탐색-데이터 검증-가설 갱신을 반복하며 root cause를 좁혀 가도록 설계됐다.

실무 인사이트

• 복잡한 분석 업무는 deterministic 부분과 agentic 부분을 먼저 나눠야 하며, 통계·룰 기반으로 충분한 단계는 에이전트에 맡기지 않는 것이 안정적이다.
• 멀티 에이전트의 가장 큰 실패 원인은 모델 성능보다 context handoff와 책임 분산이므로, 최종 판단을 소유하는 단일 에이전트를 두는 쪽이 실무적으로 유리하다.
• knowledge graph는 사실 조회용이 아니라 에이전트의 탐색 범위와 가설 경로를 제한하는 제어 장치로 써야 일관된 추론이 가능하다.