Skip to main content
ArgentOS Business — This feature is part of ArgentOS Business. The architecture is documented here for all users, but full functionality requires a Business license. Learn more about Business

Overview

The Execution Worker is ArgentOS’s autonomous task processor. It runs on configurable intervals (default 20 minutes), selects the next runnable task by priority and dependency order, executes it through the full agent toolchain, validates evidence of completion, and auto-blocks tasks that make no progress after repeated attempts. This is the system that lets Argent work independently on a backlog of tasks — research, content creation, code generation, data processing — without requiring a human to trigger each one.

Configuration

Task Selection

Priority Ordering

Tasks are selected based on a weighted priority system: Within the same priority, tasks are ordered by creation time (oldest first).

Dependency Resolution

Before selecting a task, the worker checks its dependsOn array. A task is only runnable if all its dependencies are in completed status. Tasks with unresolved dependencies are skipped.

Scope Filtering

The worker resolves agent aliases so that main, argent, agent:main, and agent:argent all match the main agent.

Evidence Validation

When requireEvidence is true (the default), the worker validates that the agent actually accomplished something during execution:
  1. Tool claim validation: Did the agent claim to use tools? Did it actually execute them?
  2. External artifacts: Were external artifacts produced (files, messages, API calls)?
  3. Progress indicators: Did the task status change? Were subtasks completed?
If evidence is insufficient, the attempt is marked as no-progress.

No-Progress Blocking

When a task accumulates maxNoProgressAttempts (default: 2) consecutive attempts without measurable progress, it is automatically blocked. This prevents the worker from burning tokens on tasks it cannot make progress on.
Blocked tasks are excluded from future selection until manually unblocked.

Pre-flight Checks

Before each cycle, the worker performs several checks:
  1. Enabled: Is the worker enabled in config?
  2. Not paused: Is the worker paused (globally or per-agent)?
  3. Not running: Is another cycle already in progress?
  4. Queue empty: No pending user messages that should take priority
  5. No active runs: No embedded agent sessions currently executing
  6. Active hours: Is the current time within configured active hours?
If any check fails, the cycle is skipped with a reason code.

Dashboard Controls

Available Actions

Metrics Tracked

Multi-Agent Support

The worker maintains independent state per agent. Each agent has its own configuration, timer, no-progress tracking, and metrics counters.
This allows different agents to have different execution profiles — for example, a research agent might run every 10 minutes with a broad scope, while a support agent runs every 30 minutes on assigned tasks only.