Online edition for BLOGE
0.9.8-RC1· facts verified 2026-09-15 · 中文
Arc 4 Recap — Lifecycle Models (Chapters 14–17)
You can now move beyond one-shot graphs and model longer-lived orchestration in ways that keep lifecycle structure visible.
What You Learned
Chapter 14 — Multi-Turn Sessions promoted the old appendix-only session material into the main reading path. You learned how SessionGraph, ONCE phases, and ROUND phases model a conversation that spans multiple external signals; durability and restart recovery require the durable manager and stores.
Chapter 15 — State Machines introduced explicit lifecycle modeling. You learned how states, event-driven transitions, guards, and timeout rules make status progression visible instead of hiding it inside branch-heavy DAGs.
Chapter 16 — Composing Sessions and State Machines showed how to combine the two runtimes without losing signal ownership or lifecycle clarity. You learned that nested composition is useful but not symmetric, and that the outer runtime must own the main business lifecycle.
Chapter 17 — Putting a Nondeterministic Agent Inside a Deterministic Lifecycle added a bounded tool-use loop. You learned to constrain tools and turn count and to let an explicit graph—not the model— own exit and failure policy.
What You Should Be Able to Do Now
- Decide whether a workflow is best modeled as a graph, a
session, astate_machine, or a deliberate composition of them - Split a multi-turn conversation into
ONCEandROUNDphases with explicit limits and timeout policy - Model a named lifecycle with event-driven, automatic, guarded, and timeout transitions
- Explain which runtime owns signals, recovery, and identity in a nested flow
- Trace nested output paths without flattening away state and phase provenance
Common Mistakes at This Stage
| Mistake | Why It Happens | Fix |
|---|---|---|
Replacing every await with session | Sessions feel like the “more advanced” tool | Use session only when the interaction is truly multi-turn; one suspend/resume boundary still fits a graph |
| Treating state machines like fancy branch nodes | The workflow still “looks conditional” at first glance | Ask whether named states and backward transitions matter to the business model |
Forgetting phase-level max_rounds | The session-level cap looks like it should be enough | Set explicit limits on every real ROUND phase |
| Ignoring ownership in nested composition | Both runtimes seem to offer suspend/resume concepts | Choose the outer owner first; all signals enter through that boundary |
| Assuming nested session and nested state-machine support are symmetric | The surface syntax looks similar | Remember the current constraint: nested sessions inside a state machine must complete synchronously |
Key Vocabulary Additions
| Term | Meaning |
|---|---|
SessionGraph | Immutable definition of a multi-turn interaction made of named phases |
ROUND phase | Phase that resumes per signal payload and can repeat until until matches |
SessionExecutor | Runtime entry point for starting, signalling, restoring, and terminating sessions |
StateMachineDef | Immutable lifecycle definition made of named states and transitions |
| Guarded transition | A transition that fires only when a predicate over state output is true |
| Lifecycle ownership | The rule that the outer runtime owns signals, recovery, and business identity in a nested orchestration flow |
| Bounded agent loop | A tool-use loop with explicit tools, turn limit, exit condition, and graph-owned failure behavior |
Try It: Name the Lifecycle Owner
A support case has a 30-day lifecycle, a four-turn customer conversation, and an agent that may call two tools per turn. Draw three nested boxes and name the owner of case status, conversation round, and tool-loop exit. If two boxes claim the same transition, rewrite the boundary until each decision has one owner.
Where to Go Next
Arc 5 moves from lifecycle models to technical confidence: testing, observability, Spring wiring, and scale. Start with Chapter 18 — Testing Your Graphs.