Skip to main content
Palyra implements an autonomous learning pipeline that extracts structured knowledge, user preferences, and repeatable procedures from agent-user interactions. This system, referred to as the Reflection Pipeline, operates as a background workload to ensure that the “Natural Language Space” of chat transcripts is distilled into the “Code Entity Space” of Durable Facts, Workspace Documents, and Preferences.

​
Learning Pipeline Architecture

The learning process is decoupled from the main message loop to minimize latency. It follows a “Phase 6” lifecycle where successful runs trigger background reflection tasks.

​
Data Flow & Component Interaction

The following diagram illustrates how a completed run is transformed into learned entities. Learning Lifecycle: From Transcript to Fact Sources: crates/palyra-daemon/src/application/learning.rs#41-123, crates/palyra-daemon/src/application/learning.rs#125-185, crates/palyra-daemon/src/background_queue.rs#11-26

​
Learning Candidates & Confidence Thresholds

Palyra classifies learned information into three primary candidate types. Each type has configurable confidence thresholds measured in Basis Points (BPS), where 10,000 BPS equals 100% confidence.
Candidate TypeDescriptionKey Logic
DurableFactLong-term factual information intended for Workspace Documents.build_compaction_learning_candidates
PreferenceUser-specific stylistic or operational constraints.build_preference_candidates
ProcedureSequences of tool calls or steps that recur across sessions.build_procedure_candidates

​
Threshold Configuration

The LearningRuntimeConfig struct defines the behavior of the autonomous agent: Sources: crates/palyra-daemon/src/gateway/runtime.rs#85-96, crates/palyra-daemon/src/application/learning.rs#160-185

​
Reflection Background Workload

Reflection is managed by the background_queue.rs subsystem. When an orchestrator run completes, schedule_post_run_reflection is called.
  1. Sampling: To manage costs, the system uses sampling_percent to decide if a run should be reflected upon. crates/palyra-daemon/src/application/learning.rs#48-64
  2. Cooldown: A cooldown_ms prevents excessive background tasks for the same session. crates/palyra-daemon/src/application/learning.rs#82-88
  3. Task Creation: A task of kind post_run_reflection is inserted into the orchestrator_background_tasks table. crates/palyra-daemon/src/application/learning.rs#90-120
  4. Execution: The poll_background_queue loop picks up the task and executes process_post_run_reflection_task, which uses the LLM to analyze the transcript and session compaction plan. crates/palyra-daemon/src/background_queue.rs#51-93
Sources: crates/palyra-daemon/src/background_queue.rs#31-44, crates/palyra-daemon/src/application/learning.rs#125-157

​
MemorySection UI Workflow

The Web Console provides a dedicated interface for managing the output of the learning pipeline. Memory UI to Daemon RPC Mapping

​
UI Features

Sources: apps/web/src/console/sections/MemorySection.tsx#104-180, crates/palyra-daemon/src/transport/http/handlers/console/memory.rs#11-95

​
Implementation Detail: Auto-Apply vs Manual Review

When a candidate is created, the daemon evaluates its confidence against the runtime configuration. 
// Logic within process_post_run_reflection_task
if record.confidence_bps >= learning_config.durable_fact_auto_write_threshold_bps {
    // Transition to approved and trigger side-effects immediately
    runtime_state.review_learning_candidate(LearningCandidateReviewRequest {
        candidate_id: record.candidate_id.clone(),
        decision: "approved".to_owned(),
        // ...
    }).await?;
}
If the confidence is between the min_confidence and auto_write thresholds, the record remains in a queued state, appearing in the MemorySection for human intervention. Sources: crates/palyra-daemon/src/application/learning.rs#189-205, crates/palyra-daemon/src/gateway/runtime.rs#151-166