왜 우리가 라우팅 규칙이 아닌 오케스트레이터를 만들었는가
정적 트리거/트랜스폼 규칙은 캔버스가 몇 개 에이전트를 넘어가면 확장이 안 됩니다. MadoHub이 이제 실제 툴 호출 루프로 라우팅하는 이유 — 그리고 여전히 규칙을 써야 할 때.
MadoHub의 대부분 기간 동안, 에이전트 사이의 라우팅은 규칙 엔진이었습니다. 연결에는 트리거(on-idle, on-complete, on-keyword, always), 트랜스폼(AI routing, prompt-wrap, full-output, raw, summary), 그리고 루프 보호 노브가 있었습니다. 한 번 구성하면 매번 같이 발동합니다. 그 모델은 여전히 존재합니다 — Agent Routing과 Flows가 문서화하는 것이며, 동료 리뷰 같은 알려진 패턴을 위해 두 타일을 연결하는 가장 빠른 방법이기도 합니다. 하지만 구체적으로 짚을 가치가 있는 확장 문제가 있습니다.
문제는 어떤 단일 규칙이 아닙니다. 개수입니다.
"on idle → prompt-wrap" 연결은 추론하기 쉽습니다: source가 끝났는가? 그렇다면 전달합니다. 골칫거리는 캔버스가 몇 개 타일을 넘어가고 연결이 독립적이지 않을 때 시작됩니다.
다섯 에이전트와 여덟 연결이 있으면, 모든 규칙이 다른 모든 규칙과 상호작용합니다. A의 출력이 B의 on-keyword 트리거에 키워드 매칭으로 세나요? C가 같은 대상이 1초 안에 두 번 맞지 않도록 D의 쿨다운을 기다려야 하나요? 이들 중 어느 것도 틀린 답이 아닙니다 — 트리거 유형, 트랜스폼, 또는 우선순위 플래그를 하나 더 추가해 어느 하나를 해결할 수 있습니다. 하지만 각 답이 새 규칙이고, 규칙은 더해지지 않고 곱해집니다. N개 에이전트 토폴로지는 N개 규칙이 아니라 N²에 가까운 엣지 케이스 처리가 필요합니다, 왜냐하면 규칙은 캔버스의 다른 곳에서 무슨 일이 일어나는지에 대한 모델이 없기 때문입니다 — 출력 텍스트에 패턴 매칭하고 맹목적으로 발동합니다.
이것이 오케스트레이터를 위한 진짜 논증입니다: 규칙이 나쁘다가 아니라, 고정된 규칙은 무엇을 할지 결정하기 전에 워크스페이스의 나머지를 볼 수 없고, 두어 개 이상의 에이전트가 있는 워크스페이스는 점점 더 정확히 그것을 필요로 한다는 것입니다.
MadoHub이 다루는 방법
더 큰 규칙이 아닌 툴 루프
대안은 "AI 트랜스폼 추가"가 아닙니다 — MadoHub은 이미 그것을 가지고 있었습니다. 라우팅 결정이 워크스페이스에 접근하게 하는 것입니다. 기본적으로, 발동한 연결은 이제 MadoAgent 서브턴을 엽니다: 캔버스의 스냅샷 — 모든 타일, 모든 연결의 트리거와 트랜스폼과 라운드 상태, 최근 출력 — 을 보고 하나의 라우팅 결정을 내린 뒤 멈추는 실제 툴 호출 루프입니다.
그 결정은 의도적으로 좁습니다: 파일 읽기, git 상태 확인, 연결 나열, 라우팅 히스토리 검사, 세션 검색, 메모리 recall, 그리고 정확히 하나의 동작 — 메시지 전달 또는 건너뛰기 — 을 할 수 있습니다. 캔버스를 다시 쓰거나, 연결을 바꾸거나, 워크플로를 실행할 수는 없습니다. 지시는 단순합니다: 실질적 내용(계획, 코드, 리뷰)이 있을 때 전달하고, source 출력이 사용자에 대한 질문이거나 빈 잡담일 때 건너뜁니다. 패턴 매치가 아닌, 실제 대화에 대한 판단입니다.
경로에 상관없이 루프 보호는 여전히 적용
결정론적 디스패처를 모델 호출로 바꾸는 것은 첫날부터 온전히 자신 있게 할 수 있는 변경이 아니어서, 규칙 기반 시스템의 가드레일이 변경 없이 이어집니다. 루프 보호는 연결이 자동 비활성화되기 전에 도는 사이클 수(기본 5)를 제한하고, 트리거 사이의 최소 간격(기본 3초)을 강제하며, LGTM 같은 stop keyword가 나타나는 즉시 루프를 끝낼 수 있습니다. 매 라운드 전달하기로 결정한 서브턴이라도 폭주할 수 없습니다 — 한도와 쿨다운이 그 결정과 무관하게 강제됩니다.
신뢰를 쌓기 위한 섀도 모드
동작을 바꾸지 않고 새 경로를 시도하고 싶다면, 섀도 모드가 레거시 라우터를 라이브로 실행하고 그 결정이 전달되며 — 사용자 대면 동작은 바뀌지 않고 — 같은 트리거에서 MadoAgent 서브턴이 병렬로, 순전히 비교 신호로서 실행됩니다. 라이브 콜을 맡기기 전에 실제 트래픽에서 새 경로가 옛 것과 어디서 동의하는지 볼 수 있습니다. 레거시 경로는 그 신뢰가 쌓이는 동안 설정에서 선택 가능하게 남습니다.
실용적 안내
- 알려진 좋은 형태에는 Flow를 사용. 세 개의 빌트인(Peer review, Pipeline, Watcher)은 고정 규칙 세트로 남습니다, 반복 가능한 패턴을 위해 드롭된 템플릿이 매 발동마다 모델에 의해 재심사돼서는 안 되므로.
- 맞춤형이거나 큰 토폴로지에는 오케스트레이터를 사용. 고정 규칙 세트가 캔버스를 잘 기술하지 못할 때, 결정하기 전에 워크스페이스의 나머지를 볼 수 있는 툴 호출 루프가 또 다른 규칙보다 더 잘 일반화합니다.
- 일회성 정밀함에는 수동 연결. 두 타일 사이에 연결을 드래그하는 것은 여전히 단일 링크에 대한 완전한 통제를 원하고 템플릿이나 대화가 필요 없을 때 가장 빠른 경로입니다.
- 루프 보호 켜둬. 라우팅 루프의 LLM은 출력이 실질적인지 잘못 판단해 규칙이 전달했을 것을 건너뛰고, 템플릿 매치가 하지 않는 레이턴시와 토큰의 왕복을 추가할 수 있습니다. 루프 보호와 전달 게이트가 잘못된 결정이 무한 루프로 소용돌이치지 않게, 그리고 전달이 더 이상 받을 타일이 없어 조용히 삼켜지지 않게 보장합니다.