Scheduled Agents Collide When Dependencies Are Invisible
Scheduled Agent collision control is the operating practice of checking whether several Axon Agents can run on a Schedule without stepping on source refreshes, workspace artifacts, and downstream Workflows. Without it, teams waste hours on manual investigation after repetitive, inefficient timing failures. A collision is not always two jobs starting at the same minute. It may be a downstream Agent reading last week's source folder because the upstream refresh is late. It may be one Agent overwriting an artifact while another reads the old version. It may be a retry window pushing into the next scheduled run.
OpenAI Agents tracing shows why run state and step history matter when teams need to understand Agent behavior. NIST's AI Risk Management Framework places monitoring and governance inside AI management. Axon's practical view is that Schedule is not a cron table. Schedule is a workflow promise that includes sources, artifacts, owners, Trust Mode boundaries, and downstream readers.
This article connects to Agent downstream dependency checks, scheduled Agent failure policy, Agent source refresh windows, and workspace artifact continuation. The problem is common: a run can be on time and still be wrong.
A Common Collision
At 09:00, a source refresh Agent is still waiting for a new customer feedback CSV. At 09:05, the summary Agent starts on time and reads last week's folder. At 09:10, the reporting Agent reads the summary artifact and produces a leadership update. At 09:30, the owner sees that the numbers disagree with the support system, and the team starts manual investigation.
None of the Agents looks broken in isolation. Each followed its own Schedule. The collision happened because the dependency map was invisible.
A Schedule collision happens when one Agent assumes a prerequisite is ready while the workflow state says it is not.
Scheduled Agent collision control starts with four questions:
- When is the upstream source considered available?
- When is the intermediate artifact considered accepted?
- May downstream Agents read draft artifacts?
- If the upstream run is late or failed, should downstream work wait, skip, or downgrade?
Replace the Time Table With a Dependency Table
A list of run times is not enough. The useful view connects time with prerequisites and artifacts.
09:00 source-refresh-agent
requires: customer-feedback.csv uploaded
produces: workspace/sources/current-feedback/
accepted_by: support operations owner
09:15 feedback-summary-agent
requires: current-feedback accepted
produces: workspace/artifacts/weekly-feedback-summary.md
fallback: if source not accepted, stop as needs_source
09:30 leadership-report-agent
requires: weekly-feedback-summary accepted
produces: workspace/artifacts/leadership-report.md
fallback: if summary missing, publish no report and notify owner
This is more reliable than spacing jobs fifteen minutes apart. It tells the Schedule which artifact is a draft, which artifact is accepted, and which failure should stop downstream work.
Three Collisions That Repeat
- Source collision: downstream starts before source refresh finishes.
- Artifact collision: an Agent reads an artifact that is not accepted or is being overwritten.
- Recovery collision: retries from a failed upstream run push into the downstream window.
These should not depend on someone watching the clock. They should become workflow rules.
Do Not Fix Every Collision by Moving the Time
After a collision, teams often move the downstream Agent ten minutes later. Sometimes that helps. Often it only hides the issue. If upstream source delivery sometimes slips by thirty minutes, a ten-minute delay does not solve the dependency problem.
A stronger recovery rule is short:
if required_artifact.status != accepted:
stop_state: waiting_dependency
notify: report owner
retry: once after 20 minutes
after_retry: skip this run and record reason
That rule makes scheduled Agent collision control state-based instead of guess-based. It protects downstream work from producing a polished artifact from unfinished inputs.
Collision Records Improve the Schedule
A collision record should be kept long enough to learn from it. If the same source is late every Monday, the source window is wrong. If the same artifact is being read before acceptance, the dependency rule is wrong. If retries keep overlapping downstream work, the failure policy needs a different recovery window.
This is why collision control belongs with Agent operations, not only infrastructure scheduling. Business value depends on whether the right artifact was available at the right time, not whether a process started on a timer.
FAQ
Q1: Is scheduled Agent collision control just about spacing jobs apart?
No. Spacing helps, but the important question is whether sources, artifacts, and dependencies are ready.
Q2: Can downstream Agents read draft artifacts?
Only if the workflow explicitly allows it. For important work, reading accepted artifacts is safer.
Q3: Should downstream Agents continue when upstream fails?
Usually no. They should wait, skip, downgrade, or notify the owner based on a clear rule.
Q4: How long should collision records be kept?
Important recurring workflows should keep them. The records help tune Schedule, source windows, and recovery rules.
Q5: What if several Agents share one artifact?
Define write owner, read owner, overwrite rule, and version review so reading and writing do not happen invisibly at the same time.
Next Step
When you start using Axon Schedule, map critical chains before adding more recurring Agents: upstream source, intermediate artifact, downstream Agent, accepted state, and recovery rule. Learn more by reviewing whether each Agent ran under the right dependency state, not only whether it started on time.