Skip to main content
The palyrad daemon is the central hub of the Palyra ecosystem. It hosts the gateway runtime, model provider adapters, tool execution backends, and the durable journal in a single process crates/palyra-daemon/src/lib.rs#1-10. It manages the entire lifecycle of agent interactions, from inbound message routing to iterative tool execution and post-run learning.

System Hub: GatewayRuntimeState

The core of the daemon is the GatewayRuntimeState. This structure acts as the shared coordinator for all transport surfaces (gRPC, HTTP, and QUIC), providing a unified interface to the underlying subsystems crates/palyra-daemon/src/gateway/runtime.rs#1-12.

Subsystem Interconnection

The daemon organizes its logic into several major domains that interact through the gateway runtime:

Daemon Entity Map

The following diagram illustrates how high-level architectural concepts map to specific code entities within the palyra-daemon crate. Sources: crates/palyra-daemon/src/lib.rs#14-27, crates/palyra-daemon/src/gateway/runtime.rs#1-12, crates/palyra-daemon/src/application/mod.rs#1-5

Major Subsystems

The daemon’s functionality is partitioned into specialized subsystems. Detailed documentation for each can be found in their respective child pages.

Gateway Runtime and Session Lifecycle

The gateway manages OrchestratorSessionRecord and RunLifecycleState. It handles inbound message admission via the InboundCoalescer and ensures that sessions are resolved and cleaned up properly crates/palyra-daemon/src/gateway/runtime.rs#7-12.

Agent Loop and Run Orchestration

The AgentRunLoopState drives the iterative process of prompting a model, parsing tool calls, and feeding results back. This loop is recorded on an append-only Tape for determinism and auditability crates/palyra-daemon/src/application/run_stream/orchestration.rs#1-15.

Journal Store and Audit System

The JournalStore is a SQLite database operating in WAL mode. It implements a SHA-256 hash-chain to ensure that every JournalEventRecord is tamper-evident. It also handles sensitive data redaction before persistence crates/palyra-daemon/src/journal.rs#1-20.

Transport Layer: HTTP, gRPC, and QUIC

The daemon exposes multiple interfaces. The Axum-based HTTP router serves the Web Console and Admin APIs, while gRPC services handle high-performance communication for tools and remote workers crates/palyra-daemon/src/transport/http/router.rs#25-38.

Request Flow: Natural Language to Code Execution

This diagram traces the path of a user request from the “Natural Language Space” (an inbound message) through the internal “Code Entity Space” until a tool is executed. Sources: crates/palyra-daemon/src/application/mod.rs#47-48, crates/palyra-daemon/src/application/run_stream/orchestration.rs#3-9, crates/palyra-daemon/src/tool_protocol.rs#6-11

Security and Governance

The daemon enforces a “deny-by-default” security posture. Every tool call is gated by decide_tool_call, which evaluates the request against Cedar policies crates/palyra-daemon/src/tool_protocol.rs#4-5. Security-relevant invariants, such as execution limits and resource cleanup (e.g., stale PID files, browser sessions), are managed centrally within the gateway hub crates/palyra-daemon/src/gateway.rs#9-11. Sources: crates/palyra-daemon/src/gateway.rs#1-11, crates/palyra-daemon/src/tool_protocol.rs#1-15

Child Pages