Always On Agent Applications

---
license: Apache-2.0
name: always-on-agent-applications
description: |
  What you can build and do with an always-on AI agent that has episodic memory. Covers concrete product ideas, workflows, emergent capabilities from persistence plus memory, and real-world examples of deployed persistent agents. Helps you go from "I have the architecture" to "here's what it actually does for me." Activate on: "what can an always-on agent do", "persistent agent use cases", "agent applications", "proactive agent ideas", "what to build with episodic memory", "always-on agent product", "personal AI assistant ideas", "/always-on-agent-applications". NOT for: building the architecture (use always-on-agent-architecture), designing inputs (use always-on-agent-inputs), safety and privacy (use always-on-agent-safety).
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - Task
  - WebSearch
  - WebFetch
metadata:
  category: AI & Agents
  tags:
    - always-on
    - applications
    - use-cases
    - proactive-agents
    - personal-assistant
    - product-ideas
    - emergent-capabilities
  pairs-with:
    - skill: always-on-agent-architecture
      reason: Architecture is the foundation; applications are what you build on it
    - skill: always-on-agent-safety
      reason: Every application has safety implications that must be designed in
    - skill: tech-entrepreneur-coach-adhd
      reason: Many applications are product opportunities worth evaluating
    - skill: agentic-patterns
      reason: Application design requires solid agent loop fundamentals
category: Agent & Orchestration
tags:
  - always
  - agent
  - applications
  - ai
  - workflow
  - design
---

# /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**
```yaml
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:

- [ ] Clear ROI calculation showing >3x cost benefit
- [ ] Single vertical scope with defined boundaries  
- [ ] Memory growth bounded with compaction strategy
- [ ] Proactive behavior frequency configured (<20% of total interactions)
- [ ] Success metrics defined and measurable
- [ ] User privacy boundaries explicitly mapped
- [ ] Cold start experience works without accumulated memory
- [ ] Kill switch implemented for user memory control
- [ ] Cost monitoring with auto-throttling thresholds set
- [ ] Graduation criteria defined for scope expansion

## 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`