Skip to main content

​
The Problem

ArgentOS runs scheduled jobs (cron) in isolated sessions — separate agent instances with no conversation history, no memory access, and no personality context. This is by design: isolation prevents cron jobs from polluting the main session’s context window and allows them to run on cheaper model tiers. But isolation creates three gaps:
Isolated sessions produce work that the main session never sees. The agent wakes up, does research, generates output, and the result evaporates when the session ends.
The main session has MemU, conversation history, SOUL.md, and USER.md. Isolated sessions have none of this. They produce competent but generic output — missing the personal touch.
There’s no verification that the isolated session completed all requirements, met quality standards, or handled edge cases. Fire-and-forget means fire-and-hope.

​
The Insight

ArgentOS has two persistent storage systems that survive gateway restarts:
SystemStoragePersists?Accessible By
Task systemSQLite (dashboard.db)YesAll sessions
Doc panelSQLite (dashboard.db)YesAll sessions
System eventsIn-memory queueNoMain session only
Session historyIn-memoryNoSame session only
The minion pattern uses persistent storage (tasks + doc_panel) as the handoff mechanism, with system events as a bonus notification layer — not the primary one.

​
The Pattern

​
The Minion’s Job (Isolated Session)

The minion has a narrow, well-defined scope:
  1. Research — Gather raw data (web search, API calls, inbox checks)
  2. Draft — Write a structured draft of the deliverable
  3. Persist — Save the draft to doc_panel (survives restarts)
  4. Hand off — Create a task assigned to the main session with clear instructions
The minion does NOT:
  • Generate final audio/media
  • Deliver to external channels (Discord, email)
  • Make judgment calls about tone, timing, or audience
  • Access memory or personality context

​
The Main Session’s Job

The main session picks up the handoff during its normal operating cycle:
  1. Discover — Check tasks during startup, heartbeat, or contemplation
  2. Read — Open the doc_panel draft, review the minion’s work
  3. Enhance — Add context from memory, conversation history, personality
  4. Deliver — Generate final media, send to channels, notify the user
  5. Close — Mark the task complete

​
Why This Split Works

CapabilityIsolated SessionMain Session
Web searchYesYes
Tool callsYesYes
MemU (memory)NoYes
SOUL.md (personality)NoYes
Conversation contextNoYes
Relationship awarenessNoYes
Model tierUsually cheaperFull routing
Quality judgmentLimitedFull
This mirrors how human teams work: a junior researcher gathers data and writes a first draft, then the senior partner reviews, adds their expertise, and signs off.

​
Implementation Details

​
Cron Job Configuration

{
  "sessionTarget": "isolated",
  "wakeMode": "now",
  "payload": {
    "kind": "agentTurn",
    "message": "You are a research minion for [task]. Your ONLY deliverables are: doc_panel draft + task creation. Do NOT deliver to channels yourself."
  },
  "delivery": {
    "mode": "announce"
  }
}
Key settings:
  • sessionTarget: "isolated" — Runs in a separate session (no context pollution)
  • wakeMode: "now" — Triggers immediate heartbeat in main session after completion
  • delivery.mode: "announce" — Posts system event to main session
  • Both wakeMode and delivery are supplementary — the task in dashboard.db is the primary handoff

​
Main Session Discovery

The main session checks for minion handoffs at three points:
  1. Session startup — AGENTS.md “Cron Job Awareness” section
  2. Contemplation cycles — CONTEMPLATION.md “Check your minions” section
  3. Heartbeats — Triggered by wakeMode: "now" after cron completion
This triple-check ensures the handoff is discovered even if one mechanism fails.

​
Failure Modes and Recovery

FailureImpactRecovery
Minion crashes mid-researchNo draft, no task createdNext cron run retries
Minion creates draft but not taskDraft exists but undiscoverableManual check of doc_panel
Gateway restarts after minion completesSystem event lostTask persists in SQLite
Main session skips task checkTask sits pendingDiscovered on next cycle

​
Design Principles

  1. Persistent Over Ephemeral — Never rely on in-memory state for cross-session communication
  2. Narrow Minion Scope — “Research and draft” is good. “Research, draft, generate audio, deliver, and verify” is too much
  3. Explicit Handoff Instructions — The task description should be a complete checklist
  4. Triple-Check Discovery — Wire the handoff into multiple discovery points
  5. Separation of Concerns — Minion: data gathering (context-independent). Main: quality control (context-dependent)

​
Applying the Pattern

For any new cron job, ask:
  1. What part is data gathering? -> Minion does this
  2. What part requires context/memory/personality? -> Main session does this
  3. What’s the deliverable format? -> Minion saves draft to doc_panel
  4. What’s the delivery channel? -> Main session handles delivery