The agent_sdks/python/src/a2ui directory contains the Python implementation of
the A2UI agent SDK.
The src/a2ui/core directory contains the base protocol logic, version
management, and schema operations.
manager.py: TheA2uiSchemaManagerhandles loading specification schemas, managing catalogs, and generating system prompts for LLMs.validator.py: ImplementsA2uiValidatorfor validating A2UI messages against JSON schemas and protocol rules.catalog.py: DefinesA2uiCatalogandCatalogConfigfor handling component libraries.payload_fixer.py: Utilities to automatically correct common LLM output issues in A2UI payloads.
provider.py: Implementation ofBasicCatalogfor handling the basic A2UI components.
a2a.py: Utilities for creating A2A Parts with A2UI data and managing the A2UI extension URI.
Support for the Agent Development Kit (ADK) and A2A protocol.
send_a2ui_to_client_toolset.py: Implementation ofSendA2uiToClientToolsetto enable agents to send UI to clients via tool calls.
-
Navigate to the directory:
cd agent_sdks/python -
Run the tests
uv run pytest
To build the SDK, run the following command from the agent_sdks/python
directory:
uv build .To format the code, run the following command from the agent_sdks/python
directory:
uv run pyink .To release a new version of the SDK, follow these steps:
-
Update the version in
src/a2ui/version.py. -
Run the release script from the
agent_sdks/pythondirectory:./release.sh
The script will build the package, upload it to the Artifact Registry, and trigger the release pipeline.
- Check the release status through Sponge: go/spng2?q=PROJECT%3Aa2ui%2Fpypi
- You will see logs for the jobs involved in your release. A successful release is confirmed when the final job, named "publisher", completes successfully.
Important: The sample code provided is for demonstration purposes and illustrates the mechanics of A2UI and the Agent-to-Agent (A2A) protocol. When building production applications, it is critical to treat any agent operating outside of your direct control as a potentially untrusted entity.
All operational data received from an external agent—including its AgentCard, messages, artifacts, and task statuses—should be handled as untrusted input. For example, a malicious agent could provide crafted data in its fields (e.g., name, skills.description) that, if used without sanitization to construct prompts for a Large Language Model (LLM), could expose your application to prompt injection attacks.
Similarly, any UI definition or data stream received must be treated as untrusted. Malicious agents could attempt to spoof legitimate interfaces to deceive users (phishing), inject malicious scripts via property values (XSS), or generate excessive layout complexity to degrade client performance (DoS). If your application supports optional embedded content (such as iframes or web views), additional care must be taken to prevent exposure to malicious external sites.
Developer Responsibility: Failure to properly validate data and strictly sandbox rendered content can introduce severe vulnerabilities. Developers are responsible for implementing appropriate security measures—such as input sanitization, Content Security Policies (CSP), strict isolation for optional embedded content, and secure credential handling—to protect their systems and users.