Problem
There is currently no mechanism for one cron job's output to be available to another cron job. Each job runs in a completely isolated session (cron/scheduler.py creates a fresh AIAgent per run with its own session ID). If job A discovers something and job B needs to act on it, users must wire the data through files on disk manually (e.g. job A writes to a file, job B's prompt references that file).
Current behavior
- Each cron job gets an isolated agent session (
cron_{job_id}_{timestamp})
- Job output is delivered to the configured target (Telegram, Discord, etc.) and saved to the session DB
- No job can reference another job's output or declare a dependency on another job
- The
script field lets a Python script run before the agent and inject stdout into the prompt, which is the closest workaround — but requires the user to write a script that reads from wherever the previous job saved its output
Desired behavior
A first-class way to chain cron jobs so one job's output can feed into the next. Possible approaches:
Option A: Explicit chaining via job dependencies
Add a depends_on or after field to the job schema that references another job ID. When job B depends on job A:
- Job B waits for job A to complete before running
- Job A's final output is injected into job B's prompt (similar to how
script stdout is injected)
Option B: Named output slots
Jobs can write to named output keys (e.g. output_key: "daily_findings"). Other jobs reference these via input_from: "daily_findings", which injects the most recent output from that key into the prompt.
Option C: Shared context file (lightweight)
Provide a convention/helper for jobs to share state through a well-known location (~/.hermes/cron/shared/), with the cronjob tool exposing a context parameter that auto-reads from a named file before execution. Less magical than A/B but trivial to implement.
Use case
"One [cron job] finds something, but the other can't see what it found unless I wire it through files manually."
— @Witcheer
Files involved
cron/jobs.py — job schema, CronJob dataclasscron/scheduler.py — job execution, prompt building (_build_job_prompt)tools/cronjob_tool.py — cronjob tool schema (would need new fields)hermes_state.py — SessionDB (could query previous job outputs)
Problem
There is currently no mechanism for one cron job's output to be available to another cron job. Each job runs in a completely isolated session (
cron/scheduler.pycreates a freshAIAgentper run with its own session ID). If job A discovers something and job B needs to act on it, users must wire the data through files on disk manually (e.g. job A writes to a file, job B's prompt references that file).Current behavior
cron_{job_id}_{timestamp})scriptfield lets a Python script run before the agent and inject stdout into the prompt, which is the closest workaround — but requires the user to write a script that reads from wherever the previous job saved its outputDesired behavior
A first-class way to chain cron jobs so one job's output can feed into the next. Possible approaches:
Option A: Explicit chaining via job dependencies
Add a
depends_onorafterfield to the job schema that references another job ID. When job B depends on job A:scriptstdout is injected)Option B: Named output slots
Jobs can write to named output keys (e.g.
output_key: "daily_findings"). Other jobs reference these viainput_from: "daily_findings", which injects the most recent output from that key into the prompt.Option C: Shared context file (lightweight)
Provide a convention/helper for jobs to share state through a well-known location (
~/.hermes/cron/shared/), with the cronjob tool exposing acontextparameter that auto-reads from a named file before execution. Less magical than A/B but trivial to implement.Use case
Files involved
cron/jobs.py— job schema, CronJob dataclasscron/scheduler.py— job execution, prompt building (_build_job_prompt)tools/cronjob_tool.py— cronjob tool schema (would need new fields)hermes_state.py— SessionDB (could query previous job outputs)