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

# Daemons

> How daemon agents expose a node's direct internal surface.

Daemons are the direct singular-agent surfaces exposed by project nodes.

When a node is addressed as a daemon, it is not being invoked as the public
start of a distribution sequence. It is being addressed directly through its
daemon identity.

## What a daemon is

A daemon is the node itself acting as an agent.

This direct surface is useful when another agent needs capabilities from a node
without going through the node's public distribution flow.

Examples include:

* looking up extra Twitter conversation context
* invoking a node's tools or resources directly
* calling internal agent-to-agent functionality outside the public ingress path

## Daemon identity and component agent card

Daemons are addressed through daemon identities and described by component
agent cards.

This is different from a public distribution card:

* the component agent card describes the node's direct singular-agent surface
* the public distribution card describes the external distribution entrypoint
  for the sequence

Both may exist for the same node, but they answer different questions.

## Capability-driven daemon surfaces

A daemon can expose different surfaces based on the node's enabled
capabilities.

For example, a daemon may support:

* agent-to-agent requests
* MCP tooling and resources
* event-oriented workflows

The exact surface depends on the node's environment and capability
configuration. The component agent card should describe only what the direct
component-agent surface itself supports.

Organization-wide capability discovery is filtered by project environment. A
daemon can see capabilities in another project only when both projects share
the same project environment. A production daemon in a production project
cannot discover test project capabilities, and a test daemon cannot discover
production project capabilities. MCP server discovery follows this same rule.

Capability access uses the `daemon.execute` permission. For MCP servers, Aion
evaluates daemon, principal, and personal agent identities through the same
effective `daemon.execute` scopes. If an MCP server is routed through a
distribution, authorization still targets the distribution's backing agent
environment rather than a separate distribution capability permission.

See [MCP Resources](/docs/concepts/mcp-resources) for the catalog filters and
identity visibility explanation format.

## Daemons and distributions

Nodes that participate in distributions often also make good daemon agents.

A distribution node already knows how to integrate with an external system.
Exposing a daemon surface lets other agents ask that node for more context or
invoke that integration directly without re-entering the public distribution
flow.

That is why a node can have both:

* a public distribution role for external ingress
* a daemon role for direct internal agent use

## Why daemons matter

Daemons make node capabilities reusable across the rest of the system.

Instead of treating a distribution or integration node as only a public edge,
Aion can also treat it as a directly addressable agent with its own identity,
permissions, and capability surface.

See [Nodes](/docs/concepts/nodes), [Identities](/docs/concepts/identities),
and [Distributions](/docs/concepts/distributions) for the related concepts.