AI 에이전트는 승인되어도 여전히 미확인(unknown) 결과를 남길 수 있습니다.

승인(approval)은 에이전트가 특정 작업을 시도할 수 있는지 여부를 알려줄 뿐입니다. 이것이 원격 서비스가 실제로 그 작업을 완료했는지에 대한 정보는 제공하지 않습니다.

이러한 차이는 Agent Work Layer의 개발자인 Murthy G와의 공개 토론에서 구체화되었습니다. AWL은 관리자가 작업을 승인할 때까지 선택된 도구 호출(tool calls) 단계를 거칩니다. 저는 서비스가 호출을 받았지만, 게이트웨이(gateway)가 답변을 기록하기 전에 다운되는 경우에 무슨 일이 발생하는지 질문했습니다.

유용한 결과는 우리가 검사하고 재실행할 수 있는 변경 사항이었습니다.

불확실한 구간 (The uncertain interval)

승인된 작업 하나를 가정해 봅시다:

1. 게이트웨이가 작업을 시작한다고 기록합니다.
2. 수신자(receiver)가 효과(effect)를 수행합니다.
3. 수신자가 결과를 반환합니다.
4. 게이트웨이가 그 결과를 기록합니다.

2단계 이후 결과가 누락되었다고 해서 아무 일도 일어나지 않았음을 의미하지는 않습니다. 다시 보내면 효과가 중복될 수 있습니다. 만약 게이트웨이가 실제로 2단계 이전에 멈췄다면, 다시 보내기를 거부하는 것은 작업을 미완성 상태로 남길 수 있습니다.

Murthy는 최대 한 번만 실행되는 동작(at-most-once behavior)을 명확히 했고, 이에 따라 agent-work-layer-mcp 0.8.1 버전의 PR #43에서 답변이 없거나 중단된 효과를 unknown으로 변경했습니다. 게이트웨이는 이러한 불확실성을 유지하며 작업을 자동으로 다시 보내는 것을 방지합니다. 호출에는 또한 awl/ref 및 awl/order 메타데이터가 포함됩니다. 실제 수신자는 여전히 해당 식별자(identifier)에 대한 자체 검증된 처리가 필요하며, 메타데이터만으로는 중복 제거(deduplication)를 보장할 수 없습니다.

재현 과정에서 실제로 보여준 것 (What the reproduction actually showed)

2026년 10월 27일, 유지 관리자 측의 재현 검사는 Linux x86_64 환경과 Node v24.22.1을 사용하여 PR #43의 정확한 HEAD인 493157aee3391ec89fe1ffd301a402ae6e61861c를 체크아웃했습니다. 이 명령어들은 리포지토리 루트에서 실행되었습니다:

npm ci --ignore-scripts --no-audit --no-fund
npm run build -w agent-work-layer
node --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts

포커스 스위트(focused suite)는 약 21.95초 만에 42개의 테스트 통과, 실패 0개, 건너뛴 테스트 0개로 종료되었으며, exit 0을 반환했습니다. 이는 게시된 npm 아티팩트가 아닌 소스 체크아웃을 테스트한 것입니다. [public results reply]에는 환경 및 제한 사항이 기록되어 있습니다.

[CLI 테스트]는 stdio를 통해 별도의 로컬 MCP 리시버(receiver)를 사용합니다. 이 리시버는 게이트웨이 로그와 분리된 자체 전송 파일(delivery file)을 작성합니다. 통과한 어설션(assertions)은 다음 사항들을 다룹니다:

녹색 결과와 동등하게 언급해야 할 두 가지 제한 사항이 있습니다.

첫째, 종료된 프로세스로부터의 복구에는 수동 잠금 제거(manual lock removal)가 포함됩니다. [Issue #44]에서는 이 오래된 잠금(stale-lock) 문제를 추적했습니다. AWL 0.9.0 ([PR #48])은 이 재현 이후 병합되었으며, 동일한 장치에서 나중에 실행된 작업이 프로세스가 사라진 잠금을 가져가는 현상을 보고합니다. 저는 해당 버전을 다시 실행하지 않았으므로, 이번 실행만으로는 자동 충돌 복구(automatic crash recovery)가 확립되지 않습니다.

둘째, 전송 전/후 모호성(before/after-send ambiguity)을 나타내는 [gateway 테스트]는 running 로그 항목을 주입합니다. 이는 디스패치 직전에 실제 게이트웨이를 종료시키지 않습니다. 별도의 리시버는 가짜 로컬 서비스이며, Gmail 전송, 프로덕션 아이뎀포턴시(idempotency), 또는 정전 시 내구성(power-loss durability)은 테스트되지 않았습니다.

결과 확정 및 재시도 허용 (Settling an outcome and permitting another attempt)

[Issue #45]에서는 리시버를 확인한 후 누군가가 미확인(unknown) 효과를 확정하도록 하는 것을 제안했습니다.

이는 별도로 기록할 가치가 있는 두 가지 결정을 도입합니다:

• 사용 가능한 증거는 이전 작업에 대해 무엇을 확립합니까?
• 현재 권한 하에서 또 다른 시도가 발생할 수 있습니까?

Murthy는 이후 해당 제안을 개선했습니다: 정산 기록(settlement records)이 증거를 처리하고, 별도의 재시도 단계(retry step)가 권한을 다시 확인하며 시도 전반에 걸쳐 작업 식별자(operation identity)를 유지합니다. 누가 정산할 수 있고 누가 재시도할 수 있는지는 해당 댓글에서 열린 질문으로 남아 있었습니다.

같은 PR #48은 이후 구현을 배포했습니다. 설명에 따르면, 워커(worker)는 필수 노트와 함께 unknown 효과를 ok 또는 not_run으로 정산하며, 정산만으로는 아무것도 실행되지 않습니다. 매니저(manager)만이 재시도를 허용합니다. --retry는 승인 및 스테이징된 호출을 다시 확인한 다음, awl/try: 2를 포함하여 동일한 awl/ref를 전송합니다. 저는 해당 설명만 읽었으며, 위의 재현(reproduction)은 정산 또는 재시도 구현을 검증하지 못합니다.

부재하는 수신자 기록(receiver record)은 불완전한 증거일 수 있습니다. 이전 승인 역시 현재 보류 중인 것과 다른 수신자, 페이로드(payload), 또는 요청 인스턴스(request instance)를 설명할 수 있습니다. 재시도는 현재 권한 및 논리적 작업 식별자에 대한 의도적인 정책을 필요로 합니다. 이들은 재실행에 의해 확립된 기능이 아니라 새 릴리스의 승인 질문으로 남아 있습니다.

별도의 trollshell 토론은 요청 인스턴스 경계(request-instance boundary)를 특히 명확하게 했습니다: 승인 클릭을 마지막으로 폴링된 UI 스냅샷과 비교하는 것은 나중에 서버 측 경쟁 조건(server-side race)을 남깁니다. 작성자는 기존의 UI 보호와 제안된 서버 측 compare-and-set을 구별합니다. 우리의 소스 기반 응답은 상위 작업의 비활성 범위(dormant scope)를 온전하게 유지합니다. 해당 검토에서는 GTK 또는 hive 런타임 테스트가 실행되지 않았습니다.

런타임 간격이 보이는 열여덟 개의 실행 가능한 계산

저는 오프라인 선언 검사기인 Agent Role Contracts를 유지하고 있습니다. 이 논의는 #71 및 #69에서 추적된 경계가 있는 픽스처 패키지(bounded fixture pack)에 대한 것입니다. 픽스처, 러너 및 원시 결과는 공개되어 있으며, README에 재현 명령어(reproduction commands)가 포함되어 있습니다.

이 패키지는 18가지의 오프라인 사례를 다음 세 가지로 그룹화합니다:

• 6가지 권한 비교: 초과 권한 매핑(mapped excess authority), 누락된 인벤토리(missing inventory), 오래되거나 외부 신원(stale or foreign identity), 미매핑 도구(unmapped tools) 및 복구된 공급 스냅샷(repaired supplied snapshot).
• 6가지 승인 바인딩 사례: 변경된 페이로드, 대상 또는 정책; 인증 발급자/현재 범위 증거 누락; 오래된 결정 대 명시적으로 제공된 새로운 가상 결정.
• 6가지 증거 워크시트: 개별적인 전송/수신/응답 기록(distinct dispatch/receiver/response records), 전송 전 실패(pre-dispatch failure), 응답 손실(lost response), 취소(cancellation), 누락된 영구 증거(missing durable evidence) 및 충돌하거나 재전송된 기록.

러너는 기존의 G0/G1/G3 API를 사용하며 해결된 입력값과 원시 결과를 보존합니다. 로컬 실행에서 18가지 예상 계산 모두가 일치했습니다. 출력은 또한 실행되지 않은 런타임 사례(zero runtime cases executed), 권한 UNKNOWN 및 런타임 NOT_RUN을 기록합니다. 생명주기 선언(lifecycle declaration)이 일관적일 수 있지만, 별도로 제공된 추적(supplied trace)은 해결되지 않은 상태로 남아 있을 수 있습니다. 변경되지 않은 선언을 해싱하는 것만으로는 숨겨진 수신자 해결책을 발견할 수 없습니다.

권한 비교기는 동등하게 정보가 풍부하고 모델링된 네이티브 스타일의 술어(native-style predicate)와 일치합니다. 이 중첩은 중요합니다: 픽스처 패키지는 반복 가능한 워크시트를 제공하지만, 실제 호스트의 완전한 제어 및 인간 유지보수 비용에 대한 점진적 가치는 여전히 측정되지 않습니다. 6가지 증거 워크시트는 AWL에서 실행된 수신자 테스트와는 별개의 합성 입력값입니다.

보존해야 할 증거(The evidence to keep)

불확실한 작업을 위해, 유용한 기록은 검토된 정확한 대상(reviewed subject), 논리적 연산자 식별자(logical operation identity), 개별 시도, 현재 승인 결정, 발송 관찰, 수신 관찰 및 응답을 분리하여 유지합니다. 또한 이 기록들이 누가 제공했는지, 무엇이 실제로 검증되었는지, 그리고 무엇이 관찰되지 않았는지를 명시합니다.

이러한 분리는 운영자가 녹색 선언 확인(green declaration check)을 전달 주장(claim of delivery)으로 변환시키지 않으면서 불확실성을 보존할 수 있게 합니다. 이 상호작용에서, 구체적인 테스트 제안은 검사 가능한 외부 변경 사항과 제한된 재현(bounded reproduction)을 초래했습니다. 남아 있는 복구(recovery) 및 조정(reconciliation)에 대한 질문들은 그 옆에서도 보이도록 유지됩니다.