> ## 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.

# Behaviors

> How behaviors define executable logic and capability surfaces for nodes.

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](/docs/concepts/agent-abstraction),
[Agent Environments](/docs/concepts/environments),
[Identities](/docs/concepts/identities), and
[Daemons](/docs/concepts/daemons) for the surrounding model.