Deterministic core llm judgment

Deterministic Core, LLM Judgment

An agent where the LLM is the backbone fails when the LLM hallucinates, drifts, is unavailable, or costs too much. An agent where the deterministic duties are the backbone always runs and the LLM only adds judgment on top. If the LLM is off, the work still happens; if it's on, the work is better. This is the robust agent architecture.

The split

• Deterministic core (load-bearing, always executes): the duties that must happen every run regardless of LLM availability — fetching the queue, snapshotting state, computing metrics, writing the run log, surfacing blockers. Pure code, no LLM calls. Testable, auditable, no hallucination.
• LLM judgment layer (additive, optional): the parts where judgment helps — ranking the next experiments, curating new sources, summarizing for a digest, flagging collapse alerts. The LLM is called after the deterministic core has gathered the facts, and its output is used to enhance, not to gate.

The principle

Deterministic duties are load-bearing and always execute; the LLM adds judgment only.

Consequences:

• LLM off → agent still useful. The deterministic tick still runs, still logs, still surfaces. You ship the agent before you have API access.
• LLM hallucination → bounded damage. The LLM can't break the load-bearing work; it can only make a bad ranking or a wrong summary. The deterministic state is still correct.
• LLM cost → optional. You can run the deterministic core every tick and the LLM layer only when the budget allows.
• Auditability → intact. The deterministic transcript shows what actually happened; the LLM transcript shows what it suggested.

How to build it

1. List the duties. What must happen every run? Those are deterministic — pure code, no LLM.
2. List the judgment calls. Where would ranking/curation/synthesis help? Those are the LLM layer — called after the facts are gathered.
3. Gate the LLM layer behind a flag + a key. if LLM_ENABLED: ... — the agent runs either way. The key is the one user-only input.
4. Keep the LLM additive-only. The deterministic duties don't read LLM output to decide whether to run. The LLM reads deterministic output to decide what to suggest.
5. Test the deterministic core offline. The eval gate runs fully offline (no network, no LLM) — that's the proof the core is load-bearing. Wire it into CI.

Anti-patterns

• LLM-as-backbone. The agent's core work is an LLM call. When the LLM is wrong, the work is wrong; when it's down, the work stops.
• LLM gates the deterministic work. "If the LLM says it's worth doing, do the tick." The LLM is now a single point of failure for the load-bearing work.
• No offline mode. The agent can't run without an API key → can't ship, can't test in CI, can't run in a budget-constrained env.
• Untestable core. The deterministic duties are tangled with LLM calls so you can't verify them without the LLM.

Pair with

• agent-guardrails — the deterministic core is what makes bounded loops safe (the agent does its work and stops, doesn't freewheel).
• validate-gate — the offline eval gate is the proof the core is load-bearing.
• fill-the-wait — the deterministic tick is a perfect fill task (no LLM, no network, always useful).