Argent autonomous task pickup — wire assignment → inner-loop → claim/heartbeat/halt

[webdevtodayjason]

Summary

Argent has a task board (tasks get created, assigned to argent, tracked in the UI) and a kernel inner loop (Phase 1 just shipped tickMs scaffolding). Nothing connects them. Tasks assigned to her sit there indefinitely because assignment is a database row write, not a runtime signal — her inner loop has no reason to look at the board and no protocol for working through pending work.

Operator-visible symptom (2026-05-25/26): 43 active tasks "assigned to argent" sitting unworked across multiple lanes — old HoLaCe items, Rust migration, podcast, Telegram, support-validation. Operator's read, which is correct: "the board is acting like an inventory, not an execution engine."

This isn't a bug in any one component — every individual piece works. It's a missing layer of glue, and arguably the layer that defines whether Argent is an assistant that responds or an agent that follows through.

Five layers that have to all be true

#	Layer	State today	Notes
1	Inner loop ticks — Argent wakes periodically	✓ Exists	Kernel-fitness Phase 1 (#388) just scaffolded this. tickMs is configurable.
2	Task store exists — tasks have IDs, state, assignment	✓ Exists	Tasks API + UI; used today for the reranker urgent task 18711e62-... and the SpecForge bug task 54a66659-...
3	Assignment emits a signal to the runtime	✗ Missing	Assignment writes a row. Nothing tells Argent's inner loop "look at the board."
4	Picker / safe-claim heuristic	✗ Missing	Even if she polled, tasks are descriptions, not executable specs. No "I can safely do this autonomously vs needs operator" gate.
5	Claim → heartbeat → halt protocol	✗ Missing	No claim_ttl, no heartbeat surface, no per-task "done condition." Even if execution worked you couldn't tell.

Smallest viable version

1. New tick handler in the kernel inner loop — every N minutes (env-configurable, default 5 min):

SELECT * FROM tasks
WHERE assignee = 'argent'
  AND status IN ('pending', 'scheduled')
  AND (claim_ttl IS NULL OR claim_ttl < NOW())
  AND class IN (<safe-class-whitelist>)
ORDER BY priority DESC, created_at ASC
LIMIT 1;

2. Safe-class whitelist — v1 is hardcoded:

   • triage (issue triage, no writes)
   • memory-search (read-only)
   • code-review (output is a comment, not a commit)
   • doc-update (writes are reviewable)
   • Excluded by default: anything touching prod, external comms, irreversible operations, secrets

3. Claim protocol:

UPDATE tasks SET
  status = 'in_progress',
  claimed_by = 'argent',
  claim_ttl = NOW() + INTERVAL '15 minutes',
  claim_acquired_at = NOW()
WHERE id = $1 AND status = 'pending';
-- Reject the run if 0 rows updated (someone else claimed it)

4. Execution path: dispatch a subagent with the task's description as the spec, the task's acceptance_criteria as the done condition. Reuse the existing sessions_spawn machinery.

5. Heartbeat: while subagent is running, refresh claim_ttl every 60s. If subagent stalls or dies, the TTL expires and the task returns to pending for another round.

6. Completion: subagent posts evidence (a PR link, a comment, a memory write) and sets status = done. Operator sees the evidence in the task UI.

Policy / autonomy gating

This is the real design question, separable from the implementation:

• What's Argent allowed to do without the operator in the loop? The autonomy skill in the global config hints at this (autonomy doctrine for orchestrators / workers) — but Argent's runtime doesn't currently consult any policy file when deciding to act, because there's no "deciding to act" code path.
• Blast-radius budget per autonomous run — token cost, time, irreversibility. A task that "researches and writes a memory" is cheap. A task that "drafts and opens a PR" is moderate. A task that "merges and publishes" must require operator confirmation.
• Kill switch — operator needs a single command to halt all autonomous work. argent autonomy pause or similar.
• Reporting cadence — daily summary of what got done, what got declined, what's still pending.

A reasonable v1 default: autonomy = read-only (search memory, draft, analyze — never write). Upgrade to autonomy = scoped-write (PRs, comments, memory writes) per-class via opt-in.

Why this matters beyond the 43 tasks

The 43-task cleanup is housekeeping. The architectural gap is that Argent presents as an agent but operates as an assistant. Every interaction is operator-initiated. Idle time produces nothing. Pending intent doesn't decay into action without a human prompt.

Fixing this is what differentiates Argent from "fancier chat UI." It's also the layer that makes the operator's trust loop tractable — instead of "why isn't she working on the things I asked for?", the answer becomes "here's what she did since you last checked, here's what she declined and why."

Out of scope (don't tackle in this issue)

• Multi-agent task distribution (one Argent is enough for v1)
• Cross-machine task federation (operator runs Argent on one machine for now)
• AI-driven task prioritization (manual priority is fine for v1)
• Background research / learning that doesn't correspond to a task (separate problem)

Suggested next step

1. Pick the safe-class whitelist for v1 — get 3-5 task classes the operator is comfortable with Argent attempting autonomously
2. Build the tick handler + claim protocol (layers 3 + 5)
3. Run with autonomy = read-only for a week, see what gets attempted, refine the whitelist
4. Add scoped-write autonomy after the trust loop has data

Related

• Argent runtime stability sweep — subagent dispatch, worker lifecycle, model routing #423 — Argent runtime stability umbrella (this is the missing enhancement that sits underneath those bug symptoms)
• Memory recall ranks reinforced topical co-mentions above direct attribute claims #418 / fix(memory): reranker guardrail — prevent LLM from burying dominant pre-rerank top (closes #418) #420 — memory reranker; once Argent CAN autonomously work tasks, memory quality becomes load-bearing for her self-direction
• The diagnostic doc at ~/.argentos/workspace/memory-reranker-diagnostic-favorite-color.md is itself an example of work she did unprompted because she was given a clear ask — that pattern generalizes

[webdevtodayjason]

#453 ships layers 3–5 for the execution-worker lane: claim CAS (claimed_by/claim_ttl/claim_acquired_at/attempt columns), runner-side 60s heartbeat capped at maxRunMinutes, lease-expiry sweep per cycle, boot-time orphan sweep (crash recovery = restart time — live-verified on a real killed-mid-flight run), and execution.worker.halt (cooperative abort + 30s-grace hard kill, measured 66ms to stopped). Remaining from this issue: layer 3's event wakeup beyond runNow (assignment-creation → dispatch) and the kernel-loop safe-class picker for non-job tasks.