Skip to main content
Behaviors are the executable building blocks behind project nodes. A behavior describes what a node can do. It is the implementation that eventually handles requests, produces side effects, and exposes capability-specific surfaces such as agent-to-agent, MCP, or event handling.

​
Behavior sharing and inclusion

When adding a behavior to a project, Aion lists behaviors that are available for that selected project. Behavior visibility follows the deployment sharing scope:
  • Project behaviors are available only inside their owning project.
  • Organization behaviors are available to other projects in the organization only when the projects use the same project environment name, such as Production or Staging.
  • Aion behaviors are globally available and are not constrained by project environment names.
This environment-name rule keeps production projects from accidentally pulling in staging or development organization-shared behavior deployments. System behaviors, such as platform-provided prompt or starter behaviors, use the global Aion scope when they should be available everywhere.

​
Behaviors and nodes

A node in the project editor is not just a behavior. A node combines several concerns:
  • The behavior implementation itself
  • Environment-specific configuration
  • One or more identities
  • A set of enabled capabilities
That distinction matters because the same behavior can appear in different roles depending on how the node is configured. For example, the same underlying behavior may:
  • act as a terminal agent in a distribution sequence
  • act as middleware in front of another agent
  • expose a direct daemon agent surface for out-of-band requests

​
Capability declarations

Behaviors participate in capabilities, but the effective surface is determined by configuration. A behavior may support:
  • agent-to-agent communication
  • MCP tools or resources
  • event ingestion or emission
  • distribution-specific integrations
Whether those capabilities are actually published depends on the node’s environment, identities, distribution role, and any public routing constraints.

​
Behaviors in public and daemon roles

One of the most important distinctions is between a node’s public distribution role and its direct daemon role. When a node is used as part of a distribution sequence, its behavior may run as middleware or as the terminal agent behind a public entrypoint. In that case, external requests flow through the distribution’s public surface. The same node may also expose a direct component-agent surface. That surface may be addressed through the node’s daemon identity and is described by the component agent card, not the distribution’s public distribution card.

​
Why this separation exists

Keeping behavior separate from identity and distribution makes it possible to:
  • reuse the same implementation in different environments
  • publish only the capabilities a route can actually support
  • let a node participate in a sequence while still exposing a direct daemon API
See Agent Abstraction, Agent Environments, Identities, and Daemons for the surrounding model.