bot0 Proactive Engine Architecture
Overview
The Proactive Engine is an addon layer that sits on top of the reactive system. While the reactive system waits for user commands, the proactive engine observes, thinks, and acts autonomously ā within boundaries the user defines.
Key principle: The proactive engine learns what it can do autonomously through user approvals over time. It starts by asking for everything, then builds confidence.
š Related documentation:
- Core System Architecture ā Reactive system foundation
- Task Queue Manager ā How tasks are scheduled and dispatched to daemons
Relationship to Reactive System
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā ā
ā PROACTIVE ENGINE (addon) ā
ā ā
ā Observes ā Thinks ā Acts (or Asks) ā
ā ā
ā Generates tasks, suggestions, notifications ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā
ā Feeds tasks into
ā¼
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā ā
ā REACTIVE SYSTEM (core) ā
ā ā
ā Desktop āā Daemon āā Hub āā Other Daemons ā
ā ā
ā Executes tasks ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
The proactive engine creates tasks. The reactive system executes tasks.
Tasks flow through the Task Queue Manager (in Hub) which handles prioritization, scheduling, and daemon dispatch. See bot0-queue-manager.md for details.
The Goal System
Every proactive engine instance has a north star goal set by the user.
yaml
goal: primary: "Run the business efficiently and grow revenue to $1B" sub_goals: - "Keep customers happy (NPS > 50)" - "Ship features faster (cycle time < 1 week)" - "Reduce manual work (automate repetitive tasks)" - "Stay informed (no surprises)" constraints: - "Never spend more than $1000 without approval" - "Never send external emails without review" - "Never delete production data"
The proactive engine evaluates every potential action against this goal:
- "Does this action move toward the goal?"
- "Does this violate any constraints?"
- "Do I have permission to do this autonomously?"
Core Components
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā PROACTIVE ENGINE ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā DATA LAYER ā ā
ā ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā Data Syncs ā ā Memory ā ā Triggers ā ā ā
ā ā ā (Sheets) ā ā Store ā ā Registry ā ā ā
ā ā ā ā ā ā ā ā ā ā
ā ā ā ā¢ Revenue ā ā ā¢ User prefs ā ā ā¢ Webhooks ā ā ā
ā ā ā ā¢ Analytics ā ā ā¢ Approvals ā ā ā¢ Events ā ā ā
ā ā ā ā¢ GitHub ā ā ā¢ Context ā ā ā¢ Thresholds ā ā ā
ā ā ā ā¢ Gmail ā ā ā¢ Insights ā ā ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā OBSERVATION LAYER ā ā
ā ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā Watchers ā ā Schedules ā ā Ingestors ā ā ā
ā ā ā ā ā ā ā ā ā ā
ā ā ā Poll syncs ā ā Cron jobs ā ā Process ā ā ā
ā ā ā at intervals ā ā Time-based ā ā webhook ā ā ā
ā ā ā ā ā triggers ā ā events ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā ā
ā ā Batching ā¢ Debouncing ā¢ Rate Limiting ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā THINKING LAYER ā ā
ā ā ā ā
ā ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā ā
ā ā ā EVALUATOR ā ā ā
ā ā ā ā ā ā
ā ā ā Input: Batch of observations ā ā ā
ā ā ā ā ā ā
ā ā ā Process: ā ā ā
ā ā ā 1. What changed? What's significant? ā ā ā
ā ā ā 2. Does this relate to the goal? ā ā ā
ā ā ā 3. What actions are possible? ā ā ā
ā ā ā 4. Do I have permission for each action? ā ā ā
ā ā ā 5. What's the confidence level? ā ā ā
ā ā ā ā ā ā
ā ā ā Output: List of potential actions with confidence scores ā ā ā
ā ā ā ā ā ā
ā ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā ā
ā ā ā ā
ā ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā ā
ā ā ā PERMISSION CHECKER ā ā ā
ā ā ā ā ā ā
ā ā ā ā¢ Check user's explicit rules ā ā ā
ā ā ā ā¢ Check learned permissions (past approvals) ā ā ā
ā ā ā ā¢ Check constraints ā ā ā
ā ā ā ā ā ā
ā ā ā Output: autonomous | needs_approval | forbidden ā ā ā
ā ā ā ā ā ā
ā ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ACTION LAYER ā ā
ā ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā EXECUTE ā ā ASK ā ā STORE ā ā ā
ā ā ā ā ā ā ā ā ā ā
ā ā ā Autonomous ā ā Request ā ā Log insight ā ā ā
ā ā ā action via ā ā approval via ā ā for later ā ā ā
ā ā ā reactive ā ā preferred ā ā reference ā ā ā
ā ā ā system ā ā channel ā ā ā ā ā
ā ā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāā ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Data Sources
1. Data Syncs (Sheets)
Your existing sync sheets ā structured data pulled from external systems.
yaml
data_syncs: - name: "revenue" source: "stripe" frequency: "every 1 hour" sheet_id: "sheet_abc123" schema: - mrr: number - customers: number - churn_rate: number - name: "github_activity" source: "github" frequency: "every 15 minutes" sheet_id: "sheet_def456" schema: - open_prs: number - merged_today: number - issues_created: number - name: "user_analytics" source: "mixpanel" frequency: "every 6 hours" sheet_id: "sheet_ghi789" schema: - dau: number - signups: number - activation_rate: number
2. Memory Store
The agent's knowledge base ā learnings, context, user preferences.
yaml
memory: user_preferences: communication_channel: "telegram" quiet_hours: "22:00-08:00" digest_time: "09:00" learned_permissions: - action: "archive_newsletter_emails" approved: true learned_from: "approval_2024_01_15" times_executed: 47 - action: "send_external_email" approved: false requires: "explicit_approval" context: current_focus: "Series A fundraising" key_contacts: - name: "Sarah Chen" role: "Sequoia partner" relationship: "warm intro from Mike" insights: - date: "2024-01-20" observation: "Revenue drops correlate with support ticket spikes" confidence: 0.8
3. Triggers Registry
Events that can wake up the proactive engine.
yaml
triggers: webhooks: - name: "github_pr_opened" source: "github" event: "pull_request.opened" - name: "stripe_payment_failed" source: "stripe" event: "payment_intent.payment_failed" - name: "slack_mention" source: "slack" event: "app_mention" thresholds: - name: "revenue_drop" sync: "revenue" condition: "mrr_change < -10%" - name: "high_churn" sync: "revenue" condition: "churn_rate > 5%" - name: "pr_stale" sync: "github_activity" condition: "pr_age > 3 days"
4. Schedules
Time-based triggers.
yaml
schedules: - name: "morning_briefing" cron: "0 9 * * 1-5" # 9am weekdays action: "generate_daily_briefing" - name: "weekly_review" cron: "0 18 * * 5" # 6pm Friday action: "generate_weekly_summary" - name: "sync_check" cron: "*/30 * * * *" # Every 30 min action: "check_all_syncs"
Observation Layer: Batching & Rate Limiting
The proactive engine does NOT spin up on every event. It batches and debounces.
Batching Strategy
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā OBSERVATION BATCHING ā
ā ā
ā Events arrive: ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā ā āāā ā ā ā āāāāā ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā Batched into windows: ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā [ batch 1 ] [ batch 2 ] [ batch 3 ] [ batch 4 ] ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā ā ā ā
ā ā¼ ā¼ ā¼ ā¼ ā
ā Evaluate Evaluate Evaluate Evaluate ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Configuration
yaml
batching: # Default batch window default_window: "30 seconds" # Max events before forced processing max_batch_size: 100 # Per-source overrides sources: github: window: "5 minutes" debounce: true # Only process latest state stripe: window: "immediate" # Payment events are urgent email: window: "2 minutes" analytics: window: "1 hour" # No rush rate_limits: # Max evaluations per time period evaluations_per_minute: 10 evaluations_per_hour: 100 # Max actions per time period actions_per_minute: 5 actions_per_hour: 50 # Cooldown after action action_cooldown: "30 seconds"
Debouncing
For data syncs, we often only care about the final state:
Email sync events:
10:00:01 - New email (id: 1)
10:00:02 - New email (id: 2)
10:00:03 - New email (id: 3)
10:00:04 - Email read (id: 1)
10:00:05 - New email (id: 4)
After debounce (30s window):
ā "4 emails received, 1 read" (single evaluation)
NOT:
ā 5 separate evaluations
Permission System
How Permissions Work
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā PERMISSION RESOLUTION ā
ā ā
ā Action: "Send email to customer about renewal" ā
ā ā
ā Step 1: Check explicit rules ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā Rule: "Never send external emails without approval" ā
ā Result: NEEDS_APPROVAL ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā Action: "Archive newsletter email" ā
ā ā
ā Step 1: Check explicit rules ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā No matching rule. ā
ā ā
ā Step 2: Check learned permissions ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā Found: User approved this 47 times, never rejected. ā
ā Result: AUTONOMOUS ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā Action: "Delete production database" ā
ā ā
ā Step 1: Check constraints ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā Constraint: "Never delete production data" ā
ā Result: FORBIDDEN ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Permission Levels
| Level | Meaning | Example |
|---|---|---|
AUTONOMOUS | Do it without asking | Archive newsletters |
NOTIFY | Do it, but tell user | Auto-responded to support ticket |
NEEDS_APPROVAL | Ask before doing | Send email to investor |
FORBIDDEN | Never do this | Delete production data |
Learning Permissions
yaml
# When user approves an action approval_event: action_type: "respond_to_support_ticket" action_details: ticket_type: "billing_question" response_template: "standard_billing_faq" approved: true timestamp: "2024-01-20T10:30:00Z" # System learns learned_permission: action_pattern: "respond_to_support_ticket WHERE ticket_type = billing_question" confidence: 0.3 # Low after 1 approval approvals: 1 rejections: 0 # After 10 approvals of similar actions learned_permission: action_pattern: "respond_to_support_ticket WHERE ticket_type = billing_question" confidence: 0.95 # High confidence approvals: 10 rejections: 0 auto_approve: true # Now autonomous
Confidence Thresholds
yaml
permission_thresholds: # Minimum approvals before auto-approve considered min_approvals: 5 # Minimum confidence for autonomous action autonomous_threshold: 0.9 # If rejection ratio exceeds this, always ask rejection_threshold: 0.1 # Time decay - recent approvals weight more decay_half_life: "30 days"
User Communication
Channel Preferences
yaml
user_communication: preferred_channel: "telegram" fallback_channels: - "email" - "desktop_notification" quiet_hours: enabled: true start: "22:00" end: "08:00" timezone: "America/New_York" urgency_overrides: critical: true # Always notify, even in quiet hours high: false medium: false low: false batching: enabled: true digest_time: "09:00" # Non-urgent items batched to morning digest channel_preferences: telegram: - urgent_alerts - approval_requests email: - daily_digest - weekly_summary desktop: - suggestions - insights
Message Types
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā MESSAGE TYPES ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā APPROVAL REQUEST ā ā
ā ā ā ā
ā ā "Revenue dropped 23%. Should I create a detailed report?" ā ā
ā ā ā ā
ā ā [Yes, create report] [Yes, also draft email] [No, ignore] ā ā
ā ā ā ā
ā ā ā User response feeds back into permission learning ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā NOTIFICATION (action taken) ā ā
ā ā ā ā
ā ā "ā Archived 12 newsletter emails" ā ā
ā ā "ā Auto-responded to 3 support tickets" ā ā
ā ā ā ā
ā ā [Undo] [Don't do this anymore] ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā SUGGESTION (low priority) ā ā
ā ā ā ā
ā ā "I noticed you've had 3 meetings about pricing this week. ā ā
ā ā Want me to create a summary doc?" ā ā
ā ā ā ā
ā ā ā Shown in daily digest or when user opens Desktop ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā INSIGHT (background) ā ā
ā ā ā ā
ā ā Stored silently, surfaced when relevant. ā ā
ā ā ā ā
ā ā User: "Why did signups drop?" ā ā
ā ā Agent: "I've been tracking this. I noticed that..." ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Self-Evolution Actions
The proactive engine can modify itself ā within limits.
Actions the Engine Can Take on Itself
yaml
self_evolution_actions: memory: - action: "memory.create" description: "Store new insight or context" autonomous: true - action: "memory.update" description: "Update existing memory" autonomous: true - action: "memory.delete" description: "Remove outdated memory" autonomous: false # Ask first - action: "memory.reorganize" description: "Restructure memory for better retrieval" autonomous: true data_syncs: - action: "sync.create" description: "Create new data sync" autonomous: false # Ask first (costs money, API access) - action: "sync.update" description: "Modify sync frequency or schema" autonomous: false - action: "sync.pause" description: "Temporarily pause a sync" autonomous: true # Can auto-pause if errors - action: "sync.delete" description: "Remove a data sync" autonomous: false triggers: - action: "trigger.create" description: "Create new trigger" autonomous: false - action: "trigger.update" description: "Modify trigger conditions" autonomous: false - action: "trigger.disable" description: "Disable a trigger" autonomous: true # Can auto-disable if noisy schedules: - action: "schedule.create" description: "Create new scheduled task" autonomous: false - action: "schedule.update" description: "Modify schedule timing" autonomous: false - action: "schedule.skip" description: "Skip next occurrence" autonomous: true
Example: Engine Improves Itself
Observation:
"Email sync trigger fired 500 times today but only 3 were relevant"
Evaluation:
"This trigger is too noisy. It's wasting compute and my attention."
Action (autonomous):
1. Update trigger to filter by sender/subject patterns
2. Store insight: "Most irrelevant emails are from no-reply@ addresses"
3. Notify user: "I refined the email trigger to reduce noise by 95%"
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Observation:
"User asks about competitor pricing every week"
Evaluation:
"User cares about competitor pricing. No sync exists for this."
Action (needs approval):
"I noticed you ask about competitor pricing often.
Should I create a sync that tracks their pricing page weekly?"
[Yes, create sync] [No thanks]
Processing Pipeline
Full Flow
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā PROACTIVE PROCESSING PIPELINE ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 1. COLLECT ā ā
ā ā ā ā
ā ā Data syncs poll at their frequencies ā ā
ā ā Webhooks arrive and queue ā ā
ā ā Schedules fire at their times ā ā
ā ā ā ā
ā ā All events go into OBSERVATION QUEUE ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 2. BATCH ā ā
ā ā ā ā
ā ā Wait for batch window (30s default) ā ā
ā ā OR max batch size reached (100 events) ā ā
ā ā OR urgent event arrives (bypass batching) ā ā
ā ā ā ā
ā ā Debounce: collapse multiple events into final state ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 3. EVALUATE ā ā
ā ā ā ā
ā ā Load context: goal, memory, recent actions ā ā
ā ā ā ā
ā ā For each observation in batch: ā ā
ā ā - Is this significant? ā ā
ā ā - Does it relate to the goal? ā ā
ā ā - What actions are possible? ā ā
ā ā ā ā
ā ā Output: List of potential actions ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 4. CHECK PERMISSIONS ā ā
ā ā ā ā
ā ā For each potential action: ā ā
ā ā - Check constraints (forbidden?) ā ā
ā ā - Check explicit rules ā ā
ā ā - Check learned permissions ā ā
ā ā - Assign: AUTONOMOUS | NOTIFY | NEEDS_APPROVAL | FORBIDDEN ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 5. EXECUTE / ASK / STORE ā ā
ā ā ā ā
ā ā AUTONOMOUS actions: ā ā
ā ā ā Send to reactive system (Hub ā Daemon) ā ā
ā ā ā Optionally notify user after ā ā
ā ā ā ā
ā ā NOTIFY actions: ā ā
ā ā ā Execute, then notify user ā ā
ā ā ā User can undo or disable ā ā
ā ā ā ā
ā ā NEEDS_APPROVAL actions: ā ā
ā ā ā Send approval request via preferred channel ā ā
ā ā ā Wait for response ā ā
ā ā ā If approved: execute + learn permission ā ā
ā ā ā If rejected: learn rejection ā ā
ā ā ā ā
ā ā FORBIDDEN actions: ā ā
ā ā ā Log attempt ā ā
ā ā ā Do nothing ā ā
ā ā ā ā
ā ā Low-confidence insights: ā ā
ā ā ā Store in memory for later ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā ā
ā ā¼ ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā 6. LEARN ā ā
ā ā ā ā
ā ā Record action taken and outcome ā ā
ā ā Update permission confidence scores ā ā
ā ā Store insights for future context ā ā
ā ā ā ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Implementation in Bytespace
apps/
āāā bytespace-api/
ā āāā api/
ā ā āāā ...
ā ā
ā āāā proactive/
ā ā āāā engine.ts # Main orchestrator
ā ā ā
ā ā āāā data/
ā ā ā āāā syncs.ts # Data sync management
ā ā ā āāā memory.ts # Memory store
ā ā ā āāā triggers.ts # Trigger registry
ā ā ā
ā ā āāā observation/
ā ā ā āāā queue.ts # Observation queue
ā ā ā āāā batcher.ts # Batching logic
ā ā ā āāā watchers.ts # Sync polling
ā ā ā āāā ingestors.ts # Webhook processing
ā ā ā
ā ā āāā thinking/
ā ā ā āāā evaluator.ts # Main evaluation logic
ā ā ā āāā goal.ts # Goal checking
ā ā ā āāā permissions.ts # Permission resolution
ā ā ā
ā ā āāā action/
ā ā ā āāā executor.ts # Autonomous execution
ā ā ā āāā approval.ts # Approval request handling
ā ā ā āāā notify.ts # User notification
ā ā ā
ā ā āāā learning/
ā ā āāā permissions.ts # Permission learning
ā ā āāā insights.ts # Insight storage
ā ā
ā āāā jobs/
ā āāā sync-runner.ts # Runs data syncs
ā āāā scheduler.ts # Runs scheduled tasks
ā āāā batch-processor.ts # Processes observation batches
Database Schema (Additions)
sql
-- Goals CREATE TABLE proactive_goals ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), primary_goal TEXT, sub_goals JSONB, constraints JSONB, created_at TIMESTAMP, updated_at TIMESTAMP ); -- Data Syncs CREATE TABLE data_syncs ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), name TEXT, source TEXT, frequency TEXT, config JSONB, last_run TIMESTAMP, status TEXT, created_at TIMESTAMP ); -- Memory Store CREATE TABLE proactive_memory ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), category TEXT, -- 'preference', 'context', 'insight', 'learned_permission' key TEXT, value JSONB, confidence FLOAT, created_at TIMESTAMP, updated_at TIMESTAMP, expires_at TIMESTAMP ); -- Triggers CREATE TABLE proactive_triggers ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), name TEXT, source TEXT, event_type TEXT, conditions JSONB, enabled BOOLEAN DEFAULT true, created_at TIMESTAMP ); -- Schedules CREATE TABLE proactive_schedules ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), name TEXT, cron TEXT, action TEXT, config JSONB, enabled BOOLEAN DEFAULT true, last_run TIMESTAMP, next_run TIMESTAMP, created_at TIMESTAMP ); -- Learned Permissions CREATE TABLE learned_permissions ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), action_pattern TEXT, approvals INTEGER DEFAULT 0, rejections INTEGER DEFAULT 0, confidence FLOAT DEFAULT 0, auto_approve BOOLEAN DEFAULT false, last_used TIMESTAMP, created_at TIMESTAMP ); -- Observation Queue CREATE TABLE observation_queue ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), source TEXT, event_type TEXT, payload JSONB, priority TEXT, -- 'urgent', 'normal', 'low' batch_id UUID, processed BOOLEAN DEFAULT false, created_at TIMESTAMP ); -- Action Log CREATE TABLE proactive_actions ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), trigger_id UUID, action_type TEXT, action_details JSONB, permission_level TEXT, -- 'autonomous', 'notify', 'approved', 'rejected' outcome TEXT, created_at TIMESTAMP );
Open Questions
-
Evaluation model: Use same LLM as reactive system? Smaller/faster model for frequent evaluations?
-
Cost control: How to limit LLM calls in proactive loop? Cache similar evaluations?
-
Multi-user/team: How do team permissions work? Can team admin set constraints for all members?
-
Conflict resolution: What if two triggers fire conflicting actions?ā Partially resolved: Task Queue Manager handles priority-based scheduling. See bot0-queue-manager.md. -
Audit trail: How detailed should action logging be for compliance?
-
Rate limiting proactive actions:ā Resolved: Task Queue Manager enforces per-user rate limits and backpressure. See bot0-queue-manager.md.
Summary
| Component | Purpose |
|---|---|
| Goal | North star that guides all decisions |
| Data Syncs | Structured data from external systems |
| Memory | Context, preferences, learned permissions |
| Triggers | Events that wake up the engine |
| Schedules | Time-based triggers |
| Batching | Prevents overwhelming with events |
| Evaluator | Decides what to do |
| Permissions | Determines autonomy level |
| Learning | Gets smarter over time |
| Self-Evolution | Can improve its own configuration |
The proactive engine turns bot0 from a tool you use into an agent that works for you.