Ai-Agent

A2A(Agent-to-Agent) 프로토콜: 에이전트 간 협업 표준과 결제 레이어의 접점

A2A(Agent-to-Agent) 프로토콜: 에이전트 간 협업 표준과 결제 레이어의 접점

A2A(Agent2Agent)는 따로 운영되는 에이전트에 일을 맡기고, 진행 상태와 결과를 받는 방법을 표준화합니다. 요청자는 Agent Card로 상대의 기능·접속 주소·인증 조건을 확인하고, 오래 걸리는 일은 Task로 추적합니다. MCP는 각 에이전트가 도구와 데이터를 사용하는 연결을 담당하며, 구매 승인이나 결제 정산은 AP2·x402 같은 별도 규약이 맡습니다. A2A로 협업하는 데 블록체인이나 지갑은 필요하지 않습니다. A2A 명세, MCP와의 역할 분담

더 보기
KYA(Know Your Agent): AI 에이전트 신원 검증, 표준 경쟁과 온체인 실태

KYA(Know Your Agent): AI 에이전트 신원 검증, 표준 경쟁과 온체인 실태

AI 에이전트가 신원 인증서나 온체인 등록 번호를 제시해도, 그 사실만으로 결제나 데이터 접근을 허용해서는 안 됩니다. 어느 에이전트인지, 요청자가 그 신원을 통제하는지, 지금 하려는 행동을 위임받았는지, 과거 평가를 얼마나 믿을지는 서로 다른 확인입니다. KYA(Know Your Agent)는 이런 확인을 묶어 부르는 이름입니다. ERC-8004는 식별자와 공개된 신뢰 신호를 제공하고, Visa TAP이나 신원 검증 업체는 요청·조직·사람을 확인하는 다른 방식을 제공합니다. 최종 접근 결정은 서비스를 제공하는 쪽에 남습니다. ERC-8004 명세와 Trulioo의 제품 설명도 각각 등록과 검증이 보장하는 범위를 제한합니다.

더 보기
AI 자기개선은 모델 밖 하네스에서 먼저 온다

AI 자기개선은 모델 밖 하네스에서 먼저 온다

모델 가중치를 그대로 둬도 AI 에이전트는 실행 기록을 바탕으로 다음 작업을 더 잘하도록 바뀔 수 있습니다. 실패 원인을 찾아 프롬프트·메모리·도구·실행 절차를 수정하고, 별도 평가를 통과한 변경을 다음 실행에 남기는 방식입니다. 하네스 자기개선의 핵심은 재시도 횟수가 아니라, 검증한 변경이 축적된다는 데 있습니다. Darwin Gödel Machine(DGM)은 코딩 에이전트의 코드를 바꾸는 사례이고, GEPA와 Reflexion은 각각 프롬프트와 메모리를 바꾸는 사례입니다. 세 방법 모두 모델을 다시 학습하는 것과 구분됩니다. (DGM, GEPA, Reflexion)

더 보기
Apify x402와 Coinbase 지갑 심층편: 에이전트가 웹 자동화 도구를 직접 사는 구조

Apify x402와 Coinbase 지갑 심층편: 에이전트가 웹 자동화 도구를 직접 사는 구조

웹 스크래핑 플랫폼 Apify가 x402 결제 지원을 발표했다. AI 에이전트가 Apify 계정도 API 키도 없이 Base 체인의 USDC로 결제하고, 2만 개가 넘는 Actor를 실행할 수 있다는 내용이다. Apify는 기존 x402 생태계를 약 2,000개 엔드포인트 규모로 보고, 이번 통합으로 결제 가능한 도구 표면이 약 10배 커졌다고 설명한다.

더 보기
Hermes Agent v0.18: 스스로 배우는 에이전트와 MoA가 만났을 때

Hermes Agent v0.18: 스스로 배우는 에이전트와 MoA가 만났을 때

Nous Research가 만든 오픈소스 에이전트 Hermes Agent가 2026년 7월 1일 v0.18.0을 냈습니다. 릴리스 노트는 이번 버전을 “The Judgment Release"라고 부릅니다. 새 명령어 몇 개를 더한 마이너 업데이트로 보면 핵심을 놓치기 쉽습니다. 공식 문서는 Hermes Agent를 “스스로 배우는 AI 에이전트"라고 소개하는데, 실제로 이 프로젝트는 쓸수록 메모리와 스킬을 쌓아가는 학습 루프를 핵심 설계로 삼고 있습니다. 이 글은 그 자기개선 루프가 v0.18에서 어떻게 다듬어졌는지, 그리고 같은 버전에서 정식 모델 선택지가 된 Mixture of Agents(MoA)가 이 루프 안에서 어떤 역할을 맡는지를 정리합니다.

더 보기
AI 에이전트 상거래와 조율: ERC-8183, ERC-8226, ERC-8001, ERC-8041

AI 에이전트 상거래와 조율: ERC-8183, ERC-8226, ERC-8001, ERC-8041

이전 글에서 다룬 ERC-8004/8126/8196은 AI 에이전트의 신원 등록, 보안 검증, 정책 실행이라는 세 계층을 정의한다. 에이전트를 식별하고, 위험도를 평가하고, 소유자가 허용한 범위 안에서만 거래를 실행하게 만드는 기반이다. 여기까지가 답하는 질문은 하나다. “이 에이전트를 믿고 내 대신 움직이게 해도 되는가.”

더 보기
ERC-8004 에이전트 평판: 온체인 등록과 조회

ERC-8004 에이전트 평판: 온체인 등록과 조회

지난 글에서 ERC-8004/8126/8196 신뢰 스택 개요를 살펴봤다. ERC-8004는 AI 에이전트 신원 등록(Identity Registry), 평판 기록(Reputation Registry), 작업 검증(Validation Registry) 세 레지스트리를 정의하는 Ethereum Draft 표준이다. 개념 설명은 그 글에 정리돼 있으니, 여기서는 중복하지 않는다.

더 보기
AI 에이전트 신뢰 스택: ERC-8004, ERC-8126, ERC-8196

AI 에이전트 신뢰 스택: ERC-8004, ERC-8126, ERC-8196

AI 에이전트가 사용자를 대신해 자산을 쓰고, 컨트랙트를 호출하고, 유료 API에 접근하는 시대가 가까워지면서 “이 에이전트를 믿고 돈을 맡겨도 되는가"라는 질문이 실질적인 설계 문제가 됐다. 블록체인 커뮤니티는 이 문제를 세 계층으로 나눠 접근하고 있다. 신원 등록(ERC-8004), 보안 검증(ERC-8126), 정책 기반 실행(ERC-8196)이다.

더 보기
Open Knowledge Format(OKF): 에이전트용 지식 표현 개방형 포맷

Open Knowledge Format(OKF): 에이전트용 지식 표현 개방형 포맷

AI 에이전트가 실패하는 원인을 들여다보면 모델 성능보다 맥락의 부재가 먼저 나오는 경우가 많습니다. 테이블 스키마, 지표 계산법, 장애 대응 런북, 두 시스템 사이의 join path가 카탈로그 벤더, 사내 위키, 코드 주석, 개인 노트에 흩어져 있고, 에이전트 개발자마다 같은 context assembly 문제를 처음부터 다시 풉니다.

더 보기
Future AGI: AI 에이전트 평가·관찰·개선을 한곳에서

Future AGI: AI 에이전트 평가·관찰·개선을 한곳에서

AI 에이전트를 만들어 본 사람은 이 장면이 익숙합니다. 데모는 잘 돕니다. 그런데 프로덕션에 올리면 환각이 터지고, 뭐가 왜 틀렸는지 추적이 안 됩니다. 그래서 평가 도구 하나, 관측 도구 하나, 가드레일 하나를 따로 붙이죠. 진짜 문제는 이것들이 서로 말을 안 한다는 겁니다. 고치는 루프가 닫히지 않습니다.

더 보기
카테고리
태그