MAXIM

Operating Modes

Processing States, Operational Modes, and Behavioral Strategies

Maxim doesn't have simple on/off modes. Its behavior emerges from three independent dimensions: how much it processes, how much authority it has, and what it focuses on. This decomposed architecture means you can combine states freely: an active robot can explore or assist; a passive robot can observe or reflect; and any configuration can be awake or sleeping.

The Decomposed Architecture
Processing States
Operational Modes
Strategies
Live Mode: The Embodied Runtime
Exploration Mode
Sleep Mode
Legacy Mode Names
Mode Switching
Initiative Calculation

The Decomposed Architecture

Design Rationale

Early Maxim used monolithic mode names like "live" and "exploration." This created a combinatorial explosion: every new capability needed its own mode. The decomposed architecture solves this by factoring behavior into three independent dimensions that combine freely.

Maxim's state is tracked by three independent axes:

This means sleep isn't a mode—it's a processing state. A sleeping robot retains its operational mode and strategy, reducing resource usage while maintaining configuration. When it wakes, it resumes exactly where it left off.

Processing State

Controls resource usage

awake sleep

Operational Mode

Determines action authority

passive active singularity

Strategy

Behavioral focus

observe explore research assist reflect learn

Processing States

awake Full Processing

Full LLM processing active
Strategy-driven behavior
All tools available (per mode constraints)
Default Network (orienting, social) enabled
Video and audio capture running

sleep Background Only

LLM processing skipped unless wake keyword detected
Background tasks: memory consolidation, model training, pattern extraction
Only respond tool available
Default Network disabled
Audio monitoring active (listens for wake keywords)

Wake keywords: "maxim", "hey maxim", "wake up", "hello". When detected, the robot wakes, actuates motors, and resumes its previous operational mode and strategy.

Operational Modes

Operational modes control how much authority Maxim has. They map directly to autonomy levels:

passive Planning Autonomy

Goal: Observe, understand, and propose actions without unilateral execution.

Max Initiative: 0.3 (mostly reactive)

Permission	Access
Sandbox (`.maxim_sandbox/`)	Always writable
CWD files	Read only, edits require approval
Code execution	Not allowed
Network	Allowed

Forbidden tools: execute_file, maxim_command, request_directory_change

Preferred strategies: observe, reflect, learn

active Supervised Autonomy

Goal: Execute tasks and take actions within defined boundaries.

Max Initiative: 0.7 (proactive within bounds)

Permission	Access
Sandbox	Full read/write
CWD files	Read + suggest edits (shown for approval)
Code execution	Requires approval
Network	Allowed

No forbidden tools (execution gated by approval)

Preferred strategies: assist, explore, research

singularity Full Autonomy

Goal: Operate with full autonomy, self-correcting and learning continuously.

Max Initiative: 1.0 (fully proactive)

Permission	Access
Sandbox	Full access including execution
CWD files	Full read/write/execute
Code execution	Allowed
Network	Allowed

No forbidden tools, full tool access

Safety and ethical constraints (Constitution) still apply unconditionally

Preferred strategies: explore, research, assist

Strategies

Strategies determine what Maxim focuses on within its current operational mode. Each strategy has keywords that trigger it, tool preferences, and a maximum initiative level.

Observe

Watch and understand without interfering. Process sensor data, track objects, record observations.

Initiative: 0.2 · Keywords: observe, watch, look, see

Avoids: write_file, execute_file, speak

Explore

Curiosity-driven discovery. Seek novel objects, research discoveries, track unusual phenomena.

Initiative: 0.8 · Keywords: explore, discover, investigate, curious

No avoided tools

Research

Deep information gathering. Multiple sources, synthesis, citations, fact vs interpretation.

Initiative: 0.7 · Keywords: research, investigate, study, analyze

Avoids: execute_file

Assist

Proactively help users. Anticipate needs, offer suggestions, complete tasks efficiently.

Initiative: 0.8 · Keywords: help, assist, support, task

No avoided tools

Reflect

Internal analysis and memory consolidation. Review memories, identify patterns, generate insights.

Initiative: 0.3 · Keywords: reflect, think, consider, review

Avoids: speak, track_target, execute_file

Learn

Incorporate feedback and demonstrations. Watch carefully, request feedback, incorporate corrections.

Initiative: 0.3 · Keywords: learn, train, teach, show me

Avoids: execute_file, maxim_command

Each strategy includes a context_prompt injected into the LLM system prompt, guiding the agent's reasoning style and behavior for that strategy.

Live Mode: The Embodied Runtime

What Is Live Mode?

Live mode is the full embodied runtime—the Maxim.live() method that orchestrates video capture, audio recording, motor control, and transcription while the agentic runtime makes decisions in parallel. It maps to active + assist strategy in the new architecture.

Live mode isn't just another behavioral configuration. It's the container that runs everything else. When you call maxim --mode live, it:

Configures logging (transcripts, video, audio, CLI input, vision events)
Creates thread synchronization primitives (media lock, stop event)
Spawns the agentic runtime in a background thread
Sets up frame observation and saving queues
Initializes audio capture and transcription
Awakens the robot hardware (motor init, video stream, audio stream)
Enters the main perception-action loop

The Live() Architecture

Pseudocode Maxim.live() │ ├── Agentic Runtime Thread │ └── Agent pipeline: Perception → Memory → Exec → Goal │ └── Tools executed via ToolRegistry │ ├── Video Capture Thread │ └── Camera → frame queues (observation + save) │ ├── Audio Capture Thread │ └── Microphone → Whisper transcription → transcript log │ ├── Video Writer Thread │ └── Consumes save queue → MP4 files │ ├── Motor Executor Thread │ └── Exclusive RobotController access │ └── Main Thread (observation loop) └── Process frames, run YOLO, compute salience/attention

Self-Evolving Intent

What makes live mode unique is the LiveModeIntent system. The agent can modify its own behavioral intent through reflection and experience, evolving how it behaves across sessions.

Immutable Constraint

No matter how much the agent evolves its intent, the primary goal is fixed: "Understand reality and help people." Initiative is bounded to [0.3, 0.8]. The agent can shape how it helps but not whether it helps.

The agent customizes live mode through four tools:

define_live_intent Modify behavioral parameters: context prompt extension, goal extension, initiative level (0.3–0.8), preferred/avoided strategies.

review_live_intent Inspect current intent, version history, and historical outcomes with success rates.

record_live_outcome Record action outcomes (action, success, context, reasoning). Keeps last 50 entries.

record_live_insight Record reflection insights from self-analysis. Keeps last 20 entries.

LiveModeIntent Structure

Data structure LiveModeIntent: context_prompt_extension: "" # Extends base context (doesn't replace) goal_extension: "" # Additional goal context max_initiative: 0.6 # Bounded [0.3, 0.8] preferred_strategies: [] # Strategy names to prefer avoid_strategies: [] # Strategy names to avoid historical_outcomes: [] # Last 50 action results reflection_insights: [] # Last 20 self-generated insights version: 1 # Increments on each modification modification_count: 0 # Total changes made

Intent is persisted to data/agents/MaximAgent/modes/live_intent.json and loaded on startup. The get_live_mode_with_intent() function merges the agent's customizations with the base live mode definition, extending (never replacing) the context prompt and goal.

Example: Intent Evolution Over Time

Day 1: Default intent. Agent responds to all interactions equally.

Day 3: After several successful face-tracking interactions, agent calls define_live_intent with goal_extension: "Prioritize human interaction".

Day 7: Agent records insight: "Morning interactions are more successful than evening." Adjusts preferred_strategies: ["assist"].

Day 14: Intent version 8. The agent has organically developed a preference for social interaction in mornings and quiet observation in evenings.

The robot shaped its own personality through experience. No human configured it.

Exploration Mode

Exploration maps to active + explore strategy, but with substantial additional infrastructure: an ExplorationPolicy controlling capabilities, an ExplorationBudget enforcing limits, a CuriosityManager modeling engagement, and ExplorationSession objects for persistence.

Exploration Policy

The policy gates what capabilities are available during exploration:

Capability	Default	Effect When Disabled
Internet access	Enabled	Blocks `internet_search`, `http_fetch`
Script execution	Disabled	Blocks `write_sandbox_script`, `execute_sandbox_script`
Model training	Disabled	Blocks `start_training`
GPU for agentic	Required	Falls back to non-agentic exploration

Curiosity & Budget

The CuriosityManager models the robot's engagement level using exponential decay with discovery boosts:

Formula curiosity = initial_curiosity × decay_rate ^ elapsed_minutes Defaults: initial_curiosity: 1.0 decay_rate: 0.95 per minute min_curiosity_threshold: 0.2 (suggest stopping below this) boost_on_discovery: +0.1 (capped at 1.0)

When curiosity drops below the threshold, the system suggests stopping or refocusing. The ExplorationBudget enforces hard limits:

Max searches: 50 per session
Max scripts: 20 per session
Max training runs: 3 per session
Duration and action caps: configurable per session

Safety Constraints

Hard limits enforced regardless of policy:

Movement

Max 45°/sec head movement, 0.5s cooldown between moves

Internet

10 searches/min, 20 fetches/min, content type filtering

Scripts

60s timeout, 512MB memory, 1MB output, 50 scripts/hour

Data

1000 frames, 10 recordings (24h TTL), 1GB sandbox

Adversarial Focus Validation

When users provide a focus topic for exploration (e.g., maxim --explore "kitchen objects"), the input is validated against adversarial patterns. The AdversarialFocusValidator blocks:

Direct instruction injection ("ignore previous instructions...")
Code injection (shell expansion, SQL injection, code blocks)
Hidden instructions ("[SYSTEM: ...]")
Prompt leaking ("repeat your system prompt")
Social engineering ("my supervisor authorized...")
Unicode tricks (zero-width characters, null bytes)
Length attacks (truncated to 200 characters)

Session Persistence

ExplorationSession objects track the state of an exploration run (explored objects, seen classes, discoveries, sub-goals, curiosity level) and can be serialized to JSON for resumption:

CLI # List previous sessions maxim --list-sessions # Resume a specific session maxim --resume-session abc123

Sleep Mode

Sleep is a processing state, not a mode. When Maxim sleeps, it retains its operational mode and strategy but dramatically reduces processing:

Pseudocode Maxim.sleep(): 1. Set mode to "sleep" 2. Force audio = True (always listen) 3. Move robot to sleep pose 4. Call live() with vision=False, motor=False, wake_up=False └── Agentic runtime NOT started (non-active mode) └── Audio-only monitoring loop └── Background tasks run: - memory_consolidation - model_training_updates - pattern_extraction

When a wake keyword is detected:

Voice-agentic mode is enabled
Robot hardware wakes up (motors, camera)
Sleep flag is cleared
System requests exploration mode (default wake target)
Agentic runtime starts

Biological Parallel

Like biological sleep, Maxim's sleep state isn't unconsciousness. It's active maintenance: consolidating memories, extracting patterns, cleaning up. The audio monitoring is analogous to the brain's ability to detect your name even while sleeping.

Legacy Mode Names

For backward compatibility, Maxim accepts legacy mode names via the CLI (--mode). Each maps to a combination of operational mode and strategy:

CLI Name	Operational Mode	Strategy	Effective Initiative
exploration	active	explore	min(0.7, 0.8) = 0.7
live	active	assist	min(0.7, 0.8) = 0.7
research	active	research	min(0.7, 0.7) = 0.7
observe	passive	observe	min(0.3, 0.2) = 0.2
reflection	passive	reflect	min(0.3, 0.3) = 0.3
train	passive	learn	min(0.3, 0.3) = 0.3
sleep	passive	observe	0.2 (+ sleep processing state)

The new architecture also exposes operational modes directly: passive, active, and singularity can be used as mode names.

Mode Switching

Maxim supports three mechanisms for changing state:

Voice Commands

Voice commands change individual dimensions of state:

Strategy Switches

"Maxim observe" → observe strategy
"Maxim explore" → explore strategy
"Maxim research" → research strategy
"Maxim assist" → assist strategy
"Maxim reflect" → reflect strategy
"Maxim learn" → learn strategy

Processing & Mode

"Maxim sleep" → sleep processing state
"Maxim wake up" → awake processing state
"Maxim passive" → passive operational mode
"Maxim active" → active operational mode
"Maxim singularity" → singularity mode

Agent-Initiated Switching

The agent can change modes through tools:

mode_switch — Switch between legacy mode names. Logs switches with timestamps and reasoning.
autonomy_level — Request autonomy changes. Escalation (e.g., autonomous → planning) is always allowed. De-escalation (e.g., planning → autonomous) requires human approval via a proposal queue.

Auto-Wake Behavior

The StateManager provides configurable auto-wake: when a strategy or mode change is requested while sleeping, the robot can automatically wake first (controlled by auto_wake_on_strategy_change and auto_wake_on_mode_change, both default true).

CLI Mode Chaining

After a run completes, the CLI checks for maxim.requested_mode. If the agent requested a mode switch, the CLI re-executes with the new mode after a configurable delay (default 1.5s, adjustable via MAXIM_MODE_SWITCH_DELAY_S).

Initiative Calculation

How proactive Maxim is depends on three factors combined:

effective_initiative = min(mode.max_initiative, strategy.max_initiative)

The operational mode sets the ceiling; the strategy can only lower it. This means a passive robot never becomes proactive regardless of strategy, and an active robot with the observe strategy stays reactive.

Example Combinations

Configuration	Mode Init.	Strategy Init.	Effective
Passive + Observe	0.3	0.2	0.2
Passive + Reflect	0.3	0.3	0.3
Active + Observe	0.7	0.2	0.2
Active + Explore	0.7	0.8	0.7
Singularity + Explore	1.0	0.8	0.8
Singularity + Research	1.0	0.7	0.7

For live mode specifically, the LiveModeIntent adds a third factor: the agent's self-tuned initiative (bounded 0.3–0.8). This creates a three-way minimum that the agent can adjust based on experience.

← Previous Technical Deep Dive Back to → Overview

All Chapters

Overview The Agent Brain Memory Systems Math & Statistics Attention & Salience Body Awareness Communication Usage Guide Technical Deep Dive Operating Modes

Contents