Inside the Liminal harness — architecture for real coding sessions

Chat products optimize for conversation. Liminal optimizes for finishing work — multi-step tool use, partial failure, context limits, and human approval on destructive actions.

The ReAct loop#

Each user message starts a send() run:

1. Intent + reasoning budget — fast model classifies the turn; harness picks effort and whether to route to fast or main.
2. Completion — model returns text and/or tool calls.
3. Dispatch — validate args, safety pre-flight, acquire locks, approval if needed, execute, record output.
4. Context — hot rounds stay verbatim; older tool output compresses or distills to artifact pointers.
5. Repeat until the model answers or limits hit.

User → Intent (fast) → Main model → Tool(s) → Context update → Main model → … → Answer

Tool dispatcher#

Tools aren't fire-and-forget. The dispatcher:

• Validates JSON schema for every call
• Locks resources (file:read:, file:write:, shell:) in sorted order to prevent deadlock
• Approves destructive tools unless YOLO or safety judge clears them
• Distills huge outputs to .agent_artifacts/ so context stays usable

Context tiers#

Harness rules inject at round 2 — recipes from past successful turns, failure digests, golden eval hints.

Recovery#

Production agents fail. Liminal plans for it:

• Retries — rate limits and 5xx with exponential backoff and wall-clock caps
• Provider circuit — opens after repeated failures
• Length-resume — streamed writes can resume from staging manifests
• Reflection memory — all-tool-failure rounds auto-write reflection: notes

Sub-agents#

spawn_agent forks a child harness with a copied registry (minus parent-scoped tools). Children get their own context and epistemic state — useful for parallel research or isolated edits.

— The Vireon Dynamics team