LLM as Periphery
also known as Deterministic-Core LLM-Edge, LLM — это периферия, а не ядро
Invert the typical LLM-in-the-middle architecture: a deterministic state machine and event store form the core; the LLM is restricted to edge tasks — input interpretation and output synthesis only.
Context
An agent system is being designed where some decisions are safety-critical or property-testable (state transitions, threshold enforcement, eligibility, persisted facts) and others are inherently interpretive (free-text classification, summary generation, ambiguous intent parsing). The default architectural reflex is to place the LLM at the centre of the loop and call code from it. The author of the Habr write-up that surfaced this shape argues the default is inverted: the LLM should be the periphery, not the core.
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.
Forces
- LLM strengths (interpretation, synthesis) and weaknesses (state, exact rules, repeatability) point at different parts of the system; one architecture cannot serve both.
- State held inside an LLM context cannot be property-tested; state held in code can.
- Centring the LLM gives developer velocity early; the cost shows up later as untestability and ripple-regressions.
- Inverting the default requires more upfront design — most frameworks assume LLM-at-the-centre.
Example
A self-knowledge assistant could be built LLM-first: the LLM holds conversation state, decides when to advance the user's reflection week, and writes summaries. Instead the author built it inverted: a deterministic Stability Engine holds session state, an Event Core stores every user answer as an immutable typed event, and the LLM is called only at two edges — to turn the user's free-text answer into a typed event, and to synthesize the next probing question from the current event-store state. Crisis detection, threshold enforcement, and session advancement live in code with property-based tests. An LLM regression changes only the phrasing of questions or the parsing of answers; it cannot move the user backwards in the protocol or skip a safety check.
Diagram
Solution
Therefore:
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.
What this pattern forbids. Forbids the LLM from holding state, performing state transitions, or making safety-critical decisions. The LLM is restricted to typed-input, typed-output edge transformations.
The smaller patterns that complete this one —
- usesEvent-Driven Agent★★— Trigger the agent on external events (webhooks, message queues, file changes) instead of user requests or schedules.
- usesAppend-Only Thought Stream★— Make the agent's thought log append-only so the agent cannot rewrite its own history.
- usesJSON-Only Action Schema✕— Anti-pattern: restrict the agent's action language to JSON tool-call dictionaries even for tasks where code-as-action (functions composing, loops, conditionals over results) would be the natural shape.
- generalisesSubject-First Agent Architecture (ENA Stateful Core)·— Invert the LLM-centric pipeline: the agent is a stateful subject whose decision logic chooses whether to invoke the LLM at all, treating the model as one tool among many.
And the patterns that stand alongside it, or against it —
- complementsDeterministic-LLM Sandwich★— Bracket every LLM call with deterministic checks on both sides.
- complementsWorld-Model Separation★— Maintain an explicit, surprise-updated model of the environment (humans, repos, services, capabilities) in a separate file from the agent's self-model, so the two cannot be confused or co-mutated by reflection.
- complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
Neighbourhood
Click any neighbour to follow the language. Scroll to zoom, drag to pan.