Agent Health — user-facing cron agents

Measured 2026-04-18. Source of truth is state/log/evals.ndjson plus the artifact files listed below. This page covers the two most visible agents in the byline (inbox-sweep, content-mine) plus their health dependencies.

Summary table

inbox-sweep

• Skill: state/skills/inbox-sweep.md — sweepAll() fanout (Slack/Gmail/LinkedIn/Skool).
• Execution path: agent sessions spawned by state/bin/agents/tick.sh (every 10 min) call fetchLinkedInDMs + upstream sweepAll(). Snapshots land in state/log/sweep-snapshots/<ts>-inbox.json.
• Evals 7d: 8 rows, all score=1, verb fetchLinkedInDMs. Latest 21:00 UTC.
• Sample artifact (2026-04-18T22-19-inbox.json): 3 Gmail threads (Beautiful Life Studios re: Photographer Update; Dimitris Goudis re: State Change Mastermind; Neary re: Thank you for your time) + 1 LinkedIn Offer promo DM. All awaiting_reply: false. No errors object populated.
• Known issues:
• Byline rate_for_label() case for __sweep__ searched for "skill":"linkedin-sweep"; evals write "skill":"inbox-sweep". Fixed in this audit — patched state/bin/byline/tui.sh to match the real skill name so next-run ETA renders instead of -.
• Byline catalog row swp in state/bin/byline/agents.sh still points at missing ~/.claude/skills/snappy-inbox-sweep/linkedin-sweep-cron.sh (only backup copies exist under .claude/_backups/). Agent is NOT blocked — production pathway is state/bin/agents/tick.sh which calls sweepAll() directly — but /snappy-run inbox-sweep from byline would fail. Replacement command: cd $HOME/projects/snappy-os && npx tsx state/lib/sweep.ts sweep. Not applied (owner reverted a prior attempt); flagging as open question rather than defect.
• Known artifacts not fixed: ~/.claude/logs/linkedin-sweep.log shows "LinkedIn auth expired" entries through 2026-04-18T02:53Z, then only tick-exit lines. That log belongs to the dead cron pathway; the production pathway writes to state/log/sweep-snapshots/ and state/log/evals.ndjson, which are healthy.
• Open questions: is the dead linkedin-sweep-cron.sh pathway actually dead or just dormant? If an old cron entry re-activates, it will fail. Worth grepping for it next sweep.

content-mine

• Skill: state/skills/content-mine.md — graduated, sidecar at state/bin/content-mine/tick.ts.
• Execution path: claude-cron.sh content-mine every hour, runs state/bin/content-mine/tick.ts which extracts commits since the last run, gates via requireCitations(), scores via dispatch({model:"gemini"}), keeps atoms at robert_signal ≥ 0.6, writes to state/log/content_atoms-<run_id>.ndjson, appends to state/log/evals.ndjson.
• Evals 7d: 24 rows, mean 1.000. The one 0.0 row on 2026-04-17T16:18Z (signal-dispatch-failed) was the gemini quota cap before fallback-to-heuristic was added.
• Sample artifact (content_atoms-9afe08db-96.ndjson @ 21:56Z): 2 commits since the prior tick, both kept. Example line:

  {"run_id":"9afe08db-96","sha":"d4e604d2","subject":"pod-26: lint cleanup — sidecars + SYNC_ALLOW + cli.js autopilot verb","robert_signal":0.9,"kept":true}

• Recent recovery: cron log claude-cron-content-mine.20260418-141500.log recorded a P1 friction — the then-current tick.ts had ../lib/voice.ts imports that resolved to a non-existent state/bin/lib/. Convention is ../../lib/. The current sidecar uses the correct path (lines 7–8) so the friction is closed. Post-17:17Z ticks all recorded signal_mode:"dispatch" and produced atoms.
• Manual verification: I ran npx tsx state/bin/content-mine/tick.ts in this session — printed {run_id:"e1d4418a-23", raw:50, cited:50, kept:50, signal_mode:"dispatch"}.
• Open questions: sidecar still imports dispatch with tools:[] per kernel contract; confirm gemini quota headroom for the next 24h so we don't fall back to the 0.7 heuristic.

Fixes shipped in this audit

1. state/bin/byline/tui.sh — __sweep__ pattern matches "skill":"inbox-sweep" (the actual written name); prior "linkedin-sweep" never matched any eval row so the byline ETA displayed -.

No functional changes to either agent's execution path. Both were already running; byline visibility of inbox-sweep was broken because the skill-name pattern was stale.

Open items

• Reconcile state/bin/byline/agents.sh swp row with reality — it references a script that only exists under .claude/_backups/. Either restore the script or point the row at npx tsx state/lib/sweep.ts sweep so /snappy-run inbox-sweep from byline works.
• Decide whether ~/.claude/logs/linkedin-sweep.log should be retired or repurposed — it is referenced as live_log by the byline row but is no longer written by the active pathway.