Skip to main content
The Aion Python SDK runs an agent you have already written — a LangGraph graph, a Google ADK agent — as an A2A-compatible server. You keep writing the agent in your framework. The SDK supplies what surrounds it: the HTTP surface other systems call, routing across several agents, durable task state, and the connection to the Aion control plane. It stops at the runtime boundary. Hosting, identities, and deployment belong to the platform — see What is Aion?. GitHub: Terminal-Research/aion-python-sdk · PyPI: aionto-sdk

​
The shape of it

Point aion.yaml at the object your code exports:
Then start it:
That is the whole contract. agent.py holds a plain LangGraph graph or ADK agent and imports nothing from Aion; the adapter recognises what path resolves to — a graph, an agent, or a factory returning one — and wraps it. Adapter discovery is plugin-based, which is how further frameworks arrive without your agent changing. For the runnable version, follow a quickstart: LangGraph or ADK.

​
What runs

aion serve starts one process per configured agent, and a proxy in front of them:
  • Each agent runs in its own server process, with its own A2A endpoint.
  • The proxy fronts all of them at /agents/{agent_id}/{path}.
  • Clients call the proxy or an agent directly — both work.
  • Ports are allocated automatically unless you set them.
You never import the serving layer. The A2A server, the proxy, task storage, and the framework adapter have no import surface of their own: they are what aion serve starts around your agent.

​
What you import

Aion-aware code is optional, and this is what it offers: Which of these an environment has depends on the extra it installs. The aion command itself — serve, chat, logs — comes with the base install.

​
Where to go next

  1. Installation — extras, and which one your project needs.
  2. Quickstart (LangGraph) or Quickstart (ADK) — an agent running end to end.
  3. aion.yaml and Environment Variables — the configuration reference.