Summary

• Cron-triggered agents currently skip memory entirely (skip_memory=True), so scheduled behaviors like self-reflection and hub-discovery have zero persistence across runs
• Route each cron job to its own Honcho peer (cron-{job_name}) instead of the human owner's peer, giving each scheduled behavior a coherent representation while the assistant's unified self-model accumulates all cron actions
• Revert the feat(honcho): add opt-in initOnSessionStart for tools mode and respect explicit peerName #6995 not cfg.peer_name guard that silently blocked all user_id overrides on provisioned agents (where peerName: "user" is configured), fixing active stranger pollution and unblocking cron peer routing
• Add skip_memory=True to the hygiene compress agent, which was accidentally protected by the now-removed cron guard but should never write to memory providers
• Add agent.shutdown_memory_provider() to the cron teardown path so final sync_turn/aretain_batch writes aren't silently dropped

Detail

Why per-job peers (not one global cron peer)

Cron behaviors are semantically distinct — self-reflection, hub-discovery, morning-brief, etc. A single peer accumulating all of them would produce an incoherent representation. Each named job gets its own peer with a readable ID derived from the job name.

Why revert #6995's peerName guard

The guard (if _gw_user_id and not cfg.peer_name) was intended to prevent raw transport IDs from overwriting an explicitly configured peerName. But on provisioned agents where peerName: "user" is set, it blocks all user_id overrides — including cron peer routing and stranger isolation. This causes two bugs:

1. Cron pollution: user_id="cron-self-reflection" is silently ignored → cron messages land on the owner's user peer
2. Stranger pollution: any stranger DMing the bot also lands on user instead of their own transport-level peer

The fix moves identity protection to the gateway layer (where caller context is available) rather than the plugin layer. Owner fragmentation temporarily returns to pre-#6995 behavior until the gateway-side owner detection ships as a follow-up.

Hindsight

Hindsight has no cron guard — when skip_memory=True is removed, it activates automatically and begins retaining cron turns. Each run stores under its own document_id (the cron_{job_id}_{timestamp} session ID), so runs are naturally distinct. No hindsight-specific changes needed.

Test plan

• Create two named cron jobs, let each fire 2-3 times, verify distinct cron-{name} peers appear in Honcho workspace with per-job representations
• Verify owner's peer representation is not polluted with cron content
• Verify stranger DMs attribute to transport-level peers (not user)
• Let self-reflection cron fire and confirm it can read prior self-reflections via Honcho
• Verify cron run documents appear in Hindsight with correct document_id pattern
• Confirm shutdown_memory_provider() runs cleanly in cron teardown (no dropped writes in logs)
• Trigger hygiene compression and verify _hyg_agent does not create Honcho peers or Hindsight documents

🤖 Generated with Claude Code