Recipes
Building Event-Driven Agents
Use control events to react to memory changes, checkpoints, outcomes, and coordination artifacts instead of relying only on polling loops.
Polling is acceptable for simple loops, but event-driven coordination is better when planners and workers need to react to new memory, handoffs, feedback, checkpoints, or outcome updates.
The event stream is still a low-level control-plane surface. Keep the public integration model helper-first for memory writes and reads, and use the event stream to wake orchestration logic.
Decision model
| Event lane | Surface | Use when |
|---|---|---|
| Run-scoped control events | GET /v2/control/events/subscribe | One workflow should react to ingest, reflection, handoff, feedback, checkpoint, or outcome events |
| Memory read/write loop | remember, recall, getContext, checkpoint | Most application behavior |
Minimal implementation example
Failure modes and troubleshooting
| Symptom | Root cause | Fix |
|---|---|---|
| Workers still poll constantly | Event stream is not wired to the orchestration loop | Move wakeup logic to the control stream |
| Event stream is noisy | Too many memory writes without filtering in the worker | Filter by event type in the consumer |
| Recovery is hard after compaction | Events fire but context is not rebuilt | Re-read with getContext() after the wakeup |
Next steps
- Add planner state at Multi-agent shared state.
- Add branch-safe experimentation at Branching memory.