오케스트레이터: 프로세스보다 의도가 중요해야 하는 이유

현재 에이전트 스택은 뒤집혀 있습니다. 표면(터미널, 편집기)이 모델, 도구, 기록을 소유하고, 정체성은 일시적입니다. 새 터미널을 열면 에이전트가 사라집니다. 저자는 의도를 단일 프로세스에서 분리하는 오케스트레이터 계층을 제안합니다. 주요 속성:

• 세션 위의 정체성: 논리적 에이전트가 프로세스 전반에 걸쳐 지속됩니다. 세션은 오고 가지만 에이전트는 유지됩니다.
• 표면 간 라우팅: 에이전트가 작업을 다른 머신(예: 리포지토리 박스, GPU 박스, 휴대폰)에 분배하며, 이를 서로 관련 없는 것으로 취급하지 않습니다.
• 진정한 핸드오프 프리미티브: 수행된 작업, 미완료 작업, 차단된 결정 등을 담은 타입화된 객체로, 손실이 많은 채팅 기록이 아닙니다.
• 하위 에이전트가 아닌 동료 에이전트: 서로 다른 컨텍스트의 두 에이전트가 어느 쪽도 소유하지 않은 제어 평면을 통해 조정합니다.
• 크로스 드라이버 호출: "저렴한 모델이 요약하고, 비싼 모델이 실행"하는 것은 프롬프트 엔지니어링이 아닌 프리미티브입니다. 오케스트레이터는 비용, 지연 시간, 기능에 따라 단계별 런타임을 선택합니다.
• 지속되는 승인 표면: 에이전트가 승인을 위해 일시 중지되고 당신이 세 시간대 떨어져 있어도, 승인 요청이 당신에게 전달되며 에이전트를 계속 활성화할 필요가 없습니다.

구체적 예: 불안정한 테스트 분류

오늘날 세 개의 터미널을 열고 Claude, Gemini, Grok 사이에 스택 트레이스를 붙여넣습니다. 저자가 원하는 흐름은 하나의 오케스트레이터 의도 아래: "이 플레이크를 분류하고, 수정안을 제안하며, 리뷰를 받는다."

• Ollama (로컬): 테스트 로그를 분석하고, 노이즈를 제거하며, 구조화된 실패 요약을 생성합니다. 무료이며, 머신을 떠나지 않습니다.
• Gemini CLI: 요약과 리포지토리를 가져와 의심스러운 변경 사항을 식별하고 패치 초안을 작성합니다. 큰 컨텍스트, 코드 읽기에 강하며, 읽기 전용 리포지토리 접근 권한을 가집니다.
• Grok Build: 패치와 원본 실패를 받아 평결(배송/수정/에스컬레이션)을 렌더링합니다. 다른 모델 제품군이 두 번째 의견을 제공합니다. 쓰기 권한은 없습니다.

세 개의 런타임, 세 개의 권한 범위, 세 개의 비용 계층, 하나의 의도. 오케스트레이터는 단계 간에 핸드오프 객체를 전달하고 세 개의 분리된 대화 대신 하나의 승인을 표시합니다. Grok이 "에스컬레이션"이라고 말하면, 의도는 일시 중지되고 인간의 결정을 기다리며, Ollama나 Gemini를 계속 활성화할 필요가 없습니다.

지난 주 기준으로, 적어도 세 개의 터미널 네이티브 코딩 에이전트가 로컬에서 실행됩니다: Ollama 런타임, Google의 Gemini CLI, xAI의 Grok Build(계획 모드 및 병렬 하위 에이전트 포함). 모델은 저렴하고 교체 가능한 부분입니다. 오케스트레이터는 지루하고 내구성 있는 부분이어야 합니다.