연동

에이전트 인터페이스 (Agent-to-Agent)

당신의 비즈니스 에이전트를 다른 에이전트에게 노출하라. 고객의 AI 어시스턴트가 그것을 발견하고, 문의하고, 구조화되어 미리 채워진 요청을 MCP와 A2A로 제출할 수 있다 — 되돌릴 수 없는 것은 사람이 확인한다.

에이전트 인터페이스는 당신의 에이전트를 채팅 속 사람뿐 아니라 고객의 AI 어시스턴트에게도 기계 대 기계로 접근 가능하게 만든다. 어시스턴트는 근거 기반 질문을 하고 구조화되어 미리 채워진 요청을 제출할 수 있다. 당신 측은 전처리를 하고 사람이 확인할 요약을 돌려준다. 이것은 개방형 에이전트 표준 — MCP(도구)와 A2A(에이전트 카드) — 위에 구축되므로, 구현할 맞춤 프로토콜이 없다.

agent4.io는 agent-to-agent의 비즈니스 측이다. 당신은 인터페이스를 켠다. 기존의 근거 기반 에이전트 — 동일한 지식, 스킬, 거부 경계 — 가 다른 에이전트에게 접근 가능해진다. 사람의 채팅 경험은 아무것도 바뀌지 않는다.

상호작용의 형태

발견 및 연결

두 계층이 있으며, 차이는 어시스턴트가 무엇을 하도록 허용되는가이다.

읽기 계층 — 자동 발견, 설정 불필요

어시스턴트는 표준 주소에서 당신 에이전트의 카드를 찾고 즉시 시작할 수 있다.

  • https://<your-domain>/.well-known/agent.json — A2A 에이전트 카드 (화이트라벨 도메인, 또는 당신의 agent4.io URL).
  • 페이지 내부 — <link rel="agent" href="…"> 태그와 window.agent4, 그래서 이미 당신 사이트에 있는 브라우저 기반 어시스턴트가 추가 이동 없이 그것을 찾는다.

읽기 계층은 공개적이고 안전하다 — 근거 기반 답변, 접수 계약, 그리고 상태 조회만. 개인 데이터 없음, 요청 제출 없음.

쓰기 계층 — 일회성 페어링

누군가를 대신해 요청을 제출하려면, 어시스턴트는 그 사람과 한 번 페어링되어야 한다.

  1. 고객이 당신의 채팅이나 위젯에서 "AI 어시스턴트와 함께 사용" 을 탭한다.
  2. 붙여넣을 텍스트 블록이 아니라 일회용 코드(복사 가능한 링크, QR 코드, 딥 링크 포함)를 받는다.
  3. 어시스턴트가 코드를 범위 제한 토큰으로 교환하고(OAuth 디바이스 / 인증 코드 방식 교환) 에이전트 카드를 직접 읽는다.

그 결과 토큰은 인증된 그 사람에게 묶이고, 범위가 제한되며(이 비즈니스, 이 고객, 전처리만), 단기이고, 고객이 언제든 취소 가능하다. 그것이 바로 주장된 신원을 출처가 있는 신원으로 격상시키는 요소다.

동사

Verb계층목적
get_capabilitiesread이 에이전트가 답하고 할 수 있는 것 — 서비스와 경계
get_requirements(service)read접수 계약 — 필수/선택 필드, 타입, 그리고 근거 기반 정책
ask(question)read인용이 있는 근거 기반 답변, 또는 범위를 벗어나면 인계
status(reference)read이전 요청의 진행 상황
propose(service, payload)write구조화된 요청 제출 — 초안 + 요약을 반환
handoff_to_human(reference?)write어시스턴트가 자신의 소유자에게 다시 건네는 연속 링크

접수 계약

get_requirements는 마찰을 없애는 핵심이다 — 어시스턴트는 당신의 형식을 결코 추측할 필요가 없어야 한다. 그것은 서비스가 필요로 하는 필드와 그 주변의 근거 기반 정책(보증금, 리드 타임, 취소)을 반환하며, 이는 당신 에이전트의 스킬에서 파생된다 — 그래서 어시스턴트는 아는 것을 채우고 정말로 빠진 것만 자신의 소유자에게 묻는다.

초안 모델

propose는 절대 "완료"를 반환하지 않는다. 가장 강한 상태는 tentative — 완료된 거래가 아니라 준비되어 확인을 기다리는 요청 — 이다.

  • needs_info — 필수 필드가 빠졌거나 모호하다. open_questions를 볼 것.
  • tentative — 초안으로 수락됨, 확인 대기 중.
  • declined — 수락 불가 (정책 또는 범위를 벗어남).

사람이 확인하기 전까지는 아무것도 confirmed가 아니다. 당신의 마케팅과 응답은 이를 반영해야 한다 — tentative 예약은 요청이지, 확보된 테이블이 아니다.

사람에게 인계

어느 시점에서든 어시스턴트(또는 당신의 에이전트)는 인계를 요청할 수 있다. agent4.io는 그 세션에 범위가 제한된 연속 링크를 발급한다. 고객이 그것을 열어 전체 대화 기록을 보고, 사람으로서 이어간다 — 초안이 확인되기 전에 그것을 수정하거나 취소하면서. 행위자 귀속은 인계 시점에 전환되므로, 기록에는 누가 무엇을 말했는지가 항상 남는다.

감사

모든 상호작용은 추가 전용으로 기록되며 요청 참조에 묶인다 — 각 인바운드 주장(호출한 어시스턴트와 그것이 짝지어진 사람에게 귀속됨), 당신이 반환한 각 응답, 그리고 모든 단계의 행위자. 데이터를 제출하는 요청은 결코 익명이 아니다 — 그것이 바로 당신이 고객의 어시스턴트를 그 고객의 승인된 대리인으로 취급하고, 나중에 정확히 무엇이 교환되었는지 증명할 수 있게 하는 요소다.

실제 작업 예시

  1. 발견 — 어시스턴트가 당신의 에이전트 카드를 가져온다.
  2. 페어링 — 고객이 AI 어시스턴트와 함께 사용을 탭하고, 어시스턴트가 코드를 범위 제한 토큰으로 교환한다.
  3. get_requirements("reservation") — 날짜/시간 범위, 인원 수, 좌석, 식이 참고 사항, 이름, 연락처, 그리고 보증금과 취소 정책.
  4. propose("reservation", …){ status: "tentative", summary, reference, open_questions: [] }.
  5. 확인 — 어시스턴트가 소유자에게 요약을 보여주고, 확인되면 당신의 팀(또는 예약 가능 여부 확인)이 그것을 확정한다.
요청과 응답 형태는 플랫폼 구현과 함께 확정된다. 이 페이지는 모델과 보장을 설명한다. 화이트라벨 및 맞춤 앱기록도 참고하라.