Offline Verifiable Support Runtime

Compile customer-support intelligence into a runtime, not a chatbot.

Use frontier AI offline to analyze support policy, tickets, tools, and workflows. Then compile a domain-specific runtime that executes cheaply, quickly, and verifiably.

Try the Runtime Simulator Explore the Compiler Model See Verification Gates
From frontier reasoning to specialist support runtime offline → online
Input Support assets Policies, SOPs, historical tickets, APIs, macros, constraints.
Compiler Frontier AI offline Discovers task structure and drafts DSL, tests, and runtime candidates.
Language Controlled DSL SupportFlow English parsed by ANTLR, Bison, or equivalent.
Assembly Runtime stack Rules, slots, small extractors, search, APIs, traces, fallbacks.
Output Verified execution Owned support infrastructure instead of rented runtime cognition.
The model

The LLM is the compiler engineer.

The LLM performs high-cost synthesis outside the customer request path. Production traffic uses the compiled runtime, which can be tested, traced, replayed, and versioned.

Stage 1

Compile the support agent

Infer intent taxonomy, slot schema, action inventory, escalation classes, and policy boundaries from support assets.

Stage 2

Compile the runtime

Generate a parser-valid DSL, typed IR, tool adapters, rule engine config, response templates, and test corpus.

Stage 3

Deploy with gates

Reject any runtime candidate that fails syntax, type, policy, replay, latency, trace, or fallback checks.

Architecture

Two loops, one runtime.

Offline compilation produces the support runtime. Online execution converts customer language into typed state and evaluates deterministic flow rules.

Offline compilation loop Online execution loop Support assets SOPs · tickets · APIs LLM compiler discover · design DSL parser ANTLR / Bison Typed IR AST · schema · rules Verified Support Runtime slots · rules · actions · responses · traces · fallbacks Customer text free-form message Extractor intent · entities Runtime state slots · facts · history Rule execution collect · call · say APIs CRM · order Fallback LLM · human Trace evidence log Hot path: customer message → extractor → typed state → compiled runtime → action / response / escalation
Controlled language

Natural enough to author. Strict enough to compile.

The DSL is intentionally less expressive than English. Ambiguity is a compile error, not a runtime improvisation.

SupportFlow Englishsource — see policy.sfr
support domain "commerce".
intent "refund_request" means user asks for a refund.
slot order_id is text matching "[A-Z0-9-]{6,}".
slot refund_reason is one of "damaged", "late", "wrong_item".
action lookup_order requires order_id returns order.
action create_refund requires order_id, refund_reason returns refund.
flow "refund order" starts when intent is "refund_request".
collect order_id by asking "What is your order number?"
collect refund_reason by asking "Why are you requesting a refund?"
when order_id is known then call lookup_order with order_id.
when order.age_days <= 30 and refund_reason is "damaged"
  then call create_refund with order_id, refund_reason.
when refund.status is "approved"
  then say "Your refund of {refund.amount} has been approved." and close.
otherwise escalate to human with priority normal because "manual review".
Typed IRcompiled → runtime.js
{
  "domain": "commerce",
  "flow": "refund order",
  "start": { "intent": "refund_request" },
  "slots": {
    "order_id": { "type": "text", "pattern": "[A-Z0-9-]{6,}" },
    "refund_reason": { "type": "enum" }
  },
  "rules": [
    {
      "if": { "op": "known", "ref": "order_id" },
      "then": [{ "type": "call", "action": "lookup_order" }]
    },
    {
      "if": {
        "op": "and",
        "args": [
          { "op": "lte", "left": "order.age_days", "right": 30 },
          { "op": "eq", "left": "refund_reason", "right": "damaged" }
        ]
      },
      "then": [{ "type": "call", "action": "create_refund" }]
    }
  ]
}
Verification

No black box in the covered path.

Every deployed runtime carries its parser, schema, tests, traces, thresholds, and replay set. Failures become compiler input for the next version.

GatePurposeReject when
Syntax ANTLR/Bison accepts only declared sentence forms. The DSL uses unsupported wording or ambiguous structure.
Types Slots, fields, actions, and response variables resolve to declared schemas. A condition compares strings to numbers, calls unknown actions, or interpolates missing values.
Policy High-risk actions require explicit authorization rules and limits. Refund, cancellation, account, PII, or credit actions lack guardrails.
Replay Historical and synthetic conversations reproduce expected outcomes. Actions, messages, escalations, or traces diverge from gold cases.
Trace Every answer is linked to state, rule match, source policy, and tool result. The runtime cannot explain why it acted.
Boundary

Use frontier models at the edges, not everywhere.

The runtime handles covered cases. The LLM handles authoring, extraction, exception triage, synthetic eval generation, and offline recompilation.

Good LLM work

Offline or fallback path

Read policies, propose flows, generate tests, extract entities, summarize escalations, diagnose drift, and propose DSL patches.

Good runtime work

Hot production path

Evaluate typed state, apply rules, call APIs, send approved responses, create tickets, close cases, and emit traces.

Treat the LLM like a compiler engineer that builds a custom support machine. Ship the machine, not the compiler, into the latency-sensitive path.