Extension SPI Overview

BLOGE extensions add higher-level orchestration constructs without turning the core DSL into a hard-coded list of product features. An extension owns its syntax, semantic compiler, runtime model, nested operator bridge, and lint behavior.

Current First-Class Extensions

Extension	Module	Runtime model
Session	bloge-session-ext	Session, phase, round, signal, snapshot
State machine	bloge-state-ext	State, transition, signal, timeout, checkpoint
Agent	bloge-agent-ext	LLM loop, tools, memory, trace events, streaming chunks

Durable concerns are intentionally split into dedicated bridge modules:

Durable bridge	Module
Durable sessions	bloge-session-durable
Durable state machines	bloge-state-durable

Extension Responsibilities

Responsibility	What it means
Syntax provider	Registers extension keywords and scopes through DslExtensionProvider
Semantic compiler	Lowers generic extension AST into a concrete runtime definition
Nested operator factory	Lets an extension embed or be embedded inside another graph-like construct
Runtime executor	Owns extension-specific lifecycle, signals, memory, or transitions
Lint contributor	Adds static rules for extension-specific traps
Durable bridge	Persists checkpoints and handles recovery when the extension is long-running

Why This Boundary Matters

The extension model keeps the base DSL small while allowing BLOGE to grow into conversational, event-driven, and agentic orchestration. The core engine still sees executable graph nodes, suspendable operators, events, checkpoints, and results.

That boundary prevents two common failures:

• pushing every advanced workflow concept into bloge-core
• treating extensions as separate runtimes that cannot share durability, observability, or tooling

Next Steps

• Model conversations with Sessions.
• Model event-driven lifecycles with State Machines.
• Build LLM loops with Agents.
• Combine extension types with Cross-Extension Composition.