LLM as Periphery

Problem

When the LLM holds state and orchestrates transitions, every state mutation is non-deterministic, every safety-critical decision is unverifiable, and every regression in the LLM ripples through the whole system. The decision the Habr author reached after building a self-knowledge bot: keep all state transitions, thresholds, and safety-critical decisions in explicit, property-tested code; use the LLM only at the edges where its strengths (interpretation, synthesis) match the task. Distinct from the existing deterministic-llm-sandwich pattern (which wraps a centrally-placed LLM in deterministic gates): here the deterministic component is canonical and the LLM is auxiliary.

Solution

Place a deterministic state machine and an event store at the core. Decisions about state transitions, threshold checks, and persistence happen in explicit code with property-based tests. The LLM is invoked at well-defined edges: interpreting free-text input into a typed event, synthesizing user-facing text from a typed state, classifying ambiguous inputs into a known taxonomy. The LLM is stateless across edges; the event store is the only state. New LLM calls re-read from the event store and produce edge outputs that get written back as typed events.

When to use

• Systems where some decisions are safety-critical or property-testable and others are interpretive.
• Agents that need full replayability and audit of state transitions.
• Teams comfortable with event-sourced / state-machine design and willing to pay the upfront design cost.
• Products where LLM-cost or LLM-regression risk is high and bounding it to edges is worth the design effort.