Production agents need two layers: a flexible front door for language, and a deterministic engine for operations that must not be wrong.
Layer 1 — Etch (orchestrator)
Etch is a small LLM-backed agent. Its job is narrow: understand what the user wants, pick the right tool, pass context, and write a human-readable answer from structured expert output. It should not compute margins, match invoices, or scan inventory itself — it delegates.
In this demo Etch runs on a Novella-tier model. That adds latency and token cost to every turn, but the expert portion of the work — the part that touches money, inventory, and compliance — stays deterministic.
Layer 2 — Etch SDK experts
Each expert is a Python program: a graph of tools (GLC API calls, parsers, aggregators) with scripted reasoning strings emitted between steps. The Etch SDK streams those events so the UI renders them like LLM thoughts. When the expert finishes, it returns JSON (order facts, match verdicts, KPI tables) that Etch weaves into prose.
User message
│
▼
┌─────────────┐ tool call ┌──────────────────┐
│ Etch │ ─────────────────► │ Expert (SDK) │
│ (LLM UI) │ ◄───────────────── │ deterministic │
└─────────────┘ JSON + trace └────────┬─────────┘
│
▼
GLC microservices
(orders, AP, inventory…)
Why split the layers?
- Language is fuzzy; operations are not. Customers write messy emails. GLC invoice totals are exact.
- Trust boundaries. Finance and ops teams need line-by-line traces, not “the model said so.”
- Economics. One LLM call to route and narrate beats twenty LLM calls to guess API payloads.
The founding letter puts it simply: the LLM is the editor; the expert is the engine. This demo lets you watch both run in real time.
Next: General Logistics Co (the mock company behind the APIs) and the Expert catalog.