Skip to main content
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 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, Identities, and Distributions for the related concepts.