Skip to main content
The Gateway and Orchestration Engine is the core execution supervisor of the Palyra daemon. It manages the lifecycle of agentic “Runs,” handles gRPC streaming communication with clients, and orchestrates the complex loop between Large Language Models (LLMs), tool execution, and human-in-the-loop approvals.

GatewayRuntimeState

The GatewayRuntimeState is the central shared state object for the gateway. It acts as a facade over the various subsystems required for orchestration, including the JournalStore, AgentRegistry, ChannelRouter, and ModelProvider crates/palyra-daemon/src/gateway.rs#75-82. Key responsibilities include:

Configuration Snapshots

The engine operates using GatewayRuntimeConfigSnapshot, which defines operational limits such as MAX_TAPE_ENTRIES_PER_RESPONSE and budget constraints for tool execution crates/palyra-daemon/src/gateway/runtime.rs#36-55. Sources: crates/palyra-daemon/src/gateway.rs#1-110, crates/palyra-daemon/src/gateway/runtime.rs#35-164

The Run State Machine

Every interaction in Palyra is encapsulated in a Run. The RunStateMachine governs the lifecycle of these runs, ensuring they move through valid states.
StateDescription
PendingInitial state before execution starts.
InProgressThe run is actively processing (LLM is generating or tool is executing).
DoneSuccessful completion of the run.
CancelledExecution stopped due to user request or timeout.
FailedTerminal state following an unrecoverable error.
Runs transition via RunTransition events (e.g., StartStreaming, Complete, Cancel) crates/palyra-daemon/src/application/run_stream/orchestration.rs#197-202. Sources: crates/palyra-daemon/src/orchestrator.rs#26-28, crates/palyra-daemon/src/application/run_stream/orchestration.rs#106-143

Agentic Execution Loop

The orchestration engine follows a “Route → LLM → Tool → Approval” loop. This process is primarily managed in orchestration.rs and provider_events.rs.

Execution Flow Diagram

1. Message Routing

When a message arrives via RouteMessage, the ChannelRouter determines which agent should handle the input based on pairings and session context crates/palyra-daemon/src/gateway.rs#50-54.

2. LLM Interaction

The engine prepares the prompt via prepare_model_provider_input, which injects relevant memories from the JournalStore and current session state crates/palyra-daemon/src/application/run_stream/orchestration.rs#15-17.

3. Tool Dispatch & Approval Loop

If the LLM requests a tool call:
  1. Policy Check: The engine checks ToolCallPolicySnapshot. If the tool is marked as sensitive, it triggers an ApprovalPromptRecord crates/palyra-daemon/src/gateway.rs#78-81.
  2. Approval: The run enters a waiting state until a client provides an ApprovalDecision via the ApprovalsService crates/palyra-daemon/src/gateway.rs#57-59.
  3. Execution: Once approved, execute_tool_call runs the tool (often in a Wasm or Tier-C sandbox) crates/palyra-daemon/src/gateway.rs#78-79.
Sources: crates/palyra-daemon/src/application/run_stream/orchestration.rs#1-100, crates/palyra-daemon/src/gateway.rs#23-82, crates/palyra-daemon/src/journal.rs#57-71

RunStream gRPC Endpoint

The RunStream endpoint in gateway.proto is the primary bi-directional interface for real-time agent interaction.

Data Flow and Persistence

Key Functions

Tape and Event Sequencing

Every event emitted in a RunStream is recorded in the “Tape”—an append-only log of a specific run’s events. The engine tracks tape_seq to ensure clients receive events in the correct order even if they reconnect crates/palyra-daemon/src/application/run_stream/orchestration.rs#111-135. Sources: crates/palyra-daemon/src/application/run_stream/orchestration.rs#106-202, crates/palyra-daemon/src/gateway.rs#84-110, crates/palyra-daemon/src/journal.rs#63-70