Hermes can run a cron job without ICM. It can wake up on schedule, read a source, write a report, send a message, and save the run output. It also has its own durable storage: - session history, - persistent memory, - cron definitions and run logs, - skills, - and whatever files it creates in the workspace. That is useful. But it can still leave you with a familiar mess: > a chat somewhere > a cron log somewhere else > a report with no obvious home > and an agent that needs you to explain the project again next week That is where ICM comes in. I use ICM around my Build Market Close signal cron so the **job is not the whole system**. The cron is just the heartbeat. The structure holds the memory: ```text pinned-post-curriculum-signal/ ├── CONTEXT.md ├── signal-register.md ├── reply-drafts.md ├── curriculum-outline.md └── runs/ └── YYYY-MM-DD/ └── signal-review.md ``` Here is what each part does: - **`CONTEXT.md`** tells a fresh agent what source it may read, what counts as meaningful signal, what it may write, and where it must stop for me. - **`runs/YYYY-MM-DD/`** keeps a dated receipt of every review: what the job saw, what changed, and what it deliberately did not do. - **`signal-register.md`** is the one place for real questions, objections, implementation friction, and learner needs. - **`reply-drafts.md`** holds proposed answers for review. Nothing gets posted automatically. - **`curriculum-outline.md`** turns repeated questions into a better lesson sequence instead of letting them disappear into comments. So the cron does the recurring check. But ICM makes the check **usable**. A fresh agent can open the folder and answer: 1. What is this job for? 2. What source is it allowed to use?