Memory & Learning

Pilot learns from every execution. The memory subsystem stores execution history, extracts patterns, and applies learned knowledge to future tasks.

Execution History

Every task execution is recorded in SQLite (~/.pilot/data/pilot.db). Each record captures:

Query execution history:

# Recent executions
pilot metrics summary
 
# Per-project breakdown
pilot metrics projects
 
# Daily trends
pilot metrics daily --days 30

Lifetime Metrics

Metrics persist across Pilot restarts. The dashboard’s “Lifetime” section shows cumulative totals:

• Tasks completed/failed — Total count across all time
• Tokens used — Cumulative input/output tokens
• Total cost — Estimated API spend

These values are computed from the executions table, not ephemeral session state.

# View lifetime summary in dashboard
pilot start --dashboard

Cross-Project Patterns

Pilot extracts patterns from successful executions and applies them across projects.

Pattern Types

Pattern Commands

# List all learned patterns
pilot patterns list
 
# Search patterns by keyword
pilot patterns search "authentication"
 
# View pattern statistics
pilot patterns stats

How Patterns Work

1. Extraction — After each execution, the pattern extractor analyzes changes
2. Storage — Patterns are saved with confidence scores (0.0–1.0)
3. Feedback — Success/failure outcomes adjust confidence
4. Pruning — Low-confidence patterns decay over time

Review Learning

After a PR is merged, Pilot processes review comments left by human reviewers to learn patterns for future tasks. The LearnFromReview() method fetches PR review comments via the GitHub API and categorizes them by review type.

• Approved reviews with text — Reviewer comments on approved PRs are treated as positive signals. Patterns used in the execution get a confidence boost.
• Changes-requested reviews — Reviewer feedback is extracted as anti-patterns, capped at 0.85 confidence to allow future override if conventions change.
• Empty approvals — Approval clicks without review text are skipped since there is no actionable signal to extract.

Learned patterns are injected into future execution prompts, so Pilot’s code quality improves over time based on your team’s feedback.

CI Failure Pattern Extraction

Since v2.52.0

Pilot extracts error patterns from CI failure logs and stores them for future reference. When a similar CI failure occurs later, the learned pattern is injected into the execution prompt to help prevent repeat failures.

Error Categories

How It Works

1. Detection — CI fails on a Pilot PR
2. Extraction — Failure logs are parsed for error patterns with category and frequency
3. Storage — Patterns are saved to the cross_patterns table with error type metadata
4. Injection — On future tasks in the same project, relevant CI failure patterns are included in the prompt

Self-Review Pattern Extraction

Since v2.48.0

Findings from Pilot’s self-review step feed back into the learning system. When self-review identifies an issue in generated code, ExtractFromSelfReview() captures it as a pattern so the same mistake is avoided next time.

This creates a feedback loop:

1. Generate — Pilot writes code for a task
2. Review — Self-review identifies issues (e.g., missing error handling)
3. Learn — Issues are stored as anti-patterns with source self_review
4. Prevent — Future prompts include the learned anti-patterns

Self-review patterns follow the same confidence scoring as other patterns — they decay if not reinforced and are pruned below the configured threshold.

Knowledge Graph

The knowledge graph stores relationships between concepts, files, and patterns.

Node Types

• pattern — Learned code/workflow patterns
• learning — Insights from debugging sessions
• decision — Architectural choices made
• pitfall — Common mistakes to avoid

Graph Structure

~/.pilot/data/knowledge.json

Nodes can have relations to other nodes, enabling queries like “what patterns relate to authentication?”

Adding Knowledge

Knowledge is added automatically during execution. graph.AddLearning() stores task metadata after each execution, while graph.GetRelated(keywords) queries related learnings across node relationships: task type → files → patterns → outcomes.

graph.AddLearning("JWT refresh flow", "Use sliding window...", metadata)
graph.AddPattern("error_handling", "Always wrap in try/catch", nil)
related := graph.GetRelated([]string{"auth", "jwt"})

Knowledge Store (Memories)

Separate from patterns, the knowledge store holds experiential memories with time-based decay.

Memory Types

Confidence Decay

Memories have a confidence score that decays over time if not reinforced:

• Initial: 1.0 (full confidence)
• Decay rate: Configurable per-day reduction
• Reinforcement: Using a memory increases confidence
• Pruning: Memories below threshold (default 0.1) are removed

This ensures stale knowledge doesn’t pollute future prompts while validated patterns remain available.

Temporal Pattern Relevance (Upcoming)

Per-project, per-task-type confidence tracking with recency decay. Patterns unused for 90+ days receive reduced weight, ensuring that stale conventions don’t override current practices.

Data Storage

~/.pilot/data/
├── pilot.db              # SQLite database (executions, patterns, metrics)
├── knowledge.json        # Knowledge graph nodes
└── global_patterns.json  # Cross-project pattern store

Database Tables

Performance Indexes

Since v2.47.0

The cross_patterns table has performance indexes on frequently queried columns: title, description, scope, and updated_at. These indexes speed up pattern lookups during prompt construction, especially for organizations with large pattern stores.

Configuration

Memory features are enabled by default. Configuration options:

# ~/.pilot/config.yaml
memory:
  enabled: true
  db_path: ~/.pilot/data  # SQLite location
  pattern_min_confidence: 0.3  # Minimum for prompt inclusion
  decay_rate: 0.02  # Confidence decay per day
  prune_threshold: 0.1  # Remove below this

Privacy

• All data is stored in ~/.pilot/data/
• No data is sent to external services (unless you configure webhooks)
• Patterns are scoped: project (single project), org (your projects), or global