Cross-Extension Composition

BLOGE extensions can compose because each extension lowers into runtime models that still cooperate with the core engine. The goal is not to let every construct nest everywhere; the goal is to make specific mixed workflows explicit and recoverable.

Supported Direction

Current source supports sessions and state machines composing with each other:

• a session phase can embed a state_machine
• a state_machine state can embed a session

Agents can also appear in extension-owned scopes when the provider declares the scope and the required runtime operators are present.

Example

session support {
  phase triage {
    state_machine escalation {
      initial = bot

      state bot {
        on handoff -> human
      }

      state human { final }
    }
  }
}

Composition Rules

Rule	Why
Keep one dominant lifecycle	Prevents readers from losing the owner of progress
Avoid mixed sibling execution inside sensitive extension scopes	Keeps suspension and resume behavior tractable
Prefer durable bridges before production use	Nested long-running state needs restart-safe checkpoints
Make signal ownership explicit	Signals should route to the correct session, state, or graph node
Keep migration paths documented	Extension content hashes and graph versions can drift independently

Design Guidance

Use composition when the domain really changes mode. A support interaction may start as a session, enter a state machine for escalation, and return to the session. That is a real model shift.

Do not compose extensions just to reuse syntax. If the workflow is still a normal DAG, keep it as a graph. If it is only a rule table, use a decision table. If it is only repeated work, use foreach or loop.

Next Steps

• Understand sessions in Sessions.
• Understand state machines in State Machines.
• Understand agents in Agents.