A2A 역할과 기능에 대한 고찰
AI 에이전트를 둘 이상 연결해 활용하기 시작하면 필연적으로 하나의 핵심적인 질문에 부딪히게 된다. "한 에이전트가 다른 에이전트에게 작업을 위임하려면 구체적으로 무엇을 합의해야 하는가?"
단일 프레임워크 내에서는 단순한 함수 호출만으로 충분하며 동일한 조직 내부라면 사내 API 규약을 따르는 것만으로도 문제는 쉽게 해결된다. 하지만 작업을 넘겨받을 상대 에이전트가 전혀 다른 프로그래밍 언어와 프레임워크를 기반으로 하고 심지어 다른 조직에 의해 개발된 시스템이라면 이야기가 달라진다. 이처럼 철저히 이질적인 에이전트 간의 상호운용성 문제를 정조준하여 등장한 표준이 바로 A2A(Agent-to-Agent) 규격이다. A2A는 2025년 6월 리눅스 재단으로 이관되며 오픈소스 생태계에 편입되었고 2026년에 이르러 마침내 v1.0을 공식 발표하며 범용 프로토콜로서의 확고한 체계를 갖추었다.
이 글에서는 A2A v1.0의 전체 명세를 세밀하게 훑어보며 다음 두 가지 핵심 쟁점을 조명하고자 한다. 첫째는 이 프로토콜이 시스템적으로 '어디까지를 규정하고 보장하는가'에 대한 명확한 경계를 확인하는 일이다. 둘째는 명세의 범위를 벗어나 시스템을 구현하는 개발자가 여전히 독자적으로 판단하고 결정해야 하는 '공백 영역'을 파악하는 일이다. 특히 두 번째 쟁점을 주의 깊게 살펴보는 이유는 분명하다. 단순히 'A2A 표준을 준수했다'는 사실 하나만으로 시스템 간 협업의 모든 난제가 해결되었다고 착각하기 쉬운 함정을 경계하기 위함이다. 프로토콜이 의도적으로 관여하지 않고 남겨둔 문제들은 여전히 시스템 설계자와 개발자가 스스로 해결해야 할 온전한 책임으로 남는다.
전제 사항
명세 전체를 지배하는 설계 원칙으로 상호작용하는 에이전트들은 서로에게 블랙박스처럼 보여져야 한다는 것이다. 즉 에이전트끼리는 내부 상태를 공유하지 않고, 메모리를 나눠 쓰지 않으며, 상대가 어떤 모델을 쓰는지 어떤 도구를 갖고 있는지 알 필요가 없다. 에이전트 간 협업은 오직 상대가 선언한 능력과 서로 주고받은 메시지에 기반하여 이루어지게 되는 것이다.
이 전제가 프로토콜의 모양을 결정한다. 교환의 단위가 함수 호출이 아니라 **작업(Task)**인 이유가 여기에 있다. 함수 호출은 호출자가 피호출자의 시그니처와 실행 시간을 안다고 가정하지만 불투명한 상대에게 넘긴 일은 얼마나 걸릴지, 중간에 사람의 개입이 필요할지, 부분 결과가 나올지를 호출자가 알 수 없다. 그래서 A2A는 요청·응답이 아니라 상태를 가진 작업의 수명주기를 규정하는 방향으로 설계됐다.
같은 이유로 A2A는 MCP(Model Context Protocol)과 경쟁하지 않는다. MCP는 모델에게 도구와 컨텍스트를 공급하는 수직 방향의 규약이고 A2A는 대등한 에이전트끼리 일을 넘기는 수평 방향의 규약이다. 따라서 어느 한쪽이 다른 쪽을 대체할 수 있는 관계가 아니다.
에이전트 카드: 탐색과 협상의 단위
한 에이전트가 상대 에이전트에게 자신이 무엇을 할 수 있는지 선언해서 알려 주어야 하는데 그 선언을 에이전트 카드(Agent Card)라고 한다. JSON 문서 하나에 신원, 능력, 접속 지점, 인증 요구사항이 들어간다.
- capabilities —
streaming,pushNotifications,extendedAgentCard지원 여부를 불리언으로 선언한다. - skills — 이 에이전트가 수행할 수 있는 작업들의 목록. 각 스킬에 설명과 예시, 입출력 모드가 붙는다.
- supportedInterfaces — 서비스 엔드포인트 배열. 인터페이스마다 자기 트랜스포트 바인딩과 자기
protocolVersion을 갖는다. - securitySchemes — API 키, HTTP 인증, OAuth2, OpenID Connect, 상호 TLS 중 무엇으로 인증하는지 정의한다.
- extensions — 지원하는 확장의 URI 목록과 각각의 필수 여부를 표시한다.
- signature — 카드 자체에 대한 JWS 서명에 해당한다.
첫째, 스킬 설명은 구조화되지 않은 자연어 서술이다. 스킬에는 id와 이름, 태그가 붙지만 그 스킬이 무엇을 입력으로 받아 무엇을 내놓는지를 컴퓨터가 기계적으로 판단하기 적합한 타입 선언 같은 것은 적용되지 않는다. 즉 카드를 읽어서 "이 작업에 이 에이전트가 맞다"고 판정하는 일은 명세가 제공하는 기능이 아니라 카드를 읽는 쪽이 알아서 할 일이라는 것이다. 대개 그 판정을 LLM에게 맡기게 되는데 이러한 배경에서 카드의 작성 품질이 곧 라우팅 품질을 좌우하게 되는 것이다.
둘째, 인증 전후에 다른 카드를 보여줄 수 있다. capabilities.extendedAgentCard가 켜져 있으면 인증된 클라이언트는 GetExtendedAgentCard로 더 많은 스킬이 담긴 카드를 받는다. 공개 카드에는 최소한만 싣고 실제 능력은 인증 뒤에 노출하는 설계가 명세 차원에서 지원된다는 뜻이다.
서명에 대해서는 오해하기 쉬운 지점이 하나 있다. 카드는 JCS(RFC 8785)로 정규화한 뒤 JWS(RFC 7515)로 서명하며 클라이언트는 이를 검증할 수 있다. 이때 검증이 보장하는 것은 카드가 위조되거나 변조되지 않았고 제공자가 맞다는 것이지 그 에이전트가 카드에 적힌 일을 실제로 잘한다는 것을 의미하지는 않는다. 즉 서명은 진위를 증명하는 것이지 능력에 대한 신뢰도를 증명하는 것은 아니라는 것에 유념할 필요가 있다.
작업 단위 상태 공유가 핵심
회사에서 직원들이 협업할 때 서류의 결재 진행 상태(기안-검토-승인)가 중요한 것처럼 AI들끼리 협력할 때도 가장 중요한 것은 **작업(Task)**이며 이 작업의 진행 상태(대기-진행-완료)을 공유하는 것이 에이전트들이 소통하는 가장 확실한 방법이다. A2A v1.0에서 정의하는 작업 진행 상태는 다음과 같이 총 여덟 가지이며 세 부류로 나누고 있다.
- 진행 중 —
TASK_STATE_SUBMITTED,TASK_STATE_WORKING - 인터럽트 —
TASK_STATE_INPUT_REQUIRED,TASK_STATE_AUTH_REQUIRED - 종단 —
TASK_STATE_COMPLETED,TASK_STATE_FAILED,TASK_STATE_CANCELED,TASK_STATE_REJECTED
인터럽트 상태가 이 설계에서 가장 특징적인 부분인데 작업 도중에 추가 정보가 필요해지거나 자격증명이 필요해지는 상황을 예외가 아니라 정상 상태로 인정하고 그 상태에서는 메시지를 더 보내 작업을 이어갈 수 있게 했다. 반대로 종단 상태에 도달한 작업은 더 이상 메시지를 받지 않게 설계되어 있어 대화를 이어가려면 새 작업을 만들도록 가이드하고 있다.
작업을 묶는 식별자도 두 가지 형태로 정의하는데 taskId는 개별 작업이고 contextId는 관련된 작업들의 묶음을 가리키게 된다. contextId는 개별 작업은 끝나도 여러 작업들을 걸쳐서 맥락은 이어질 수 있기 때문에 이를 반영한 것이라고 보면 되겠다.
작업 내용물을 담는 구조에서도 설계의 의도가 뚜렷하게 드러난다. 작업 데이터는 에이전트 간에 오간 메시지 기록인 history와 그 결과로 만들어진 산출물인 artifacts로 분리된다. 이는 "무슨 대화를 나누었는가"와 "실제로 무엇을 만들어 냈는가"를 명확히 구분하겠다는 선언이다. 이로써 작업의 완료 판정 기준을 단순한 발언이나 대화의 흐름이 아닌 실질적인 산출물에 둘 수 있는 구조적 기반이 마련된다. 다만, 명세 자체가 산출물 기반의 완료 판정을 시스템적으로 강제하지는 않는다. 작업을 최종 완료 상태(TASK_STATE_COMPLETED)로 전환하는 판단은 전적으로 해당 작업을 수행한 에이전트의 자율적인 몫으로 남겨둔다.
한편, 에이전트가 주고받는 메시지의 내용물은 Part라는 단위로 표현된다. v1.0 규격에서는 텍스트, 바이트(바이너리 데이터), URL 참조 등을 개별적으로 구분하지 않고 Part라는 단일 타입으로 통합하여 메시지 구조를 간결하게 만들었다.
단일 데이터 모델과 세 개의 통신 방식 지원
A2A 시스템의 데이터 모델은 프로토콜 버퍼(Protocol Buffers)를 기반으로 정의되며 통신을 위해 JSON-RPC 2.0, gRPC, HTTP+JSON/REST라는 세 가지 트랜스포트(Transport) 방식을 지원한다. 이 구조의 핵심은 '세 가지 바인딩(Binding)이 기능적으로 완벽하게 동일해야 한다'는 것이다. 서버가 어떤 통신 방식을 선택하든 클라이언트는 동일한 의미와 결과를 보장받아야 하며 에이전트 카드에 선언된 인증 방식 역시 모든 바인딩에서 동일하게 작동해야 한다. 예를 들어, REST 방식을 사용할 때 스트리밍 기능은 반드시 SSE(Server-Sent Events)로 구현하도록 명시한 것도 같은 맥락이다. 이는 통신 방식의 선택이 에이전트의 기능적 제약으로 이어져서는 안 되기 때문이다.
제공되는 핵심 기능(작업 단위) 역시 바인딩 종류와 무관하게 일관성을 유지한다. 구체적으로는 메시지 전송(SendMessage, SendStreamingMessage), 작업 관리(GetTask, ListTasks, CancelTask), 스트림 재연결(SubscribeToTask), 푸시 설정 관리(CRUD 4종), 그리고 상세 카드 조회(GetExtendedAgentCard) 기능이 공통으로 제공된다. REST 환경의 경우, 이러한 기능들은 POST /messages, GET /tasks/{id}, POST /tasks/{id}:cancel과 같이 직관적인 자원 중심의 API 경로로 매핑된다.
실무 환경에서 이러한 기능적 동등성이 시사하는 바는 크다. 어떤 바인딩을 사용할지 결정하는 기준은 애플리케이션이나 SDK의 차이가 아니라 네트워크 인프라의 환경이 되기 때문이다. 즉, 시스템 앞단에 위치한 API 게이트웨이, 프록시, 로드밸런서가 어떤 프로토콜의 통과를 허용하느냐가 관건이 된다. gRPC 통신이 종단 간(End-to-End)으로 지원되는 네트워크인지, 중간 네트워크 장비가 긴 시간 유지되는 SSE 연결을 강제로 끊지는 않는지 등의 인프라 조건이 실제 통신 방식을 결정짓게 된다.
오래 걸리는 작업을 위한 비동기까지 고려한 응답 방식
에이전트 간 협업에서는 내부 구조를 알 수 없는 대상에게 작업을 위임하므로 해당 작업이 언제 끝날지 예측하기 어렵다. 명세는 이러한 비동기적 불확실성을 처리하기 위해 다음 세 가지 응답 경로를 제공한다.
첫째, **동기 응답(Synchronous Response)**이다. 처리 시간이 짧은 작업에 적합하며 일반적인 API처럼 요청을 보내고 즉시 결과를 반환받는다.
둘째, **스트리밍(Streaming)**이다. SSE(Server-Sent Events)를 활용해 작업의 진행 상황을 실시간으로 수신한다. 전달되는 이벤트는 단일 래퍼로 캡슐화되며 그 안에는 Task, Message, TaskStatusUpdateEvent, TaskArtifactUpdateEvent 중 하나가 포함된다. 이 스트림 연결은 작업이 최종 상태에 도달하면 자동으로 닫힌다.
셋째, **푸시 알림(Push Notification)**이다. 클라이언트가 네트워크 연결을 장시간 유지하기 어려울 때 사용한다. 사전에 웹훅 URL과 인증 정보를 등록해 두면 서버가 해당 주소로 상태 변화나 산출물 이벤트를 POST 방식으로 전송한다. 알림 설정은 CRUD(생성·조회·목록·삭제)를 모두 지원하며 삭제 요청은 멱등성(Idempotency)을 보장한다.
응답 방식을 이렇게 세 가지로 세분화한 이유는 각 방식이 요구하는 시스템적 비용과 책임이 다르기 때문이다. 스트리밍은 네트워크 연결이 살아있는 동안에만 유효하다는 제약이 있다. 반면 웹훅 기반의 푸시 알림은 클라이언트가 외부에서 접근할 수 있는 수신 엔드포인트를 노출해야 하며 이를 안전하게 보호해야 할 보안 책임까지 함께 떠안게 된다. 이러한 방식들 사이의 간극을 유연하게 메워주는 장치가 바로 SubscribeToTask 기능이다. 네트워크 연결이 끊어지더라도 위임된 작업은 서버에서 멈추지 않고 계속 진행되며 클라이언트는 언제든 다시 접속해 중단된 스트림을 이어받을 수 있다. 즉, 작업의 수명과 네트워크 연결의 수명이 구조적으로 완전히 분리되어 있다는 점이 이 비동기 설계의 가장 핵심적인 요체다.
v1.0 업그레이드 주요 사항 정리
v0.3.x에서 v1.0으로 업그레이드되면서 크게 바뀌고 개선되었는데 기존 버전을 사용 중이어서 마이그레이션을 검토한다면 다음 사항들에 유의해야 한다.
- 메서드 이름 체계 —
message/send같은 경로형 이름이SendMessage같은 동사형으로 바뀌었고 HTTP 경로에서/v1가 제거되었다. ID도tasks/{id}같은 복합 형태에서 단순 리터럴로 정리됐다. - Part 타입 통합 — TextPart·FilePart·DataPart가 하나의 Part로 합쳐지고
kind판별자가 사라졌다. 대신 어떤 멤버가 채워졌는지로 구분한다. 스트림 이벤트도 같은 방식으로 바뀌었다. - 열거형 표기 —
"completed"가"TASK_STATE_COMPLETED"로"user"가"ROLE_USER"로 바뀌었다. 이에 따라 문자열 비교로 상태를 다루던 코드는 전부 손봐야 한다. - 에이전트 카드 재구성 — 단일
url과preferredTransport대신supportedInterfaces[]배열 형태로 바귀었고 확장 카드 지원 여부도capabilities아래로 이동했다. - 오류 모델 교체 — A2A 시스템의 오류 처리 표준이 일반적인 웹 API 중심의 방식에서 보다 체계적이고 기계가 해석하기 좋은 RPC 중심의 오류 모델로 개선되었다.
- 신규 추가 — 필터링이 가능한
ListTasks, 단일 엔드포인트에서 복수 에이전트를 다루기 위한tenant필드, 커서 기반 페이지네이션, Mutual TLS, 그리고 확장 메커니즘이 새롭게 추가되었다. - 기타 —
mimeType이mediaType으로 바뀌었고 타임스탬프는 밀리초 정밀도가 필수로 되었다.
OAuth 인증 방식의 변화는 보안 측면에서 각별히 주목할 만하다. 기존에 사용되던 암묵적 흐름(Implicit Flow)과 비밀번호 흐름(Resource Owner Password Credentials Flow)은 토큰 및 자격증명 정보가 탈취될 위험성이 커 명세에서 완전히 제거되었다. 그 대신, 기기 코드 흐름(Device Code Flow, RFC 8628)과 PKCE(Proof Key for Code Exchange)가 새롭게 도입되었다. 이는 해당 명세가 현대의 엄격한 보안 표준을 충실히 따르고 있음을 보여준다. 더불어 이 프로토콜이 단순한 브라우저 기반 애플리케이션을 넘어 서버 간 통신이나 다양한 기기 환경을 핵심 타깃으로 삼고 있음을 명확히 시사하는 대목이다.
미래의 변화를 수용하기 위해 준비된 확장 메커니즘의 구조도 눈여겨볼 필요가 있다. 시스템 확장은 에이전트 카드 내에 고유 식별자(URI)와 '필수 적용 여부'를 명시하는 방식으로 선언된다. 클라이언트는 요청 시 A2A-Extensions 헤더를 통해 자신이 지원 가능한 확장 목록을 서버에 알린다. 이때 서버가 필수로 지정한 확장을 클라이언트가 지원하지 않는다면 서버는 전용 오류 코드를 반환하며 해당 요청을 거절하여 시스템의 안전성을 보장한다.
이 확장 설계에서 가장 특징적인 부분은 그 유연성에 있다. 이 메커니즘은 단순히 새로운 데이터 필드를 추가하는 수준을 넘어 필요하다면 완전히 새로운 '상태 머신(State Machine)'의 도입까지 확장으로 표현할 수 있도록 구조적 가능성을 열어두었다.
보안 관련 명세
명세에 나타난 보안 관련 항목들을 종합해 보면 프로토콜이 책임지는 보안의 경계가 매우 뚜렷하게 설정되어 있음을 알 수 있다. 가장 대표적인 예가 securitySchemes 속성이다. 이는 해당 에이전트와 통신하기 위해 '어떤 방식으로 자격증명을 제시할 것인가'이라는 인증에 해당하는 것을 선언한다. 즉, 상대방이 누구인지 확인하는 절차만 정의할 뿐 '누가 어떤 작업을 수행해도 되는가'라는 인가에 대해서는 일절 관여하지 않는다. 오류 처리 모델에 인증 실패(401)와 인가 실패(403)가 명확히 구분되어 있는 것 역시 같은 맥락이다. 이는 인가 실패 상황을 시스템적으로 표현할 자리를 마련해 둔 것일 뿐 접근 제어 정책 자체를 프로토콜이 규정한다는 의미가 아니다. 구체적인 권한 검증과 정책 판단은 전적으로 에이전트를 개발하는 구현체의 내부 로직에 맡겨진다.
에이전트 카드의 서명 메커니즘 또한 동일한 원칙을 따른다. 이 서명은 카드가 위변조되지 않았고 발급 주체가 명확하다는 진위를 증명할 뿐 해당 에이전트가 안전하게 동작할 것이라는 신뢰를 보증하는 장치가 아니다. 검증된 서명을 가진 에이전트라 할지라도 위임받은 작업을 바탕으로 내부에서 어떤 행위를 할 것인지에 대해서는 프로토콜이 개입하거나 제어하지 않는다.
결론적으로 A2A 규격은 안전하게 통신 채널을 확립하는 '연결의 보안(Security of Connection)'만을 표준화하고 어떤 권한을 어떻게 안전하게 넘겨줄 것인가 하는 '위임의 보안(Security of Delegation)'은 전적으로 구현자의 책임으로 남겨둔다. 다양한 환경에서 쓰여야 하는 상호운용 프로토콜로서는 매우 합리적인 역할 분담이지만 시스템을 도입하고 설계하는 입장에서는 이 경계를 명확히 인지하고 인가 정책 및 신뢰 검증 로직을 자체적으로 단단하게 구축해야 한다.
구현 단계에서 해결해야 할 문제들
전체 명세를 면밀히 살펴보고 나면 A2A 규격이 의도적으로 다루지 않고 구현자 몫으로 남겨둔 영역들이 분명하게 드러난다. 이는 다음과 같이 크게 다섯 가지 문제로 요약할 수 있다.
첫째, **에이전트의 능력 매칭과 브로커링(Brokering)**이다. 에이전트는 카드를 통해 각자의 능력을 선언하지만 그 스킬에 대한 설명은 비정형적인 자연어로 작성된다. 따라서 프로토콜 자체에는 "특정 작업에 어떤 에이전트가 가장 적합한지"를 기계적으로 판정하는 알고리즘이나 필요한 카드를 어디서 검색해야 하는지에 대한 기준이 없다. 레지스트리, 디렉터리 서비스, 평판 시스템 등 에이전트를 연결해 주는 생태계적 인프라는 명세의 범위를 벗어난 영역이다.
둘째, 다자간 합의(Consensus) 메커니즘의 부재다. A2A는 본질적으로 1:1(Point-to-Point) 작업 위임을 위한 프로토콜이다. 셋 이상의 에이전트가 서로 의견을 교환하여 충돌을 해소하고 최종 결론에 도달하는 절차는 정의되어 있지 않다. 여러 에이전트에게 분산된 작업을 할당한 뒤 그 결과를 취합하고 모순을 판정하는 역할은 전적으로 작업을 호출한 클라이언트 측의 로직으로 해결해야 한다.
셋째, 에이전트 간 인가(Authorization) 정책이다. 앞서 다룬 바와 같이 프로토콜은 접근을 위한 인증 방식만 규정할 뿐이다. '어떤 권한을 가진 주체가 누구에게 어떤 작업을 위임해도 되는가'에 대한 세부적인 접근 제어 및 정책적 판단은 프로토콜이 관여하지 않으며 구현체의 몫으로 남는다.
넷째, 작업의 인과 추적과 순환 위임 방지다.
taskId와 contextId는 통신하는 두 에이전트 사이에서만 유효한 식별자다. 만약 에이전트 A가 B에게 B가 다시 C에게 연속적으로 작업을 넘길 경우 이 과정 전체를 하나의 흐름(인과 그래프)으로 연결하는 표준적인 방법은 명세에 존재하지 않는다. 또한 작업 위임이 무한히 꼬리를 무는 순환을 막는 안전장치 역시 없다. 여러 네트워크 홉(Hop)을 거쳐 전파되는 상관관계 ID(Correlation ID) 체계는 시스템 구현자가 직접 설계하고 적용해야 한다.
다섯째, 프로세스의 실행 수명주기와 런타임 격리다. 명세에 정의된 상태 머신은 작업 자체의 생명주기를 뜻할 뿐 에이전트 프로세스의 생명주기를 의미하지 않는다. 위임받은 에이전트가 어떤 인프라에서 실행되는지, 해당 프로세스가 어떤 시스템 자원에 접근할 수 있는지, 작업 종료 후 컴퓨팅 자원은 어떻게 회수되는지 등은 프로토콜의 관심 밖이다. 특히 작업 과정에서 실제 코드 실행이 수반될 때 이 공백은 더욱 두드러진다. 프로토콜은 작업을 안전하게 넘기는 형식만 규정할 뿐 넘어온 작업이 실제로 구동되는 환경에 대해서는 정보를 제공하지 않는다.
물론 이러한 다섯 가지 빈틈이 프로토콜의 결함을 의미하는 것은 아니다. 서로 다른 시스템 간의 상호운용을 목적으로 하는 프로토콜이 개별 인프라의 실행 모델이나 조직의 세부 정책까지 통제하려 든다면 오히려 범용성이 떨어져 시장에서 채택되기 어렵다. 따라서 A2A가 프로토콜로서의 책임을 최소한의 필수 범위로 한정 지은 것은 매우 타당한 설계적 결단이다. 다만 시스템 설계자는 A2A 규격을 도입했다는 사실 자체만으로는 이 다섯 가지 난제가 자동으로 해결되지 않는다는 점을 명확히 인지해야 한다. 이 문제들은 통신을 관장하는 프로토콜 계층이 아니라 이를 바탕으로 실제 비즈니스 로직과 시스템을 구동하는 런타임 및 실행 계층에서 스스로 해답을 찾아야 할 과제다.
정리 및 요약
A2A 전체 명세를 관통하는 핵심 철학은 상대 에이전트의 내부 구조를 알 수 없다는 불투명성을 전제로 하고 있다. 상대방의 내부를 열어볼 수 없기에 에이전트의 능력은 규격화된 카드를 통해 선언된다. 또한 비동기 작업의 실행 시간을 예측할 수 없기에 정보 교환의 단위는 자체적인 상태를 가지는 작업이 되며 네트워크 연결이 끊어질 위험을 고려하여 작업의 수명과 연결의 수명을 구조적으로 분리했다. v1.0 규격은 여기에 더해 세 가지 통신 바인딩의 기능적 동등성, 카드 서명을 통한 진위 검증, 그리고 미래를 대비한 유연한 확장 메커니즘을 도입함으로써 상호운용 프로토콜로서의 뼈대를 견고하게 완성했다.
하지만 동시에 이 명세는 의도적으로 자신의 개입 범위를 매우 좁고 명확하게 제한한다. 통신 채널을 맺는 연결의 보안은 표준화하지만 권한을 넘겨주는 위임의 보안은 구현자의 몫으로 남겼고 작업 자체의 수명주기는 엄격히 규정하면서도 실제 코드가 구동되는 프로세스 실행의 수명주기에는 관여하지 않는다.
결론적으로 다수의 에이전트를 엮어 실제 비즈니스 시스템을 구축하려는 입장에서 볼 때 A2A는 코드 레벨의 구현체까지 모두 제공하는 완성형 솔루션이 아니다. 오히려 시스템 설계자가 인프라 및 애플리케이션 계층에서 스스로 설계하고 해결해야 할 남은 과제들이 무엇인지 그 경계를 명확하게 정의해 주는 청사진으로서의 기능에 더 가깝다고 볼 수 있다.