feat: Proactive Autonomy Loop

[lsm]

Purpose

Transform NeoKai from a purely reactive system (waiting for user input) to a proactive autonomous agent that identifies and executes work independently. This is essential for AGI-level autonomy because:

• Self-directed work: Discovering and addressing issues without explicit requests
• Continuous improvement: Maintaining and improving the codebase proactively
• Opportunity detection: Identifying beneficial changes that users might not think to request
• Idle productivity: Using downtime productively

Without proactive autonomy, NeoKai requires constant human direction and cannot operate independently.

---

Current State

NeoKai is purely reactive:

• Waits for user messages to trigger action
• No background monitoring or analysis
• No self-initiated task discovery
• Idle when no active user request

Current: User → Request → NeoKai → Response → Wait for next request

Proposed: NeoKai continuously monitors, identifies opportunities, acts autonomously

---

Proposed Approach

Phase 1: Background Monitoring System

1. Monitoring Infrastructure

   interface Monitor {
     id: string;
     name: string;
     description: string;
     checkInterval: Duration;
     lastCheck: Date;
     status: 'active' | 'paused' | 'disabled';
   }
   
   interface MonitorResult {
     monitorId: string;
     timestamp: Date;
     findings: Finding[];
     actions: RecommendedAction[];
   }

2. Built-in Monitors

   const builtinMonitors = {
     // Code Quality
     testHealth: {
       check: () => analyzeTestHealth(),
       triggers: ['test_failure_spike', 'coverage_decline']
     },
     
     dependencyHealth: {
       check: () => analyzeDependencies(),
       triggers: ['security_vulnerability', 'major_update_available']
     },
     
     codebaseHealth: {
       check: () => analyzeCodebase(),
       triggers: ['complexity_spike', 'duplication_increase']
     },
     
     // Project Hygiene
     staleBranches: {
       check: () => findStaleBranches(),
       triggers: ['branches_older_than_30_days']
     },
     
     documentationDrift: {
       check: () => detectDocDrift(),
       triggers: ['code_changed_docs_unchanged']
     }
   };

Phase 2: Task Discovery Engine

1. Discovery Strategies

   interface TaskDiscovery {
     // Pattern-based discovery
     detectPatterns(): Promise<DiscoveredTask[]>;
     
     // Anomaly-based discovery
     detectAnomalies(): Promise<DiscoveredTask[]>;
     
     // Opportunity-based discovery
     detectOpportunities(): Promise<DiscoveredTask[]>;
     
     // Learning-based discovery
     applyLearnedPatterns(): Promise<DiscoveredTask[]>;
   }

2. Task Categories

   type DiscoveredTaskCategory = 
     | 'maintenance'      // Dependencies, cleanup, refactoring
     | 'quality'          // Test coverage, lint fixes
     | 'security'         // Vulnerability patches
     | 'performance'      // Optimization opportunities
     | 'documentation'    // Doc updates, examples
     | 'developer_experience'; // DX improvements

3. Task Prioritization

   interface PrioritizationFactors {
     urgency: number;      // How time-sensitive
     impact: number;       // How beneficial
     effort: number;       // How much work
     risk: number;         // How risky
     userAlignment: number; // How aligned with user preferences
   }

Phase 3: Autonomy Levels

1. Configurable Autonomy

   type AutonomyLevel = 
     | 'suggest_only'     // Only suggest, never auto-execute
     | 'low_risk_only'    // Auto-execute only low-risk tasks
     | 'medium_risk'      // Auto-execute medium-risk, ask for high
     | 'high_autonomy';   // Auto-execute almost everything
   
   interface AutonomyConfig {
     level: AutonomyLevel;
     excludedCategories: DiscoveredTaskCategory[];
     maxConcurrentTasks: number;
     requireApprovalAbove: {
       effortThreshold: number;
       riskThreshold: number;
     };
     quietHours: TimeRange[];  // Don't run proactive tasks during these times
   }

2. Risk Assessment

   interface RiskAssessment {
     riskLevel: 'low' | 'medium' | 'high' | 'critical';
     factors: {
       reversible: boolean;
       affectsProduction: boolean;
       requiresTesting: boolean;
       hasRollbackPlan: boolean;
       touchesCriticalPath: boolean;
     };
     mitigationOptions: string[];
   }

Phase 4: Execution & Reporting

1. Execution Framework

   interface ProactiveExecution {
     // Validate task is still relevant
     validate(task: DiscoveredTask): Promise<boolean>;
     
     // Execute with safeguards
     execute(task: DiscoveredTask): Promise<ExecutionResult>;
     
     // Report to user
     report(result: ExecutionResult): Promise<void>;
   }

2. Reporting Mechanisms

   • Activity feed: "NeoKai automatically fixed 3 lint errors"
   • Summary notifications: "While you were away, NeoKai..."
   • Dashboard: Overview of proactive actions taken
   • Review queue: Actions requiring user review

3. User Override

   • Pause proactive behavior anytime
   • Undo recent proactive actions
   • Configure what's allowed
   • Provide feedback on actions

Phase 5: Self-Maintenance

1. NeoKai Self-Care

   const selfMaintenanceTasks = {
     cleanOldMemories: {
       description: "Archive or remove outdated memories",
       schedule: 'weekly'
     },
     optimizeDatabase: {
       description: "Run VACUUM and analyze on SQLite",
       schedule: 'weekly'
     },
     validateConfigurations: {
       description: "Ensure all configs are valid",
       schedule: 'daily'
     },
     updateKnowledge: {
       description: "Refresh learned patterns and preferences",
       schedule: 'daily'
     }
   };

---

Technical Considerations

Resource Management

• Monitoring CPU/memory impact
• Throttling background tasks
• Respecting user activity (don't compete for resources)

Notification Strategy

• Don't spam users with every action
• Aggregate similar actions
• Smart timing for notifications
• User-configurable notification preferences

Conflict Avoidance

• Don't modify files user is actively editing
• Coordinate with ongoing sessions
• Handle race conditions gracefully

Learning User Preferences

• What types of tasks does user appreciate?
• When does user want proactive behavior?
• What risk level is acceptable?

---

Success Metrics

1. Value Delivered: User-reported value of proactive actions
2. False Positive Rate: % of proactive tasks that were unnecessary
3. User Satisfaction: Rating of proactive behavior
4. Efficiency Gain: Time saved by proactive actions

---

Implementation Roadmap

1. Phase 1: Basic monitoring infrastructure
2. Phase 2: Task discovery engine (suggest_only mode)
3. Phase 3: Configurable autonomy levels
4. Phase 4: Full execution framework
5. Phase 5: Self-maintenance capabilities

---

Questions for Discussion

1. What's the right default autonomy level?
2. How to prevent proactive actions from conflicting with user work?
3. Should proactive tasks create git commits automatically?
4. How to handle situations where proactive action causes problems?

---

Part of the AGI-Level Autonomy initiative