What Is A2A-T, Really? A Source-Code-Based Breakdown of OpenAN

In the agent-gateway space, there are plenty of documents and very few things that run. OpenAN is currently the only telecom-grade multi-agent protocol implementation with readable source code: the IETF drafts (RTGWG / DMSC / OPSAWG) are still text, while OpenAN has shipped its “registry center” and “orchestration center” — roughly 11,800 lines of Python, 762 commits, Apache-2.0.

For people working on standards, code is more honest than drafts: it reveals which designs are actually implemented and which are still slogans. This article is based on source cloned on 2026-08-31 from registry-center (AtomGit) and a2a-t-sdk-python v1.0.0 (GitHub org project-openan); nothing was deployed.

1. The Key Finding: A2A-T Is Not a New Protocol

The registry center’s AgentCard validation imports standard A2A types directly:

from a2a.types import AgentCard, AgentProvider, AgentSkill, AgentCapabilities, AgentInterface

The entire data model is the standard A2A AgentCard, unchanged. All A2A-T enhancements ride on the capabilities.extensions field; the registry only checks count and size (≤10 extensions per agent, ≤512 characters of JSON each) and does not parse their content.

This “container, no parsing” design is worth studying: it means protocol evolution never touches the registry, but it also means the registry cannot verify whether registered extensions are compliant. Compare this with IETF draft-zhang-dmsc-gateway-directory-sync, which argues a capability directory should maintain validated capability information — a real gap, and also an opportunity for the two systems to complement each other.

2. Task-T’s Actual Wire Format: YAML Header Plus Prompt Body

task_prompt_format.py in the SDK is under 60 lines. Task-T messages look like:

---
scenario_code: <scenario code>
language: <language>
description: <description>
---

<free-form body>

Three required fields, a hand-written line-by-line parser. The “deterministic task mode” lands on prompt engineering, not a new message protocol — hard to see without reading the code.

3. The Standardization Home Is TM Forum

Every extension URI in the SDK points into the TM Forum namespace:

https://projects.tmforum.org/a2aproject/telecommunication/extensions/Task-T/v1
https://projects.tmforum.org/a2aproject/telecommunication/extensions/Negotiation-T/v1

All versioned v1. A2A-T’s standardization home is TM Forum; the IETF drafts cover the network-layer view. They are not competitors — decide which organization to submit to before writing.

4. Four Official Extensions, Uneven Implementation

The official architecture page lists exactly 4 extensions (the 6 reported elsewhere include Memory-T / Governance-T, which are not on the official list):

Extension	SDK v1.0.0 status
Task-T	✅ prompt generation + JSON Schema slot validation
Negotiation-T	✅ three negotiation types, but semantics are mostly echo pass-through
Notification-T	⚠️ doc examples only, zero source implementation
Authorization-T	❌ zero hits across the codebase, paper only

Cross-checked: registry “blacklist fallback, no extension parsing” plus SDK “no authentication” means the most security-critical official extension has no open-source implementation at all. That is both a gap and an opening — operator-side authorization and control standards fit exactly there.

5. Maturity: Prototype, Not Production

The README’s “design constraints” section is the most honest part of the whole project: single-instance deployment, default cap of 100 registered agents, 1 MB request bodies, file storage by default, and an explicit statement that the module is for internal system integration and must not be exposed to the public internet. The official roadmap (June 2026 seed code → December 2026 scenario packs → 2027 commercial validation) matches these numbers.

Two details feel distinctly telecom: owner isolation uses TLS client-certificate CNs instead of an account system (trust comes from the network layer), and the JWK key-distribution endpoint is rate-limited separately at 10 requests/second — an order of magnitude below other endpoints, guarding against amplification.

6. Three Takeaways for Standards Work

1. “Extensions as opaque containers” is a question standards must answer — the tension between engineering flexibility and verifiable capabilities, which the IETF directory-sync draft addresses from the other side.
2. Semantic capability discovery is already standard practice, but nothing guarantees determinism or explainability of results — a real problem in telecom network management.
3. The review workflow is a two-state machine (registered → published); operator inventory models use many states (in-service / retiring / frozen). If you are defining a state model for agent capability directories, this is a ready-made case study.

Limitations

All conclusions come from the main branches of two repositories (cloned 2026-08-31) and openan.dev; nothing was deployed; the Java SDK was not read; maturity judgments are inferences from design constraints, not official positions. Verify everything yourself: git clone --depth 1 https://atomgit.com/OpenAN/registry-center.git.