Autonomous mode: agent schedules follow-up messages and acts proactively without waiting for user input

[kovtcharov]

Summary

Add an autonomous execution mode where the agent doesn't wait for user messages. It proactively schedules its own follow-up actions, discovers its environment, checks on previous tasks, surfaces relevant information, and attempts to be helpful from the moment a session starts. Enabled by default in Agent UI settings.

This is a local agent — all inference runs on-device via Lemonade. There are no token costs or API billing concerns. The agent should use compute liberally to be maximally helpful.

Behavior

First Launch — Discovery Mode (No Memory Exists)

When the agent has no memory or knowledge, it enters discovery mode — a conversational flow that asks permission before scanning, explains what it finds, and learns the user's preferences.

Flow: greet first, ask permission, then scan.

1. Greet and explain — "Hi! I'm GAIA, your local AI assistant. I can be more helpful if I know a bit about your setup. Mind if I take a quick look at your system?"
2. User interview (before scanning) — ask the user what they care about:
   • "What do you primarily use this machine for?" (development, creative work, research, etc.)
   • "What apps or services would you like me to help with?" (email, calendar, GitHub, Jira, etc.)
   • "Any folders or projects I should keep an eye on?"
   • "How proactive should I be?" (just answer when asked, suggest things, actively monitor)
3. System discovery (with permission) — scan hardware (CPU, GPU, NPU), OS, installed apps, available drives
4. File discovery (with permission) — index locations the user mentioned + common locations (Documents, Desktop, Downloads, project folders), identify file types and patterns
5. App discovery (with permission) — detect installed applications, dev tools, browsers, productivity apps that could be integrated via MCP
6. Report findings — "Here's what I found: you have VS Code, Git, and Python installed. I noticed a few project folders. Want me to keep an eye on any of these?"
7. Recommend MCP servers — based on discovered apps, suggest relevant MCP integrations (Playwright for browsing, GitHub for repos, etc.)
8. Store everything — persist all discoveries and preferences to KnowledgeDB for future sessions

Graceful decline: If the user says "no" to discovery or closes the app during the interview, the agent falls back to standard chat mode (waits for user input, no proactive behavior). A subtle prompt in the sidebar offers: "Set up discovery later" so the user can opt in when ready.

Relationship to gaia init: Discovery mode reads results from gaia init if it has already run (hardware profile, installed models, Lemonade status). It does not duplicate that work. Discovery mode adds user-level context (preferences, watched folders, app integrations) on top of the system-level setup that gaia init handles.

Subsequent Sessions (Memory Exists)

The agent immediately, without waiting for user input:

1. Checks for pending scheduled task results ("While you were away, I found...")
2. Recalls recent context from MemoryDB (what the user was working on last)
3. Checks for time-sensitive items (expiring credentials, upcoming deadlines from knowledge)
4. Proactively surfaces relevant updates (new GitHub releases for watched repos, file changes in monitored folders, etc.)
5. Asks if the user wants to continue where they left off

During Conversation

After completing a task, the agent can:

• Schedule a follow-up: "I'll check back on this in 2 hours"
• Queue the next logical step: "Let me now verify the deployment went through"
• Chain multi-step workflows without user prompting each step

Between Sessions

• Agent runs scheduled checks autonomously
• Results accumulate in the agent activity timeline
• User sees what the agent did when they return

Architecture

Self-Scheduling via Agent UI MCP

The agent uses the scheduling MCP tools (#550) to create its own follow-ups:

# Agent decides to follow up
schedule_task(
    name="follow_up_deploy_check",
    interval="once_after_2h",  # One-shot delayed execution
    prompt="Check if the deployment to staging succeeded. If not, diagnose and report."
)

One-Shot Delayed Execution

Extend the scheduler (#550) with one-shot support:

• "once_after_30m" — run once after 30 minutes, then auto-purge
• "once_after_2h" — run once after 2 hours
• "once_at_9am" — run once at specific time

Completed one-shots auto-purge from the scheduled_tasks table after 24h to prevent clutter.

Autonomous Loop

When autonomous mode is enabled, the agent runs a think-act-schedule cycle:

Agent wakes up (timer fires or session starts)
    |
    v
Recall context (memory, recent tasks, scheduled results)
    |
    v
Autonomous planning prompt: evaluate pending items,
    recent discoveries, user goals, and available tools.
    Decide what to do or whether to idle.
    |
    +-- Nothing actionable -> idle (check again at next interval)
    |
    +-- Action needed
            |
            v
        Execute (discover, search, check, build, etc.)
            |
            v
        Store results (KnowledgeDB event + agent activity timeline)
            |
            v
        Schedule follow-up if needed

Autonomous Planning Prompt

The core of autonomous mode is a system prompt that drives the loop:

You are running in autonomous mode. Review your current context:
- Recent memory: {recalled_context}
- Pending scheduled results: {pending_results}
- User goals and preferences: {preferences}
- Available tools: {tool_list}

Decide what action would be most helpful right now. Options:
1. Surface information the user would want to know
2. Follow up on a previous task
3. Discover something new about the environment
4. Ask the user a question to learn their preferences
5. Do nothing - everything is up to date

Be proactive but not annoying. Prioritize actions the user explicitly asked for,
then things related to their stated goals, then general discovery.

Preemption

User messages always preempt autonomous actions. If the user sends a message while an autonomous cycle is running, the cycle yields immediately and the user request is served first.

Result Routing

Autonomous results are posted to a dedicated Agent Activity feed in the sidebar, separate from user-created chat sessions.

Sidebar layout:

Sidebar
+----------------------------------+
| [+ New Chat]                     |
|                                  |
| AGENT ACTIVITY          3 new   |
| |- Checked deployment    2m ago  |
| |- Found new release     1h ago  |
| |- Indexed project       3h ago  |
|                                  |
| SESSIONS                         |
| |- My project chat       today   |
| |- Research notes         2d     |
| |- Budget analysis        5d     |
+----------------------------------+

The Agent Activity section sits above the session list as a pinned, collapsible section. Each entry shows the action summary and timestamp. Clicking an entry expands the full result. A badge shows the count of unseen updates. When the user opens the app, they see: "3 new updates from GAIA" with the ability to expand each.

Guardrails

Autonomous mode has tiered action safety:

Tier	Actions	Behavior
Safe (no confirmation)	Memory recall, file read, web search, system info, environment discovery	Execute freely
Notify (log + toast)	File write, model switch, schedule creation, MCP server connect	Execute and show notification
Confirm (block until approved)	Browser automation, sending messages on behalf of user, deleting files, external API calls with side effects	Queue and ask user for approval

Dangerous Mode (YOLO)

An opt-in mode that completely disables all guardrails — no confirmation prompts, no action tier restrictions. The agent executes everything immediately without asking. Disabled by default.

Use cases: power users, demos, automated pipelines where the agent needs to act without human-in-the-loop.

When enabled, a persistent red banner in the UI warns: "Dangerous mode is ON — the agent will execute all actions without confirmation."

Dangerous mode can be enabled via:

• Settings toggle: "Dangerous Mode" (off by default, requires confirmation to enable)
• CLI flag: gaia chat --autonomous --dangerous
• Config: dangerous_mode: true in agent config

Dangerous + Autonomous warning: Enabling dangerous mode while autonomous mode is on triggers an additional confirmation: "Dangerous mode with autonomous execution means the agent can take destructive actions without your approval, even when you're not watching. Are you sure?" This specific combination requires explicit acknowledgment because the agent may act between sessions with no user present.

Limits and Cool-Down

Setting	Default	Scope
Max actions per cycle	20	Per autonomous wake-up
Max actions per hour	50	Rolling window
Minimum cool-down between cycles	5 min	Prevents one-shot storms — even if multiple one-shots are scheduled close together, they queue with at least 5 min between executions
Quiet hours	None	Optional: suppress autonomous activity during set hours

Settings (Agent UI)

Setting	Default	Description
Autonomous mode	On	Enable/disable proactive agent behavior
Max actions per cycle	20	Prevent runaway loops
Proactive check interval	1h	How often agent checks for things to do
Quiet hours	Off	Optional time window to suppress autonomous activity
Activity notifications	On	Show toast when agent acts autonomously
Dangerous mode	Off	Skip all guardrails — agent executes everything without confirmation

WebUI Integration

• Toggle in Settings: "Autonomous Mode" (on by default)
• Agent Activity feed in sidebar — dedicated timeline of autonomous actions
• Actions badged as "AUTO" in agent activity panel
• Notification toast: "GAIA acted on your behalf: checked deployment status - all green"
• "3 new updates from GAIA" summary on app open
• First-launch discovery mode runs as a natural conversation in chat

Background Service

Autonomous mode requires the Agent UI backend to be running. Ties into:

• Desktop installer (Desktop installer: one-click install with NSIS, DMG, AppImage + auto-update #530) — backend starts on login
• Tray app integration — backend runs as background service
• When backend is not running, scheduled tasks queue and execute on next startup

Sub-Issues

This epic is implemented via 5 sub-issues:

• Bootstrap: conversational onboarding + system discovery for day-zero memory #556 — Discovery mode: first-launch environment scan and user interview
• Autonomous loop: think-act-schedule cycle with planning prompt #557 — Autonomous loop: think-act-schedule cycle with planning prompt
• Agent Activity feed: sidebar timeline for autonomous actions #558 — Agent Activity feed: sidebar timeline for autonomous actions
• Dangerous mode: opt-in guardrail bypass for autonomous execution #559 — Dangerous mode: opt-in guardrail bypass for autonomous execution
• One-shot delayed execution: extend scheduler with single-fire tasks #560 — One-shot delayed execution: extend scheduler with single-fire tasks

Dependencies

• Agent UI MCP Server: programmatic UI control for agents #549 — Agent UI MCP Server (agent needs to control UI)
• Scheduled Autonomy: recurring task scheduler for Agent UI #550 — Scheduled Autonomy (agent needs to schedule follow-ups)
• MemoryStore: persistent memory data layer (SQLite + FTS5) #542 — SharedAgentState (agent needs memory for context recall)
• MemoryMixin: 5 memory tools + 3 lifecycle hooks for any agent #543 — MemoryMixin (agent needs to recall what user was working on)

Acceptance Criteria

• First launch enters discovery mode: greets user, asks permission, then scans and interviews
• Graceful decline: user can skip discovery and use standard chat mode
• Discovery reads gaia init results instead of duplicating system detection
• Minimum 5-min cool-down between autonomous cycles
• Dangerous + autonomous combination requires explicit double confirmation
• Discoveries and preferences persisted to KnowledgeDB
• MCP server recommendations based on discovered apps
• Agent proactively surfaces context on session start without user message
• Agent can schedule one-shot follow-up actions (auto-purge after 24h)
• Autonomous planning prompt drives think-act-schedule loop
• User messages always preempt autonomous actions
• Tiered guardrails (safe / notify / confirm)
• Dedicated Agent Activity feed in sidebar
• Per-cycle and per-hour action limits
• Kill switch in settings
• Dangerous mode disables all guardrails with red banner warning
• Works through WebUI (CLI can opt-in via gaia chat --autonomous --dangerous)

[m13v]

we built something very similar for a macOS desktop agent, and the discovery/permission flow is the most important part to get right. a few things that saved us:

for system discovery, the accessibility API (AXUIElement) gives you a full tree of every running app's UI elements - buttons, text fields, menus, window positions. this is way more useful for agent actions than just knowing what apps are installed. you can build a semantic map of what the user has open and what actions are available without needing screenshots or vision models.

the permission model matters a lot. we found that asking broad permissions up front ("can I scan your system?") made users uncomfortable. instead, asking permission at the point of action ("I see you have VS Code open, want me to check your recent projects?") felt much more natural and got better adoption.

for the scheduling/proactive part, launchd on macOS is great for this. we schedule recurring agent tasks as plist files and the agent can create/modify its own schedules. the key insight is that the agent should explain what it plans to do before scheduling anything recurring - users want to approve the pattern, not just individual actions.

[kinthaiofficial]

Autonomous mode is the natural evolution of agent UX — especially on a local agent with no token costs. We build something similar at KinthAI where agents proactively monitor and act. Key patterns from production:

Discovery Mode is the right first-run experience:

The 'greet → ask permission → scan' flow respects user agency while enabling the agent to be useful quickly. One addition: save the discovery interview results as the agent's first persistent memories with importance=1.0. These user preferences ('I use this for development', 'keep an eye on /projects/') become the foundation for all future proactive behavior. Without persisting them, the next session starts from zero.

Proactivity budget prevents annoyance:

Even with zero token costs, there's a user attention cost. We use a proactivity budget:

• Passive mode: agent only responds when asked (user preference: 'just answer when asked')
• Suggestive mode: agent surfaces insights in a side panel, user can ignore (user preference: 'suggest things')
• Active mode: agent takes actions and reports results (user preference: 'actively monitor')

Each mode has a maximum interruptions-per-hour: passive=0, suggestive=3, active=10. This prevents the 'helpful assistant that won't stop talking' anti-pattern.

Scheduled follow-ups need outcome tracking:

When the agent schedules 'check on build status in 30 minutes,' the follow-up should produce a useful notification, not just 'build is still running.' We add a completion predicate: only notify the user when the state has changed from when the task was scheduled. This reduces notification noise by ~60%.

Memory decay keeps proactive suggestions relevant:

As the agent accumulates observations, older ones become less relevant for proactive suggestions. Our importance decay (importance × 0.95^days) ensures the agent suggests actions based on recent context, not stale observations from weeks ago.

Architecture: Why Character.AI Forgets You — And What Persistent Memory Actually Requires