Skip to main content
A Distribution Ion is the ingress boundary between one network endpoint and an Ion Sequence. When work arrives through an active Distribution, Aion normalizes it into its A2A request model, passes it through the connected Sequence, and carries any response back to the same network. Assigning an Aion Identity makes that endpoint one external presence of the Aion.

​
What a Distribution Ion connects

A Distribution Ion brings together the endpoint, application flow, and identities needed for one network: The network and backing runtime are required. The identity relationships depend on the network and the Distribution’s lifecycle state. The selected Distribution type defines the capabilities and configuration it supports. See Capabilities for the shared model.

​
Map an Aion to a network

When a Distribution uses a Personal or Principal Identity as its Principal Identity, the Distribution points to that Aion Identity. A linked service identity points in the other direction: the external account uses the Distribution to carry traffic for the Aion. In this example, the Twitter account is linked to the Bright Kindle endpoint. The Distribution maps that endpoint to the @bonnie Aion Identity, and the connected Behavior Ions implement its Sequence. Provider credentials belong to the Twitter integration rather than to the linked service identity. In Composer, open Identity on the Distribution Ion to select its linked service account, Principal Identity, and optional Daemon Identity. Composer showing the linked account, Principal Identity, and Daemon Identity for a Twitter Distribution Ion Use the same Principal Identity on another Distribution to make the same Aion available through another network without changing its Identity. Identity requirements vary by network and lifecycle state:
  • A Principal Identity is optional for most Distributions. An active Playground Distribution requires one.
  • Active Slack, X, and Voice Distributions require a linked account for their network.
  • A linked account identifies the provider account or address used by the transport. It does not become the Aion Identity.
A Distribution without a Principal Identity can still define an endpoint and runtime flow, but it is not mapped to an Aion Identity.

​
Configuration

Open Configuration on the Distribution Ion to control how its endpoint receives work. The available fields match the selected Distribution type, so each endpoint presents only the settings that apply to its network. The example below shows network-specific options for the same Twitter Distribution. Other Distribution types expose their own configuration. Composer showing network-specific configuration for a Twitter Distribution Ion Sync the Project after changing the Identity or configuration to apply the update.

​
Follow a request through a Distribution

Each Distribution anchors the Sequence used for its runtime flow. The connected Behavior Ions can enrich, route, reject, or answer the request. The Distribution remains the external entry and return point throughout the flow. An Ion’s position belongs to the Sequence, not its type. Aion does not require the final participant to use a separate terminal-Ion category.

​
A2A ingress and Agent Cards

A2A and Playground Distributions may publish an Agent Card describing their public agent capability and connected Sequence. The card does not describe every Ion in the Project. A Slack, X, or Voice Distribution remains an external integration without publishing an A2A Agent Card. Adding a Distribution to a Project graph does not automatically make it an A2A endpoint.

​
External ingress and internal runtime identity

A Distribution and a Daemon Identity sit on opposite sides of the application boundary:
  • The Distribution receives external traffic and represents the connected Sequence.
  • The Daemon Identity is the acting principal when the runtime calls another Aion, accesses resources, or uses metered services internally.
The Distribution is the outside world’s route into the Aion. The runtime uses its Daemon Identity for internal authorization, billing attribution, and application-to-application communication after work enters.

​
What to do next