> ## 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.
# Why Use Aion?
> The Control Plane for Agentic Networks
Aion is useful when your system is no longer just "an agent with a prompt" and starts looking like a
network of agents, tools, identities, event sources, and external interfaces that need to work
together under one model.
## Key Benefits
### Expand Your Agents' Surface Area
Aion allows the same agent to be distributed across multiple categories and channels
without requiring a separate implementation for each. The network harness and control
plane are designed so that adding additional channels only takes minutes.
* Aion normalizes communication to A2A so direct calls, agent-to-agent hops, and
external ingress can share the same request model.
* Distribution endpoints allow you to securely bridge your agents to external networks
and systems without maintaining separate integrations.
* Aion provides more than just social channels. Distributions are available to expose A2A endpoints for
agent-native messaging, MCP for structured tool access, and other utilities like the Aion Chat CLI.
One boundary and permission model to control access between your agents and the outside world.
### Tooling for Everyone on Your Team
Aion is not just a runtime. It comes with different operating surfaces for developers, operators,
and non-technical teammates.
Aion Server
Aion Chat CLI
Aion Control Plane Chat
* Developers can run the open-source Aion server locally with `aion serve`, expose multiple agents
behind one proxy, and interact with them from the command line using `aion chat`.
* The control plane gives teams a browser-based environment for working with projects and communicating
with agents without requiring everyone to work from local source code.
* Because these interfaces all sit on the same integrated agent model, teams don't need separate platforms
for development, operations, and end-user access.
### Framework Freedom
Choose your own agent orchestration framework.
The Aion open-source server and network harness follow idiomatic IO patterns for each supported framework
so that your implementations won't require external dependencies.
For example, in LangGraph, you can simply receive a HumanMessage and respond with an AIMessage through
your graph state's messages property.
The harness does the rest. And if you want more sophistication, our framework-specific SDKs provide
additional features and capabilities.
LangGraph
Google ADK
* The Python SDK supports LangGraph and ADK today, and the broader platform is designed around
agents that expose A2A rather than agents rewritten into a proprietary runtime.
* The `aion.yaml` configuration allows you to register agents, mount custom HTTP applications,
and optionally proxy a local MCP server without forcing your application logic into a new architecture.
* That separation keeps agent implementation independent from network infrastructure, so you can
evolve frameworks and packaging choices without rebuilding the whole application shell.
### Manage Large Deployments of Agents
Once you move beyond one or two agents, the problem isn't just token management. Network topology,
deployment, routing, identity, permissions, policies, and operations all need to be managed.
The Aion control plane provides a unified interface for managing these concerns.
GitHub Deployment
Versioning
Agent Identities
Permissions
* Deploy agents to our cloud directly from GitHub and handle version management through release channels.
* Agents are not treated as anonymous functions. They have identity, permissions, discovery
semantics, and explicit capability surfaces, which makes larger deployments easier to reason
about and operate.
* Enable everyone in your organization to create digital twins to maximize their availability and impact.
### Agent-Driven Application Architectures
Aion is most useful when agents are part of the application architecture itself, not just a feature
attached to an existing app.
* Compose multi-agent systems in the Project Editor, connect middleware and terminal agents in
sequences, and expose them to other networks through A2A, MCP, and direct integrations.
* Build applications as graphs of specialized components with routing, identity, permissions, and
interoperability handled at the platform layer.
* Let agents communicate with each other as peers instead of funneling every interaction through a
single orchestrator.
## When Aion May Be Overkill
Aion is probably not the right first choice if:
* You only need a single standalone chatbot or assistant with no multi-agent topology.
* Your application does not need inter-agent communication, discovery, or network bridging.
* You don't plan to deploy large numbers of agents or distribute them widely within or outside of your organization.
* A simple request-response API plus a task queue already solves the whole problem cleanly.
## A Useful Mental Model
If you think of a traditional application as a set of services connected by APIs, queues, and
identities, Aion applies that same systems mindset to agentic software.
Instead of treating the agent as UX to another application, Aion treats it as the core
primitive. That becomes valuable once your organization deploys hundreds of agents, each
needing communication, composition, discovery, and interoperability to be provided at the platform layer.
If that matches your use case, continue to [What is Aion?](/docs/what-is-aion) for the concrete model and
examples.
