접근 권한은 주체성이 아닙니다

당신의 에이전트(Agent)는 Slack을 읽을 수 있습니다. 이메일을 검색할 수 있습니다. CRM을 조회하고, GitHub 이슈를 열고, 결제 내를 확인하며, 문서를 탐색하고, 스프레드시트를 편집하고, 고객 답장 초안을 작성하며, 세 개의 내부 API를 호출할 수 있습니다.

방 안의 모든 사람은 이것을 강력하다고 말합니다. 그것이 첫 번째 실수입니다.

질문은 에이전트가 무엇에 접근할 수 있느냐가 아닙니다. 질문은 에이전트가 무엇을 변경하도록 허용되었느냐입니다. 이메일을 직접 보낼 수 있습니까, 아니면 초안만 작성할 수 있습니까? 고객의 플랜을 업데이트할 수 있습니까, 아니면 업데이트를 제안만 할 수 있습니까? Pull Request(PR)를 머지(Merge)할 수 있습니까, 아니면 열기만 할 수 있습니까?

일단 에이전트가 도구(Tools)를 통해 행동할 수 있게 되면, 실제 시스템은 더 이상 모델(Model)이 아닙니다. 실제 시스템은 모델을 둘러싼 행동 계약(Action Contract)입니다.

접근(Access)은 도달 범위입니다. 주체성(Agency)은 제약 조건 아래 허용된 행동입니다.

더 많은 도구가 있다고 해서 에이전트가 자동으로 더 주체적이 되는 것은 아닙니다. 더 많은 도구는 판단(Judgment)을 설계해야 하는 표면을 확장할 뿐입니다. 커넥터(Connector)는 문입니다. 주체성은 누가 그 문을 통과할 수 있는지, 무엇을 들고 갈 수 있는지, 누가 가방을 검사하는지, 그리고 문제가 발생했을 때 누가 영상을 검토하는지에 관한 계약입니다.

현재의 에이전트 담론은 이 점을 놓치고 있습니다. 사람들은 마치 다음 도약이 커넥터인 것처럼 이야기합니다. 모델에게 Slack, Gmail, GitHub, Linear, Notion, Stripe를 주고 자율성(Autonomy)이 나타나기를 기다리는 식입니다. 하지만 커넥터는 의사결정권(Decision Right)이 아닙니다.

아무도 이름을 부르고 싶어 하지 않는 스택

에이전트가 진정한 주체성을 가졌는지 알고 싶다면, 모델 카드(Model Card)부터 시작하지 마십시오. 권리 스택(Rights Stack)부터 시작하십시오. 모든 에이전트 행동 시스템에는 다섯 가지 계층이 있습니다:

가시성 (Visibility) — 에이전트가 검사할 수 있는 데이터, 도구, 문서, 로그 및 시스템.

변이 (Mutation) — 에이전트가 변경할 수 있는 객체. 고객 기록을 읽는 것과 변경하는 것은 서로 다른 권한입니다. 답장 초안을 작성하는 것과 전송하는 것은 서로 다른 권한입니다.

증명 (Proof) — 변이가 실제로 적용되기 전에 에이전트가 생성해야 하는 것. 테스트 실행(Test run), 차이점(Diff), 추적(Trace), 정책 확인(Policy check), 사람의 승인(Human approval), 또는 증거 꾸러미(Evidence bundle).

에스컬레이션 (Escalation) — 에이전트가 동작을 멈추고 결정을 다른 사람에게 넘겨야 하는 상황입니다. 단순한 슬로건으로서의 "인간 참여형 (human in the loop)"이 아닙니다. 맥락 부족, 높은 가역 비용 (reversibility cost), 결제 이동, 권한 변경, 법적 노출과 같이 명시된 조건이 있을 때 발생합니다.

철회 (Revocation) — 에이전트가 실패한 후 무엇이 변하는가에 대한 문제입니다. 잘못된 판단 이후 인간은 신뢰를 잃습니다. 하지만 대부분의 에이전트는 아무것도 잃지 않습니다. 그들은 실패하고, 패치(patch)를 받은 뒤, 동일한 작업 표면 (action surface)을 가진 채 돌아옵니다. 그것은 위임 (delegation)이 아닙니다. 그것은 API 키를 가진 건망증 (amnesia)일 뿐입니다.

에이전트 작업 권한 테스트 (The Agent Action Rights Test)

현재 사용 중인 가장 강력한 에이전트를 대상으로 이 테스트를 실행해 보십시오. 장난감이 아니라, 당신이 가장 신뢰하고 싶은 바로 그 에이전트 말입니다.

에이전트가 무엇을 볼 수 있는가?
에이전트가 무엇을 변경할 수 있는가?
변경이 실제로 적용되기 전에 에이전트가 무엇을 증명해야 하는가?
무엇이 인간으로의 에스컬레이션 (escalation)을 유발하는가?
잘못된 실행 이후 어떤 권한이 사라지는가?

대부분의 팀은 첫 번째 질문에 답할 수 있습니다. 일부는 두 번째 질문에 답할 수 있습니다. 하지만 다섯 가지 질문 모두에 답할 수 있는 팀은 거의 없습니다.

이것이 진단입니다. 만약 "무엇을 볼 수 있는가?"에 답할 수 없다면, 당신은 인벤토리 (inventory)를 가지고 있지 않은 것입니다. 만약 "무엇을 변경할 수 있는가?"에 답할 수 없다면, 당신은 권한 모델 (permission model)을 가지고 있지 않은 것입니다. 만약 "무엇을 증명해야 하는가?"에 답할 수 없다면, 당신은 검증 (verification) 체계가 없는 것입니다. 만약 "무엇이 에스컬레이션을 유발하는가?"에 답할 수 없다면, 당신은 감독 (oversight) 체계가 없는 것입니다. 만약 "어떤 권한이 사라지는가?"에 답할 수 없다면, 당신은 권한 계층 (authority layer)에서의 학습 (learning) 체계가 없는 것입니다.

권한은 결과를 추적해야 합니다

훌륭한 작업 권한은 시스템 전체를 둘러싼 하나의 벽이 아닙니다. 그것은 경사면 (slope)이어야 합니다.

읽기 전용 Slack 검색은 비용이 저렴해야 합니다. 고객 답장 초안을 작성하는 것도 저렴해야 합니다. 로컬의 가역적인 수정 (reversible edits)은 외부의 불가역적인 약속 (irreversible commitments)보다 비용이 더 저렴해야 합니다. 이메일 발송, 송장 환불, 또는 풀 리퀘스트 (pull request) 병합은 더 강력한 게이트 (gates)를 통과해야 합니다.

목표는 모든 에이전트 (agent)를 양식 채우기용 인턴으로 만드는 것이 아닙니다. 목표는 권한 (authority)을 결과 (consequence)에 맞추는 것입니다. 그것이 훌륭한 인간 조직이 작동하는 방식입니다. 신입 사원은 시나리오를 모델링할 수 있습니다. 매니저는 소액의 예산을 승인할 수 있습니다. 디렉터는 인력 (headcount)을 재배치할 수 있습니다. 이사회는 인수를 승인합니다. 권한은 결과에 따라 변합니다. 에이전트에게도 동일한 경사도 (gradient)가 필요합니다.

병목 현상의 이동

이 지점에서 진지한 에이전트 시장이 갈라질 것입니다. 한쪽은 도달 범위 (reach)를 판매할 것입니다: 더 많은 커넥터 (connectors), 더 많은 메모리 (memory), 더 많은 도구 (tools), 더 많은 환경 (environments). 다른 한쪽은 에이전시 (agency)를 판매할 것입니다: 허가된 행동 (permissioned action), 제한된 자율성 (bounded autonomy), 확정 전 증명 (proof before commitment), 컨텍스트 (context)가 깨질 때의 에스컬레이션 (escalation), 그리고 신뢰를 잃었을 때의 권한 회수 (revocation).

도달 범위는 데모를 더 잘 보여줄 것입니다. 에이전시는 조직과의 접점에서 살아남을 것입니다.

도달 범위는 회의실 안에서 잘 보여집니다. 에이전시는 사고 검토 (incident review) 상황에서 견뎌냅니다.

다음 주가 되기 전에, 하나의 워크플로 (workflow)에 대해 에이전트 행동 권한 테스트 (Agent Action Rights Test)를 실행해 보세요. 전체 스택이 아닙니다. 하나의 에이전트, 하나의 워크플로면 됩니다. 다섯 가지 답변을 메모에 적으세요. 만약 다섯 번째 답변이 비어 있다면, 당신은 누락된 계층을 발견한 것입니다. 에이전트에게 필요한 것은 또 다른 도구가 아니었습니다. 그것은 틀릴 수 있는 권한을 더 작게 제한하는 것이었습니다.