/always-on-agent-applications — What Persistence + Memory Actually Unlocks
You are helping someone figure out what to build with an always-on AI agent that has episodic memory. This is the "so what?" skill — the architecture exists, the inputs are flowing, now what does it actually do that a stateless chatbot can't?
Decision Points
1. Always-On vs Session-Based Decision Tree
Evaluate task requirements:
├─ Task needs memory across sessions?
│ └─ No → Use session-based agent (cheaper, simpler)
│ └─ Yes ↓
├─ Task benefits from proactive behavior?
│ └─ No → Use scheduled agent with memory
│ └─ Yes ↓
├─ [Persistence ROI] > [Infrastructure Cost]?
│ └─ No → Start with session-based, upgrade later
│ └─ Yes ↓
├─ Domain narrow enough for quality memory?
│ └─ No → Narrow scope (meetings-only, code-only)
│ └─ Yes → Build always-on agent
ROI Calculation:
- Persistence ROI = (Task frequency × Time saved per task × User value per hour)
- Infrastructure Cost = (Server cost + Memory storage + Development time)
If ROI > 3x cost: Build always-on
If ROI 1-3x cost: Start session-based, prove value first
If ROI < 1x cost: Use existing tools
2. Application Category Selection
User asks "What should I build?":
├─ Primary workflow is coding?
│ └─ Yes → Developer Companion pattern
│ └─ No ↓
├─ Primary need is meeting/communication overhead?
│ └─ Yes → Personal Chief of Staff pattern
│ └─ No ↓
├─ Primary goal is learning/knowledge work?
│ └─ Yes → Learning Journal pattern
│ └─ No ↓
├─ Focus is health/habits tracking?
│ └─ Yes → Health Observer pattern (high safety sensitivity)
│ └─ No → Project Orchestrator or Ambient Intelligence
3. Scope Boundaries Decision
User proposes multi-domain agent:
├─ Is this their first persistent agent?
│ └─ Yes → Force single vertical (pick strongest ROI)
│ └─ No ↓
├─ Do they have >6 months development time?
│ └─ No → Single vertical only
│ └─ Yes ↓
├─ Can they define success metrics for each domain?
│ └─ No → Reduce scope until they can
│ └─ Yes → Allow multi-domain with staged rollout
4. Proactive Behavior Calibration
Configure agent interruption frequency:
├─ User work style is deep focus blocks?
│ └─ Yes → Batch notifications, respect focus signals
│ └─ No ↓
├─ User explicitly requests high-touch assistance?
│ └─ Yes → Allow real-time interruptions with relevance threshold
│ └─ No ↓
├─ Default to: 80% reactive, 15% passive proactive, 5% active proactive
Failure Modes
1. Hallucinated Memory Syndrome
Symptoms: Agent confidently references conversations or events that never happened
Detection Rule: If agent claims specific quotes/dates/facts but can't provide exact source timestamp
Root Cause: Poor memory boundaries between retrieved context and generated responses
Fix: Implement strict memory citation requirements - agent must link every claim to specific memory entry with timestamp
2. Memory Pollution Cascade
Symptoms: Agent performance degrades over time, contradictory information in responses
Detection Rule: If agent gives conflicting advice about same topic within 7 days without acknowledging change
Root Cause: Low-quality observations accumulating faster than valuable signal
Fix: Implement memory hygiene: relevance scoring, automated compaction, user-triggered memory cleanup
3. Cost Creep Explosion
Symptoms: Monthly bills increasing 30%+ without proportional value increase
Detection Rule: If cost-per-useful-interaction rises above baseline by 50%+ over 30 days
Root Cause: Agent over-processing low-value inputs (notifications, spam, automated emails)
Fix: Input filtering pipeline, memory access budgets, proactive cost monitoring with auto-throttling
4. Scope Creep Paralysis
Symptoms: Agent tries to handle everything, excels at nothing, user abandons after 2 weeks
Detection Rule: If agent has >5 distinct application verticals without clear success metrics for each
Root Cause: Building "general assistant" instead of focused tool
Fix: Force single-vertical start, require graduation criteria before expansion
5. Privacy Violation Drift
Symptoms: Agent accidentally shares sensitive information across contexts
Detection Rule: If agent mentions personal/work details in wrong context (work info in personal chat)
Root Cause: Memory boundaries not aligned with user privacy expectations
Fix: Context isolation, explicit memory compartmentalization, regular privacy audits
Worked Examples
Example: Building Developer Companion Agent
Scenario: Software engineer wants agent to help with code reviews and PR descriptions
Step 1 - Scope Definition
- User: "I want an AI that helps me code better"
- Apply Decision Tree: Coding workflow = Developer Companion pattern
- Narrow scope: "PR description generation only" (not full coding assistant)
Step 2 - ROI Calculation
- Task frequency: 3 PRs/day × 5 days = 15 PRs/week
- Time saved: 5 min per PR description = 75 min/week = 65 hours/year
- User value: $150/hour × 65 hours = $9,750/year
- Infrastructure cost: ~$50/month = $600/year
- ROI = 16x → Build always-on agent
Step 3 - Memory Strategy
- Core memory: Current feature branch, last 5 commits, recent conversations about code changes
- Recall memory: PR templates user prefers, reviewer feedback patterns, project coding standards
- Archival: Historical PRs, team communication style, project decisions and rationale
Step 4 - Trigger Design
triggers:
- git_push_to_feature_branch: Draft PR description
- pr_opened: Enhance description with context
- code_review_received: Log feedback patterns for future
Step 5 - Quality Gates
- PR descriptions include actual rationale (not generic summaries)
- Agent references specific commits/files mentioned
- 80% of generated descriptions require <2 minutes editing
- Agent correctly identifies when PR spans multiple concerns
What novice would miss: Starting with "AI coding assistant for everything"
What expert catches: Focusing on single high-value workflow (PR descriptions) where persistence creates clear advantage over stateless solutions
Quality Gates
Application design is complete when all conditions are met:
NOT-FOR Boundaries
Do NOT use this skill for:
- Building the memory architecture → Use
always-on-agent-architecture instead
- Designing input feeds and triggers → Use
always-on-agent-inputs instead
- Safety, privacy, and cost concerns → Use
always-on-agent-safety instead
- General agent patterns and loops → Use
agentic-patterns instead
- Evaluating AI safety risks → Use
ai-safety-engineer instead
- Technical infrastructure decisions → Use
systems-architecture instead
Delegate to other skills when user asks:
- "How do I store episodic memory?" →
always-on-agent-architecture
- "What data should my agent watch?" →
always-on-agent-inputs
- "Is this safe/private?" →
always-on-agent-safety
- "How do I build agent loops?" →
agentic-patterns