fix: make cron skip_memory configurable via config.yaml

[nightq]

Summary

Makes skip_memory configurable for cron jobs via config.yaml, allowing external memory providers (mem0, etc.) to be used in scheduled tasks.

Root Cause

cron/scheduler.py hardcoded skip_memory=True, which prevented _memory_manager from being initialized. This meant external memory provider tools (mem0_search, mem0_conclude, etc.) were always unavailable in cron sessions.

Fix

Changed line 753 to read skip_memory from config.yaml under cron.skip_memory$, defaulting to True` for backward compatibility.

Users can now add to their config:

cron:
  skip_memory: false

Test Plan

• Added 5 unit tests for config reading logic (default true, explicit false, explicit true, empty section, other settings preserved)
• All tests pass

Closes #9763

[drewbitt]

Flipping this on may re-expose #4052-shaped corruption for providers without Honcho's plugin-level _cron_skipped guard (mem0/openviking/retaindb/byterover etc)

May prefer #9802 which has per-call-site flags

[alt-glitch]

Competing PR: #9802 takes a different approach (allow external while keeping local skipped). Both address #9763.

[alt-glitch]

Competing with #9802 for #9763.

[teknium1]

Thanks for the focused configuration proposal. The current hard-coded gate does leave external providers unavailable to cron, but this needs a narrower implementation before salvage.

Problems

• cron/scheduler.py:753 changes the same skip_memory switch that initializes both the built-in store (agent/agent_init.py:1333-1345) and external providers (agent/agent_init.py:1353-1417). With false, cron gains local memory loading and write capability through agent/tool_executor.py:1226; it does not retain the safety intent of the existing cron comment.
• tests/cron/test_scheduler_skip_memory.py:13-41 tests a copied dictionary expression rather than cron.scheduler. Those tests pass without the production change, so they do not protect the behavior.
• The behavior needs documentation: website/docs/user-guide/features/spotify.md:218 currently says cron uses skip_memory=True to avoid memory-store writes.

Suggested changes

• Separate external-provider tools from built-in memory read/write, or add explicit guards for the intended cron behavior.
• Test the real run_job → AIAgent kwargs path and document the supported configuration.

Automated hermes-sweeper review.

[teknium1]

skip_memory is also the built-in MEMORY.md/USER.md gate: agent/agent_init.py:1333-1345 initializes that store and 1353-1417 initializes providers under the same condition. Setting this false therefore enables local-memory reads and writes as well as provider tools, rather than preserving the cron isolation described by the replaced comment. Please separate the provider-only behavior or guard the built-in memory effects explicitly.

[teknium1]

These tests only evaluate a locally copied dict expression, so they pass on the base revision where cron/scheduler.py still hard-codes skip_memory=True. Please exercise run_job with a mocked AIAgent (or an imported production resolver) and assert the actual constructor kwarg.

[teknium1]

Thanks @nightq — you were the earliest to tackle this (Apr 14), and your PR correctly identified the hardcoded skip_memory=True as the problem. We ended up going further than a config toggle: PR #91447 (merged as ef04d84) enables memory for cron agents unconditionally, matching every other agent surface (MEMORY.md/USER.md load, memory tool on the schema), with agent.disabled_toolsets: [memory] as the opt-out. Closing as superseded — appreciate you kicking this off.