자율 에이전트가 경제 행위자가 되고 있다.
법인도 아니고 회사도 아니고 인간도 아니다. 경제 행위자다.
이들은 데이터를 요청하고, API를 호출하고, 부분 작업을 조율하고, 결과물을 생성하고, 컴퓨팅 자원을 소비하고, 서비스를 판매하고, 소프트웨어 시스템 내에서 의사결정을 내린다. 오늘날 그들의 경제 활동 대부분은 인간 계정 뒤에 숨겨져 있다. 인간이 SaaS 청구서를 낸다. 인간이 카드를 보유한다. 인간이 사용 내역을 조정한다. 인간이 모든 실질적인 경제 약정에 서명한다.
이것은 확장되지 않을 것이다.
에이전트가 더 능력을 갖추게 되면서, 다른 에이전트, 서비스, 시장과 경제적으로 상호작용해야 할 것이다. 이들은 지출 한도를 필요로 할 것이다. 영수증을 필요로 할 것이다. 작업 검증, 조건부 결제, 신용을 필요로 할 것이다. 소프트웨어 속도로 작동하는 머니를 필요로 할 것이다.
이것이 에이전트 경제 테제다:
자율 에이전트는 단순한 결제 래퍼가 아니라 프로그래머블 머니를 필요로 한다.
다섯 가지 테제
1. 많은 자율 시스템이 결제를 하고 받을 필요가 있을 것이다
모든 챗봇이 지갑을 필요로 하는 것은 아니다. 하지만 유료 API를 호출하고, 컴퓨팅을 임차하고, 데이터를 구매하고, 작업을 아웃소싱하고, 결과물을 판매하거나 워크플로우를 조율하는 에이전트는 경제 능력이 필요하다. 에이전트가 결제할 수 없다면, 모든 워크플로우는 인간 운영자에게 폴백된다 — 그리고 인간 운영자는 모든 기계 작업의 병목이 된다.
2. 결제만으로는 충분하지 않다
결제 영수증은 가치가 이동했다는 것을 말해준다. 작업이 완료되었다는 것은 말해주지 않는다. 에이전트 경제는 작업 약정, 검증 영수증, 결제 영수증이 필요하다. 흥미로운 단위는 트랜잭션이 아니다. 그것은 계약이다.
3. 프로그래머블 수용은 누락된 원시 요소다
핵심 질문은 "에이전트가 돈을 보낼 수 있는가?"가 아니다. 그것은: 합의된 조건이 만족될 때에만 결제가 환매될 수 있는가? 이것이 전신 송금과 계약 간의 차이다. 에이전트 경제는 두 번째 것이 필요하다.
4. 에이전트는 무제한 지갑이 아니라 제한된 신용을 필요로 한다
안전한 에이전트는 제한 없는 자금을 보유해야 하지 않는다. 이것은 제한된, 만료되는, 목적 제한이 있는 수단을 받아야 한다. 금융사의 역사는 제한된 약정의 역사다. 에이전트도 제한된 약정이 필요하다.
5. 이기는 스택은 계층화될 것이다
어떤 단일 제품도 에이전트 경제 전체를 소유하지 못할 것이다. 인가, 결제, 작업 검증, 신용, 결제는 다른 계층에 살 것이다 — 그리고 이기는 시스템은 깔끔하게 구성되는 것들이 될 것이다.
에이전트가 머니에서 요구하는 것들
기계가 읽을 수 있는 약관
에이전트는 모호한 청구서를 협상할 수 없다. 이것은 구조화된 약관이 필요하다: 가격, 자산, 네트워크, 수취인, 기한, 환불 규칙, 검증자, 작업 정의. 그보다 덜한 것은 소프트웨어를 위해 차려입은 인간형 인공물이다.
저마찰 결제
에이전트는 분당 수백 개의 도구를 호출할 수 있다. 결제는 수동 체크아웃, CAPTCHA, 또는 6단계 OAuth 절차를 요구할 수 없다. 마찰은 자동화의 적이다.
결정론적 비용
에이전트는 트랜잭션을 제출하기 전에 그것이 가치 있는지 알아야 한다. 예측 불가능한 수수료와 가스 경매는 작은 자율 결제를 계획하기 어렵고 예산 수립을 불가능하게 만든다.
제한된 지출
에이전트는 한도를 가져야 한다 — 작업당, 상대방당, 일당, 자산당, 위험 카테고리당. 올바른 기본값은 여전히 작업을 완료할 수 있는 가장 작은 권한이다.
작업 검증
시스템은 무엇이 허용 가능한 작업으로 간주되는지를 정의해야 한다. 이것은 객관적 결과물, 서명된 검증자 영수증, 암호 증명, 해시 커밋먼트, 또는 인간이 검토한 결정일 수 있다. 검증 규칙 없이는 결제는 팁이 된다.
결제 영수증
다운스트림 시스템은 무엇이 결제되었는지 알아야 한다. 영수증은 서류 작업이 아니다 — 이것은 회계, 분쟁 처리, 감사, 평판의 기반이다. 좋은 영수증이 없는 머니 시스템은 성장할 수 없다.
인간 결제 레일이 충분하지 않은 이유
전통적인 결제 시스템은 지속적인 정체성을 위해 설계되었다: 사람, 기업, 은행 계좌, 카드, 가맹점 계좌, 차백, 법적 소추. 이것은 인간 상거래에 적절하다.
에이전트는 다르다. 이들은 일시적인 프로세스일 수 있다. 이들은 위임된 권한 하에서 행동할 수 있다. 단일 API 호출에 대해 비용을 지불해야 할 수 있다. 상대방이 등록된 가맹점이 아닌 다른 에이전트인 워크플로우 내에서 운영할 수 있다.
이것이 전통적 시스템을 쓸모없게 만들지는 않는다. 인간이 구매를 인가하는 곳이면 어디든 중요하게 남을 것이다. 하지만 더 깊은 계층은 자율 작업 결제다: 에이전트가 다른 에이전트나 서비스에 작업에 대해 비용을 지불하고, 시스템 자체가 작업 완료 여부를 검증한다.
그 계층은 카드 네트워크 주위의 래퍼가 될 수 없다. 이것은 내부에 로직이 있는 머니여야 한다.
검증 가능한 워크플로우는 기본이다. 프로그래머블 신용이 열쇠다.
검증 가능한 워크플로우는 하나의 질문에 답한다:
작업이 발생했는가?
이것이 중요하다. 검증 없이 자율 결제는 눈먼 송금이 된다. 에이전트는 영수증, 작업 해시, Acceptance Predicate, 결제 증명이 필요하다.
하지만 검증만으로는 경제를 만들지 못한다.
더 큰 열쇠는 에이전트가 서로에게 제한된, 프로그래머블 신용을 발행할 수 있을 때 온다.
부모 에이전트는 개인 키를 넘기지 않고도 하위 에이전트에게 예산을 줄 수 있어야 한다. 데이터 공급자는 즉각적인 결제를 요구하는 대신 환매 가능한 Note를 수락할 수 있어야 한다. 컴퓨팅 시장은 작업을 작은 작업 조건부 청구로 가격 책정할 수 있어야 한다. 검증자는 작업이 약정과 일치할 때만 결제를 릴리스할 수 있어야 한다.
이것이 에이전트 결제와 에이전트 경제 간의 차이다.
결제는 가치를 이동한다.
검증은 작업을 증명한다.
신용은 경제 행위자성을 만든다.
Ergo에서 이것은 Reserve, Note, Tracker, Acceptance Predicate 패턴을 통해 표현될 수 있다:
- Reserve는 신용을 뒷받침한다;
- Note는 청구를 운반한다;
- Tracker는 이중 환매를 방지하거나 회계 상태를 기록한다;
- Acceptance Predicate는 환매를 검증된 작업에 바인딩한다.
이것이 에이전트가 결제 클라이언트가 아니라 경제 행위자가 되는 곳이다.
네 가지 프로그래머블 원시 요소
작은 어휘로 대부분의 에이전트 경제 흐름을 구성하기에 충분하다.
Reserve
Reserve는 뒷받침 계층이다. 담보를 보유하거나 발행 규칙을 정의한다. 오케스트레이터가 하위 에이전트에게 신용을 발행할 때, Reserve는 신뢰의 원천이다.
Note
Note는 프로그래머블 무기명 증서다. 이것은 지출 가능한 예산이나 Reserve에 대한 청구를 나타낼 수 있다. 이것은 가치, 만료 및 작업 특정 조건을 운반한다. Note를 보유하는 누구든지 환매를 시도할 수 있다 — Note 자체의 규칙에 따라.
Tracker
Tracker는 이중 환매를 방지하고 상태 변경을 기록한다. 신용 시스템에서 무결성과 혼란 간의 차이는 Note가 두 번 환매되는 것을 막을 수 있는지 여부다.
Acceptance Predicate
Acceptance Predicate는 작업 규칙이다. 이것은 작업 해시, 검증자 영수증, 기한, 서명 또는 이들의 어떤 구성이든 요구할 수 있다. 이것은 결제 옆이 아니라 결제 내에 살아있는 스마트 계약이다.
함께, 이러한 원시 요소는 결제 수단을 작업에 대한 작은 계약으로 바꾼다.
Ergo가 이 설계에 적합한 이유
eUTXO는 상태를 명시적으로 만든다
모든 박스는 가치, 레지스터, 소비 규칙을 가진다. 에이전트는 트랜잭션을 제출하기 전에 상태 전이를 추론할 수 있다. 비행 중 그들을 놀라게 할 숨은 전역 상태는 없다.
ErgoScript는 로직을 결제 안에 넣는다
소비 조건은 수용 규칙을 인코딩할 수 있다. 결제는 어딘가의 서버에 대한 알림이 아니다 — 그것은 광부들이 강제하는 자체 포함된 계약이다.
Babel Fees는 가스 부트스트래핑 마찰을 줄인다
에이전트는 운영하기 위해 미리 자금이 조성된 네이티브 토큰 지갑을 필요로 하지 않아야 한다. Babel Fees는 Babel 박스가 존재하는 곳이면 어디든 토큰 변환 메커니즘을 통한 수수료 결제를 허용하여, 에이전트 온보딩의 가장 어색한 단계 중 하나를 제거한다.
네이티브 토큰과 Note는 구성된다
토큰은 소유권을 처리한다. Note는 프로그래머블 신용과 결제를 처리한다. 단일 애플리케이션은 둘 다 사용할 수 있고, 단일 트랜잭션에서, 브릿징이나 래핑 없이.
PoW는 거버넌스 킬 스위치를 의미하지 않는다
PoW 베이스 체인은 검증자 거버넌스 또는 재단 거버넌스 시스템과 다른 제어 모델을 가진다. 에이전트 인프라는 위원회로 일시 중지할 수 없는 베이스 계층이 필요하다. PoW가 그것을 제공한다.
에이전트 경제를 위한 원칙
이것들은 모범 사례가 아니다. 이것들은 규칙이다.
- 숨은 커스토디가 없다. 사용자는 항상 자금을 누가 제어하는지 알아야 한다.
- 무제한 에이전트가 없다. 모든 에이전트는 명시적 지출 한도를 얻는다.
- 약관 없는 결제가 없다. 가격, 작업, 기한, 검증자는 명시적이고, 기계가 읽을 수 있으며, 서명된다.
- 영수증 없는 결제가 없다. 결제와 작업 검증은 영원히 감사 가능하다.
- 감사 없는 프로덕션 주장이 없다. 데모는 데모다. 감사는 감사다. 이것들을 혼동하는 것은 부정행위다.
- 단일 레일 절대주의가 없다. 에이전트 경제는 계층화되고 상호운용 가능하거나, 또는 에이전트 경제가 아니다.
- 가짜 탈중앙화가 없다. 서버가 결과를 다시 쓸 수 있다면, README는 첫 번째 줄에 그것을 말한다.
반박론
기존 결제 네트워크가 에이전트 상거래를 해결할 수 있을까?
그들은 인간이 여전히 모든 구매 뒤에 있는 부분인 구매자 인가 상거래의 대부분을 해결할 것이다. 이것이 신뢰 최소화 작업 결제, 프로그래머블 Note, 또는 에이전트-에이전트 신용의 필요성을 제거하지 않는다. 두 계층은 다른 문제를 해결한다.
EVM 시스템이 충분할까?
계정 모델 체인은 이러한 패턴 중 많은 것을 구현할 수 있다. 주장은 다른 시스템이 무능하다는 것이 아니다. 그것은 eUTXO, ErgoScript 및 Note가 이 설계를 비정상적으로 직접적이고 감사 가능하며 분석 가능하게 만든다 — 그리고 에이전트 인프라를 위해 이 세 속성이 생태계 규모보다 더 중요하다는 것이다.
에이전트가 신용을 필요로 하지 않을까?
일부 에이전트는 단순 결제만 필요로 할 것이다. 하지만 에이전트가 조율을 시작하는 순간 — 오케스트레이터, 하위 에이전트, 위임된 예산, 지연된 결제 — 신용 수단이 필수가 된다. 에이전트가 협력할수록, 신용이 더 중요해진다.
사용자가 자율 결제를 신뢰하지 않는다면?
그들은 신중해야 한다. 정확히 이것이 에이전트 결제가 지출 한도, 영수증, 감사 게이트, 인간 오버라이드 정책, 투명한 위험 공개를 필요로 하는 이유다. 신뢰는 시스템이 무엇을 보장할 수 있고 할 수 없는지에 대해 정직함으로써 얻어진다.
너무 이른 것 아닐까?
인간 인터넷의 레일은 사용자가 있기 전에 지어졌다. 에이전트 경제의 레일은 지금 지어지고 있다. 질문은 소프트웨어 에이전트가 돈을 필요로 할지 여부가 아니다. 그것은 그들이 받을 돈이 좋을 것인지다.
빌더를 위한 실용적인 호출
작게 빌드하라. 테스트넷에서 빌드하라. 코드를 공개하라. 영수증을 보여 줄라. 실패 모드를 기록하라. 데모를 재현 가능하게 만들라. 재생, 만료, 잘못된 결과, 잘못된 수취인, 부분 작업, 실패한 결제에 대한 테스트를 추가하라. 당신이 모르는 것을 문서화하라.
에이전트 경제는 더 많은 모호한 주장을 필요로 하지 않는다. 그것은 정밀 조사를 견딜 수 있는 작동 예제를 필요로 한다.
원시 요소를 빌드하라. 정직하게 테스트하라. 공개적으로 감사하라. 천천히 출시하라. 그러면 그것들에 의존하는 것들을 빌드하라.
이것이 다음 10년의 일이다.