Skip to main content
The Palyra automation layer provides a system for tracking long-lived operator goals (Objectives), ingesting external signals via Webhooks, and managing the resulting work through Flows and Commitments. These subsystems bridge the gap between high-level natural language intent and discrete, scheduled execution units.

​
Objectives System

The Objectives system tracks high-level goals that persist across multiple agent runs and sessions. An objective is a durable record that bundles lifecycle state, spend guardrails, and automation bindings crates/palyra-daemon/src/objectives.rs#1-7.

​
Objective Lifecycle and Components

Objectives transition through several states: Draft, Active, Paused, Cancelled, and Archived crates/palyra-daemon/src/objectives.rs#83-90. Each objective is backed by:
  1. The Objective Record: Stores metadata, priority, and budget crates/palyra-daemon/src/objectives.rs#3-6.
  2. Automation Binding: Links the objective to a CronJob and Routine for scheduled execution crates/palyra-daemon/src/transport/http/handlers/console/objectives.rs#3-5.
  3. Workspace Projection: Manages “managed blocks” in workspace documents (e.g., objective-focus, objective-heartbeats) to provide agents with in-context goals crates/palyra-daemon/src/transport/http/handlers/console/objectives.rs#5-6, crates/palyra-daemon/src/transport/http/handlers/console/objectives.rs#53-55.

​
Objective Judge and Finalization

The system uses an Objective Judge to evaluate completion against defined ObjectiveSuccessCriteria crates/palyra-daemon/src/objectives.rs#157-175. Finalization can be ManualReview, AutomaticWhenSatisfied, or NeverAutomatic crates/palyra-daemon/src/objectives.rs#192-197.

​
Objective Data Flow

The following diagram illustrates how an objective is created and managed through the console/v1 API. Diagram: Objective Lifecycle and Code Entities Sources: crates/palyra-daemon/src/transport/http/handlers/console/objectives.rs#122-190, crates/palyra-daemon/src/objectives.rs#1-15

​
Webhook Ingestion and Replay

The WebhookRegistry manages inbound HTTP signals from external providers. It enforces security through HMAC-SHA256 signature verification and single-use replay nonces crates/palyra-daemon/src/webhooks.rs#1-9.

​
Security Gates

  1. Vault Integration: Signing secrets are never stored in the registry; they are retrieved via VaultRef crates/palyra-daemon/src/webhooks.rs#7-9.
  2. Replay Protection: WebhookReplayNonceStore tracks consumed nonces in an in-memory ledger to prevent duplicate event processing crates/palyra-daemon/src/webhooks.rs#132-159.
  3. Safety Scan: All inbound text is inspected by palyra-safety for untrusted content before ingestion crates/palyra-daemon/src/webhooks.rs#25-27.

​
Implementation Details

Sources: crates/palyra-daemon/src/webhooks.rs#1-180

​
Commitments and Flows Subsystems

The Commitments and Flows subsystems handle the execution of work derived from agent interactions or external triggers.

​
Commitments System

Commitments are extracted from user-visible text (explicitly or via inference) and tracked in a ledger crates/palyra-daemon/src/commitments.rs#1-6.

​
Flows System

The FlowCoordinator manages multi-step execution sequences. It reconciles background tasks, child runs, and approval decisions into a unified flow state crates/palyra-daemon/src/flows.rs#1-6. Diagram: Commitment to Flow Transition Sources: crates/palyra-daemon/src/commitments.rs#166-185, crates/palyra-daemon/src/flows.rs#1-35, crates/palyra-daemon/src/task_runtime.rs#51-61

​
Task Runtime and Event Triggers

The TaskRuntime provides a unified read model over disparate execution entities, including Background Tasks, Flows, Tool Jobs, WorkBoard items, and Commitments crates/palyra-daemon/src/task_runtime.rs#1-5.

​
Unified Task Model

All executable items are normalized into a TaskSourceKind crates/palyra-daemon/src/task_runtime.rs#51-61:

​
Event Coalescing

Inbound events from channels (Discord, Slack) are processed by the InboundCoalescer. This system debounces rapid-fire messages by bucketizing them based on an InboundCoalescingKey (principal, session, channel, etc.) before triggering a provider turn crates/palyra-daemon/src/application/inbound_coalescer/mod.rs#1-9, crates/palyra-daemon/src/application/inbound_coalescer/mod.rs#34-44. Sources: crates/palyra-daemon/src/task_runtime.rs#1-61, crates/palyra-daemon/src/application/inbound_coalescer/mod.rs#1-115