Context
Clawdapus pods that run trading desks have agent cron schedules that are inherently tied to market hours. Today, the Invocation struct is deliberately simple — Schedule (5-field cron) + Message + To + Name — with no support for conditional execution.
What pods do today
Pod operators work around this in two ways:
-
Cron expression scoping — using day-of-week (1-5) and hour ranges (9-16) to approximate market hours. This handles the daily cycle but cannot express holidays, early closes, or variable sessions.
-
Prompt-level guards — telling agents "if nothing is newsworthy, produce zero text" or "report only on failure." The job still fires, the agent still wakes, tokens are still consumed — the agent just decides to do nothing.
The gap
Neither approach handles:
- Market holidays (e.g., US markets closed on Good Friday, MLK Day, etc.)
- Early closes (half-days before holidays)
- Cross-market scheduling (crypto 24/7 vs. equities vs. futures)
- Arbitrary runtime conditions (e.g., "only fire if there are open positions," "only fire if the agent hasn't run in the last N minutes")
The cost of the gap is wasted agent turns — an agent wakes up, spends tokens reasoning about the context, and concludes "market is closed, nothing to do." On a desk with 6+ agents and 50+ scheduled invocations, this adds up on weekends and holidays.
Real example from Tiverton
Tiverton's claw-pod.yml has ~50 scheduled invocations across 8 agents. Most are scoped to * * 1-5 (weekdays) with hour ranges. But:
- The audit export was running
15,45 * * * * (24/7 including weekends) — just tightened to weekday market hours.
- Sentinel fleet review was running
0 * * * * — just split into weekday (hourly) and weekend (every 4h) schedules.
- No job can express "skip US market holidays" without the agent wasting a turn to figure that out.
- Traders like weston/logan/gerrard have 6 jobs each scoped to
* * 1-5 — all will fire uselessly on holidays like Good Friday.
What would help
A way for pod operators to express conditions on invoke entries that the driver evaluates before waking the agent. When the condition is false, the job is silently skipped — no agent turn, no token spend.
Possible condition types that would be useful:
- Market session state (open, pre-market, after-hours, closed)
- Day-type (trading day vs. holiday for a given exchange/calendar)
- Arbitrary service health checks
- Custom shell/HTTP predicates
Not prescribing implementation
This issue intentionally does not specify where the condition should live (pod YAML schema, driver layer, runner layer) or what the evaluation mechanism should be. The current architecture (ADR-006: runner-native scheduling, no fake common cron schema) should inform the design.
The goal is: pod operators should be able to say "this job only matters when the market is open" without wasting agent compute to discover that fact at runtime.
Context
Clawdapus pods that run trading desks have agent cron schedules that are inherently tied to market hours. Today, the
Invocationstruct is deliberately simple —Schedule(5-field cron) +Message+To+Name— with no support for conditional execution.What pods do today
Pod operators work around this in two ways:
Cron expression scoping — using day-of-week (
1-5) and hour ranges (9-16) to approximate market hours. This handles the daily cycle but cannot express holidays, early closes, or variable sessions.Prompt-level guards — telling agents "if nothing is newsworthy, produce zero text" or "report only on failure." The job still fires, the agent still wakes, tokens are still consumed — the agent just decides to do nothing.
The gap
Neither approach handles:
The cost of the gap is wasted agent turns — an agent wakes up, spends tokens reasoning about the context, and concludes "market is closed, nothing to do." On a desk with 6+ agents and 50+ scheduled invocations, this adds up on weekends and holidays.
Real example from Tiverton
Tiverton's
claw-pod.ymlhas ~50 scheduled invocations across 8 agents. Most are scoped to* * 1-5(weekdays) with hour ranges. But:15,45 * * * *(24/7 including weekends) — just tightened to weekday market hours.0 * * * *— just split into weekday (hourly) and weekend (every 4h) schedules.* * 1-5— all will fire uselessly on holidays like Good Friday.What would help
A way for pod operators to express conditions on
invokeentries that the driver evaluates before waking the agent. When the condition is false, the job is silently skipped — no agent turn, no token spend.Possible condition types that would be useful:
Not prescribing implementation
This issue intentionally does not specify where the condition should live (pod YAML schema, driver layer, runner layer) or what the evaluation mechanism should be. The current architecture (ADR-006: runner-native scheduling, no fake common cron schema) should inform the design.
The goal is: pod operators should be able to say "this job only matters when the market is open" without wasting agent compute to discover that fact at runtime.