에이전트는 괜찮다. 문제는 그들 간의 인계(Handoff)이다.

AI 에이전트를 평가하는 모든 가이드들은 조용히 단 하나의 에이전트가 존재한다고 가정합니다. 모델 하나, 루프 하나, 점수를 매길 수 있는 출력 하나만 있다고 생각하죠. 그래서 깨끗한 eval harness를 구축하고, 루프를 추적하며, 합격률에 따라 게이트(gate)를 설정하면 기분이 좋습니다.

그런데 시스템이 성장합니다. 라우터 에이전트가 어떤 전문가에게 전화를 걸지 결정합니다. 리서처 에이전트가 초안을 라이터 에이전트에게 넘깁니다. 플래너가 세 명의 워커를 생성하고 그들의 결과를 병합합니다. 이제 당신은 단일 에이전트를 가진 것이 아닙니다. 당신은 에이전트들의 조직도(org chart)를 가지고 있으며, 문제가 생기는 지점은 거의 항상 그들 중 어느 한 곳 '안'에 있지 않습니다. 그것은 바로 **인계(handoff)**입니다. 즉, 한 에이전트의 출력이 다른 에이전트의 입력이 되는 이음매 부분이죠.

이것은 아무도 자신의 평가 스위트에 넣지 않는 실패 유형입니다. 왜냐하면 이것은 단일한 에이전트 안에 존재하지 않기 때문입니다. 저는 다중 에이전트 시스템이 다른 형태의 평가와 관찰 가능성(observability)을 필요로 하며, 만약 단일 에이전트용 도구들을 그대로 붙인다면 눈가리개를 하고 출시하게 될 것이라고 주장하고 싶습니다.

이음매 부분에 시신들이 묻혀있다

여기에 구체적인 사례가 있습니다. 지원 파이프라인입니다. triage 에이전트가 수신된 티켓을 분류한 다음, billing 에이전트 또는 technical 에이전트로 라우팅합니다. 각 에이전트는 고립 상태에서 훌륭했습니다. Triage는 분류 평가에서 0.94점을 받았습니다. Billing은 해결 품질에서 0.91점을 받았고, Technical은 0.89점을 받았습니다.

하지만 파이프라인 전체는 재앙이었습니다. 환불 요청들이 technical 에이전트로 들어갔는데, 이 에이전트는 청구(billing) 문제에 대해 즐겁게 트러블슈팅 계획을 지어냈습니다. 모든 구성 요소가 자체 평가를 통과했습니다. 그럼에도 불구하고 시스템은 실패했습니다.

왜일까요? Triage는 `{

해결책은 모든 인계(handoff)를 검증(assert)해야 할 일급 객체(first-class thing)로 취급하는 것입니다. 두 가지 계층이 있습니다:

1. 구조적 계약 (Structural contract) — 결정론적(deterministic)입니다. 생성 에이전트(producing agent)의 출력이 소비 에이전트(consuming agent)가 기대하는 스키마(schema) 및 기대 값 도메인(expected value domain)과 일치해야 합니다. 이는 비용이 저렴하고 빠르며, 어휘 드리프트(vocabulary-drift) 유형의 버그를 완전히 잡아냅니다.
2. 의미론적 인계 품질 (Semantic handoff quality) — 모델이 판단합니다. 상류(upstream) 에이전트가 생성한 내용을 바탕으로, 하류(downstream) 에이전트가 자신의 업무를 수행하기에 충분한 컨텍스트(context)를 전달받았는지 확인합니다. 작성(writer) 에이전트가 연구(researcher) 에이전트가 실제로 찾아낸 사실을 받았습니까, 아니면 손실이 있는 요약본을 받았습니까?

구조적 계층은 대부분의 보호를 제공하는 곳이며, 전체 스택에서 가장 비용이 저렴한 부분입니다. 다음은 제가 모든 에이전트 쌍 사이에 배치하는 계약 확인(contract check)의 예시입니다:

import { z } from "zod";

// 계약은 생성자(producer)와 소비자(consumer)가 공동으로 소유합니다.
...

이를 단순히 실시간(live) 상황뿐만 아니라, 기록된 운영 인계(production handoffs) 데이터에 대해 평가(eval)로 실행하십시오. 만약 triage가 라우터(router)가 들어본 적 없는 카테고리를 내보내기 시작한다면, 이는 새벽 2시에 호출(page)이 발생하기

전의 실패한 테스트입니다. 이것이 바로 단일 에이전트에게 효과적인 '결정론 우선, 판단 후순위(deterministic-first, judge-second)' 계층화 방식이며, 여러분은 이를 노드(node) 대신 그래프의 엣지(edge)에 적용하고 있는 것뿐입니다.

하지만 팀들이 실수하는 부분이 있습니다. 계약 평가(contract eval)가 통과(green)되었다는 것은 연결 부위(seam)가 올바르게 '타입(typed)'되었다는 것을 알려줄 뿐입니다. 그 연결 부위가 '좋다(good)'는 것을 알려주지는 않습니다. 이를 위해서는 실제로 무엇이 흘러갔는지를 확인해야 합니다.

볼 수 없는 연결 부위는 디버깅할 수 없다

인계 평가(handoff eval)가 실패(red)했을 때, 점수 자체는 무용지물입니다. "인계 품질 0.6"이라는 수치는 실행 가능한 정보를 전혀 주지 못합니다. 여러분은 다음 질문에 답해야 합니다: 에이전트 A가 실제로 무엇을 내보냈는가, 라우터가 이를 망가뜨린 후 에이전트 B가 실제로 무엇을 받았는가, 그리고 그 사이의 어떤 도구 호출(tool call)에서 필드(field)가 누락되었는가?

이것이 바로 중요한 분기점이며, 제가 agent-eval과 AgentLens를 두 개의 도구가 아닌 하나의 워크플로우(workflow)로 실행하는 이유입니다. agent-eval은 _판단(judgment)_을 담당합니다. 에이전트의 출력을 점수화하고, 구조적 계약(structural contract) 체크를 실행하며, 카테고리 어휘가 변할 때 표류(drift)를 감지하고, 기술 에이전트가 환불 정책을 임의로 만들어낼 때 근거 없는 주장(ungrounded claim)을 잡아냅니다. 즉, 합격 또는 불합격을 결정하고 릴리스(release)를 제어하는 계층입니다.

AgentLens는 _트레이스(trace)_를 담당합니다. 파이프라인 내의 모든 에이전트에 걸쳐 모든 모델 호출(model call)과 모든 도구 단계(tool step)를 하나의 연결된 실행으로 캡처합니다. 즉, 각 에이전트가 실제로 본 해결된 입력값(resolved inputs), 각 에이전트가 실제로 생성한 원시 출력값(raw outputs), 그리고 각 경계(seam)를 통과한 정확한 페이로드(payload)를 기록합니다. 따라서 agent-eval이 "triage->billing 인계 점수 0.6"이라고 말할 때, AgentLens를 사용하면 해당 특정 실행을 클릭하여 라우터 경계에서 refund_issue가 어떻게 조용히 null로 강제 변환(coerced)되었는지 확인할 수 있습니다. 평가는 신호(signal)를 제공하고, 트레이스는 그 신호를 디버깅 가능하게 만듭니다. 하나 없이는 실행할 수 없는 숫자이거나, 채점할 수 없는 소방 호스(firehose)와 같습니다.

단일 에이전트 환경에서는 때때로 로그를 눈으로 훑어보는 것만으로도 해결될 수 있습니다. 하지만 멀티 에이전트 환경에서 트레이스는 곧 _그래프(graph)_이며, 이를 수동으로 재구성할 수는 없습니다. 평가는 경계(seam)에 문제가 있다고 알려주지만, 트레이스는 어느 경계에서 왜 문제가 발생했는지 알려주는 유일한 수단입니다.

루프(loops)가 아닌 그래프를 위한 점수 모델

구체적으로, "시스템"에 대한 단일 통과율(pass rate)을 보고하는 것을 중단하십시오. 대신 다음과 같은 매트릭스(matrix)를 보고하십시오:

• 노드 점수 (Node scores) — 현재 수행하는 방식과 같이, 각 에이전트를 개별적으로 측정합니다.
• 엣지 점수 (Edge scores) — 각 인계(handoff): 구조적 계약 통과율 + 의미론적 품질(semantic quality).
• 경로 점수 (Path scores) — 실제 경로(triage->billing, triage->technical)에 대한 엔드 투 엔드(end-to-end) 측정. 왜냐하면 에이전트가 국소적으로는 옳더라도 전체적으로는 무용지물일 수 있기 때문입니다.

에지(edge)와 경로(path) 점수가 새로운 정보입니다. 이곳은 또한 회귀(regression)가 숨어드는 지점이기도 합니다. 왜냐하면 한 에이전트에 대한 프롬프트 변경이 해당 에이전트의 노드 평가(node eval)는 통과할 수 있지만, 그 하류(downstream)에 있는 이웃 에이전트가 의존하는 계약(contract)을 조용히 깨뜨릴 수 있기 때문입니다. 에지에서 이를 포착한 다음, AgentLens 트레이스(trace)로 이동하여 변경된 필드를 확인하십시오.

핵심 요약 (The takeaway)

단일 에이전트 평가(Single-agent evals)는 충분히 해결된 문제입니다. 하지만 멀티 에이전트 시스템(Multi-agent systems)은 그렇지 않습니다. 실패의 단위가 에이전트에서 에이전트 사이의 이음새(seam)로 이동하는데, 이 이음새를 평가하는 사람은 거의 없기 때문입니다. 모든 인계(handoff) 시점에 계약을 결정론적(deterministically)으로 단언(assert)하고, 시스템을 노드(node)/에지(edge)/경로(path) 레이어를 가진 그래프로 점수화하며, 평가 신호를 이를 생성한 트레이스(trace)에 밀착시켜 유지하십시오. 즉, 이음새를 등급 매기기 위한 에이전트 평가(agent-eval)와, 무엇이 이를 망가뜨렸는지 보여주는 AgentLens를 활용하십시오. 당신의 에이전트는 결코 문제가 아니었습니다. 문제는 핸드셰이크(handshake)였습니다.