멀티 에이전트 지원 흐름(multi-agent support flow)은 여전히 분산 시스템(distributed system)입니다. 구성 요소에 더 친근한 이름을 붙여 덜 무섭게 들리게 할 수는 있지만, 타임아웃(timeouts)과 중복 호출(duplicate calls)은 여전히 시스템의 일부로 남아 있으며, 실패한 핸드오프(handoff)를 누가 소유했는가에 대한 문제도 마찬가지입니다.

예를 들어, 분류 에이전트(triage agent)가 티켓을 읽고, 계정 에이전트(account agent)가 고객 컨텍스트(customer context)를 가져오며, 정책 에이전트(policy agent)가 권한(entitlements)을 확인하고, 액션 에이전트(action agent)가 주문 서비스(order service)를 호출한다고 가정해 봅시다. 정책 결정과 환불 API 사이의 어딘가에서 워커(worker)가 중단됩니다.

새벽 2시에 저는 몇 가지 사항에 신경을 씁니다. 어떤 단계가 완료되었는지, 환불을 안전하게 반복할 수 있는지, 실패한 핸드오프의 소유자가 누구인지, 운영자가 다음에 무엇을 할 수 있는지, 그리고 에이전트가 해당 호출을 수행할 권한이 있었는지 여부입니다.

Orkes Conductor의 운영 모델

Orkes Conductor는 JSON으로 저장된 워크플로우 정의(workflow definitions)를 통해 태스크(tasks)와 워커(workers)를 조정하며, 이러한 정의를 코드, API 또는 비주얼 빌더(visual builder)를 통해 작성할 수 있습니다. 문서는 정적 및 동적 워크플로우(static and dynamic workflows), 휴먼 태스크(human tasks), 이벤트 기반 흐름(event-driven flows), AI 태스크(AI tasks), 에이전틱 오케스트레이션(agentic orchestration) 및 MCP 노출(MCP exposure)을 다룹니다. Orkes는 또한 Conductor를 기존 에이전트와 워크플로우가 서로를 호출할 수 있는 플랫폼으로 포지셔닝합니다.

만약 귀하의 플랫폼이 이미 마이크로서비스 워커(microservice workers)와 명시적인 태스크 정의(explicit task definitions)를 중심으로 구성되어 있다면, 이 모델이 합리적입니다. 워크플로우는 가시적인 조정자(coordinator) 역할을 하고, 워커는 폴리글랏(polyglot) 상태를 유지할 수 있으며, 재시도(retries)와 상태(state)는 중앙에서 처리됩니다.

Catalyst의 운영 모델

Catalyst는 Dapr를 기반으로 구축되었으며 워크플로우, 에이전트, MCP 서버 및 서비스를 단일 실행 및 거버넌스 평면(execution and governance plane) 위의 워크로드(workloads)로 취급합니다. 에이전트는 이미 실행 중인 프레임워크 내에 머물 수 있는 반면, 내구성이 있는 러너(durable runners)는 추론(reasoning)과 도구 작업(tool operations)을 워크플로우 활동(workflow activities)으로 전환합니다. 앱 ID(App identities)와 정책(policies)은 어떤 워크로드가 다른 애플리케이션이나 MCP 서버를 호출할 수 있는지 제어합니다.

흥미로운 점은 다이어그램이 아닙니다. 단일 런타임 경계(runtime boundary) 내부에 무엇이 남게 되는가 하는 점입니다. 즉, 복구(recovery), 통신(communication), ID(identity), 정책(policy), 그리고 운영 검사(operational inspection)가 에이전트(agent) 구성 요소와 비에이전트(non-agent) 구성 요소 모두에서 동일한 방식으로 작동한다는 것입니다.

기능 목록이 아닌 실패 과정을 따라가 보십시오

두 플랫폼 모두에서 동일한 시나리오를 실행해 보십시오.

1. 분류(triage) 및 계정 조회(account lookup)를 완료합니다.
2. 정책 에이전트(policy agent)가 환불을 승인하도록 합니다.
3. 환불 호출(refund call) 중에 액션 워커(action worker)를 강제 종료합니다.
4. 서비스를 복구하고 무엇이 복구되는지 관찰합니다.
5. 실행 기록(execution record)과 권한 부여 경로(authorization path)를 검사합니다.

그런 다음 완료된 단계가 다시 재생(replay)되는지 아니면 재실행(re-execute)되는지, 환불 호출이 어떻게 멱등성(idempotent)을 유지하는지, 운영자가 실행을 어떻게 재시도하거나 종료하는지, 그리고 자격 증명(credentials)이 어떻게 범위(scoped)가 지정되는지 질문해 보십시오. "내구성이 있다(durable)"라고 말하는 제품 페이지는 이 질문들에 대해 어떤 답도 주지 못할 것입니다.

각각의 적합한 용도

워크플로우를 시각적으로 또는 JSON으로 관리하면서, Conductor의 태스크-및-워커(task-and-worker) 모델을 마이크로서비스(microservices), API, 사람, 그리고 AI 전반으로 확장하고 싶다면 Orkes가 강력한 후보입니다.

이미 Dapr 또는 여러 에이전트 프레임워크(agent frameworks)를 사용 중이며, 워크로드 ID(workload identity), 정책 제어 통신(policy-controlled communication), 내구 실행(durable execution), 그리고 배포 거버넌스(deployment governance)가 하나의 플랫폼에서 제공되기를 원한다면 Catalyst를 검토할 가치가 있습니다.

내장된 태스크의 개수를 보고 선택하지 마십시오. 실패 계약(failure contract)과 운영 계약(operating contract)을 보고 선택하십시오. 새벽 2시에 당신을 구해주는 것은 어떤 에이전트가 무엇을 했는지 추측하지 않고도 실행을 복구할 수 있는 온콜(on-call) 엔지니어이기 때문입니다.

공식 출처

• Diagrid Catalyst architecture
• Diagrid Catalyst agents
• Orkes workflow overview
• Orkes AI orchestration