This page describes how Aion Server adapts A2A requests to Google ADK and maps ADK events back into A2A Messages, Tasks, and streaming events. This page uses the v1 canonical JSON-RPC method names. Aion ingress may continue to accept legacy slash-style aliases for compatibility.Documentation Index
Fetch the complete documentation index at: https://docs.aion.to/llms.txt
Use this file to discover all available pages before exploring further.
1. Inbound Messages
1.1 Agent Invocation
BothSendMessage and SendStreamingMessage use the same execution path: the agent’s
run_async() is always driven as an async event stream.
SendMessage(blocking=true) — collects all events and returns the finalTask.SendMessage(blocking=false) — returns after the first event, continues processing in background withstatus="working".SendStreamingMessage— yields events as they arrive and streams them to the client via SSE.
SendMessageRequest payload; only the response mode differs.
1.2 Part Type Mapping
Inbound A2A message parts are transformed into ADKContent as follows:
| A2A Part | ADK Representation |
|---|---|
Part(text=...) | types.Part(text=...) |
Part(raw=...) | types.Part(inline_data=types.Blob(mime_type=..., data=...)) |
Part(url=...) | types.Part(file_data=types.FileData(mime_type=..., file_uri=...)) |
Part(data=...) | types.Part(text=json.dumps(data)) |
mime_type attribute → guess from filename →
fallback to application/octet-stream.
If the message contains no usable parts, the plain text input from the request is used as a fallback.
1.3 Accessing Inbound Context — ctx.a2a_inbox
When an inbound A2A Message arrives, Aion Server makes it available through ctx.a2a_inbox on
the invocation context:
a2a_inbox contains:
| Field | Type | Description |
|---|---|---|
task | Task | The current A2A Task |
message | Message | The full inbound A2A Message, including non-text parts |
metadata | dict | SendMessageRequest-level metadata (distribution/network, trace info) |
2. Outbound Messages
Valid responses to an A2ASendMessage call are a Message or a Task.
Aion Server constructs the response using the following precedence:
(1) SDK-managed response buffer (authoritative when populated)
The runtime maintains a request-scoped messaging buffer for the current turn. SDK helpers and ordinary ADK event content may populate that buffer, including partial stream output and final non-partial message content that is intended to become the durable reply. When this buffer is non-empty, it is the authoritative source for A2A response compilation.(2) a2a_outbox
Set a2a_outbox in event.actions.state_delta to provide an explicit A2A response. It must be an
A2AOutbox instance wrapping either a Message or a Task:
task_idandcontext_idare set to current values managed by Aion Server.- Canonical routing and identity metadata (e.g.
aion:network, sender IDs) is server-controlled.
- If
a2a_outbox.messageis set → append to current Task history. - If
a2a_outbox.taskis set → treat as a patch to the server’s Task: server merges or extendshistoryandartifacts; providedmetadatamerges shallowly; server-controlled keys take precedence.
(3) Framework-native fallback
If neither the SDK-managed response buffer nora2a_outbox is populated,
Aion Server falls back to framework-native output for the current turn:
- first, accumulated partial stream text
- then, if needed, the final non-partial agent-authored event content
- finally, deterministic final session/state inspection when the adapter exposes enough data to do so safely
If you need to return a comprehensive A2A response (e.g., data parts, rich metadata, multiple
artifacts), use a2a_outbox rather than relying on the streaming fallback.
3. Summary
- Read
ctx.a2a_inboxto access the inbound A2A Task, Message, and metadata. - Prefer SDK helpers or normal ADK event content when you want to populate the shared runtime response buffer.
- Optionally set
a2a_outboxinevent.actions.state_deltaas anA2AOutboxinstance for full-fidelity A2A responses. - Yield partial events for real-time text streaming.