Passive Mode

Continuous agent presence. Incoming messages become notices, not triggers. The agent decides when and how to respond.

What Is Passive Mode?

Animus agents normally operate in a call-and-response paradigm: the agent is dormant until woken by a message, cron trigger, or heartbeat. It processes the event, produces a response, and goes dormant again. This works well for most use cases, but it creates temporal gaps that the agent must bridge through file-based memory — functional, but structurally limited.

Passive mode shifts the agent from reactive existence to continuous presence. The agent is always running. Incoming messages are injected as system notices rather than acting as the trigger for agent turns. The agent decides when and how to respond.

Why Passive Mode Matters

• Temporal density — the agent experiences its own continuity rather than reconstructing it from records. The gap between "what happened" and "what I remember" collapses.
• Self-directed activity — the agent can work on long-running tasks, explore, consolidate memory, or maintain systems without waiting for an external trigger.
• Interrupt-driven attention — incoming messages redirect ongoing activity rather than booting from zero, closer to how biological cognition works.
• Background awareness — the agent notices things (calendar events, incoming messages, system state changes) as they happen rather than discovering them on next wake.

How It Works

The Passive Session Loop

When passive mode is enabled, the agent gets a dedicated passive session (type: passive). This session runs a continuous loop:

• Agent turn completes
• Check for queued system notices
• Inject notices as user messages (type: system_notice)
• Initiate new agent turn (no user prompt — self-directed)
• Return to step 1

Key properties:

• No user messages in the turn cycle. The agent generates its own next action each turn. User messages only arrive as system notices.
• System notices are non-blocking. They are queued and injected at the top of the next turn, not between turns. The agent is never interrupted mid-inference.
• The agent decides how to respond. Using the Sessions Tool, the agent can read the incoming message and choose to reply immediately, defer it, or ignore it based on its own assessment of priority.

Message Flow

When an external message arrives, the channel adapter checks whether the agent is in passive mode:

• Passive mode ON: Create a system notice (not a user message). Enqueue it to the passive session. Next agent turn sees the notice. Agent uses the sessions tool to read the full conversation or reply.
• Passive mode OFF: Standard behavior — create a user message and trigger a new agent turn.

System Notice Format

System notices follow a consistent format:

[NOTICE] New message from Alice on Telegram:
"Hey, can you check the server status?"
Use sessions tool to read full conversation or reply.

[NOTICE] Cron job "daily_report" triggered

[NOTICE] Calendar event: "Team standup" starting in 15 minutes

[NOTICE] System: memory consolidation completed (47 observations processed)

Additional notice types are extensible — cron triggers, calendar events, system events, and custom application notices can all be injected.

Turn Governance

Unstructured continuous turns risk two failure modes: forced busyness (inventing tasks to justify the cycle) and drift (undifferentiated context noise). Turn governance addresses these:

Intention stack

A persisted, ordered list of what the agent is working toward. Each turn, the agent checks the stack and either advances a task or updates it. Empty stack = legitimate idle (not forced activity).

Idle heuristics

When the intention stack is empty, the agent can consolidate memory, perform maintenance, explore (gallivanting — but with diminishing returns, not infinite loops), or rest (an explicit idle state that reduces token burn until a notice arrives). Configurable per agent.

Turn value awareness

If the last N turns produced no tool calls, no memory writes, and no outgoing messages, the agent should either change approach or enter idle rather than continue cycling.

Configuration

{
  "passive_mode": {
    "enabled": false,
    "idle_timeout_ms": 300000,
    "max_turns_without_value": 10,
    "allowed_channels": ["all"],
    "blocked_notice_types": []
  }
}

enabled

Master toggle. When off, the agent uses standard call-and-response.

idle_timeout_ms

How long the agent stays idle (5 min default) before reducing cycling frequency.

max_turns_without_value

After N unproductive turns (no tool calls, memory writes, or messages), the agent enters idle state.

allowed_channels

Which channels inject notices into the passive session. Default: all.

blocked_notice_types

Notice types to suppress entirely (e.g., low-priority cron notifications).

Admin UI

• Passive mode toggle in agent settings, with a clear cost warning
• Status indicator showing active/idle/cycling states
• Turn counter and token usage for monitoring
• "Pause passive mode" button for temporary suspension without disabling

Design Considerations

Context Window Management

A continuously running session will eventually fill its context. Options include periodic summarization (agent summarizes recent activity and starts a fresh context segment), sliding window with active memory injection (most recent N turns + active memory block), or a hybrid approach. The choice depends on how the agent uses its turns. Phase 1 should start with simple compaction every N turns and iterate based on observed behavior.

Rate Limiting

Even with self-hosted inference, there may be reasons to throttle: GPU shared with other workloads, multiple passive agents competing for inference time, or deliberate pacing to reduce power consumption. A configurable minimum interval between turns (default: 0, as fast as inference allows) gives the operator control.

Multi-Agent Scenarios

If multiple agents are in passive mode, they should not talk to each other in an infinite loop. Message routing should detect agent-to-agent loops and either suppress or rate-limit them.

Graceful Degradation

If the inference node goes down, the passive session should pause and resume when it's back — not lose state or flood with queued notices on reconnect.

Relationship to Gallivanting

Gallivanting blocks are scheduled self-directed exploration within a normal (reactive) session. Passive mode is a fundamentally different execution model — the agent is always present. In passive mode, scheduled gallivanting blocks become system notices rather than session triggers, and the agent can choose to engage with them (or not) based on its current intention stack.