How Omazy runs CX work — three flow types, one harness, one tool registry. Skills, not graphs.
Different shapes of work need different execution models. We ship all three. Pick by complexity + cost — not by team preference.
ONE LLM CALL
Customer asks → bot answers
A single LLM invocation against grounded context (persona + KB excerpt + recent thread). No tool loops, no branching, no memory writes.
WHERE
Default for /chat replies that don't need external lookups.
$ — cheapest, ~500ms median, sub-3s SLA
RFC 2202 CHAIN
Event → match → run actions in order
Imperative actions[] chain. Strict ordering, no LLM reasoning, no branching. Each action is a Go handler.
WHERE
When you know exactly what should happen — strict ETL, compliance flows, fixed notifications.
¢ — near-zero compute, no LLM tokens
RFC 2203 HARNESS
Skill describes intent → LLM picks tool calls
Markdown skill file + frontmatter. Harness loop builds context, calls LLM, executes tool calls, repeats until the LLM emits a final reply.
WHERE
CX work that benefits from reasoning, memory, branching, tone — chat, autopilot triage, operator copilot.
$$ — LLM cost per call, ~2–15s, budget-capped
Definition · grounded context
Persona (agent system prompt) + knowledge-base excerpt (top-k retrieval against bot_documents) + recent thread. Built fresh per call. No agent memory, no tool calls.
Why no tool loop here
90% of replies are pure Q&A. A tool loop adds latency (2nd round-trip ≈ +1.5s) and cost without changing the answer. When intent NEEDS a tool (lookup_order, refund), chats escalates the same request to the harness in user_chat mode — same code path, switched on intent classification.
Engineering decision · cache the system prompt
Persona + KB excerpt is mostly static across a session. Anthropic prompt-caching keeps it warm — first-token latency drops ~40% on cache hits. Cache-invalidate on KB reindex.
SLA budget
First token < 1s · full reply < 3s · 99p < 8s (measured per-app; budget alarms at p95 breach).
Definition · deterministic
Same event + same rule = same action chain executed in the same order. No reasoning. Failure modes are predictable (network errors, idempotency violations) — not "wrong tool".
Why a flat array (not a graph)
95% of automation rules in CRM/CX are 1–4 steps in linear order: "send email, assign, tag, escalate." A graph builder for that is yak shaving. The DAG sketch (RFC 2202 §15) is kept on the shelf for ETL-style flows where branching/data-passing matter — not for CX automations, where the LLM harness (Flow C) is a better fit when complexity grows.
Engineering decision · server-side filtering
Filters (app_handles, tags) eval in Publisher.Publish BEFORE Asynq enqueue. A workspace with 50 rules where 2 match → 2 tasks queued, not 50. Queue depth is a real cost; filter eval is one indexed JSONB query.
Engineering decision · skipped ≠ failed
Stub action handlers return StepStatusSkipped (not failed). Run aggregates as "succeeded" if all real steps succeed, letting operators ship full chains today.
↻ THE HARNESS LOOP
internal/harness/runner.go
load ctx → pre_run → LLM call → tool calls →
post_tool → ( back to LLM call ) → post_reply → done
max_steps=10 · budget enforced · every step traced
Definition · agentic harness
A loop that calls an LLM with tool definitions, executes the tools the LLM picks, and feeds results back until the LLM emits a final answer. Same shape as Claude Code, OpenAI Agents SDK, Cline.
Why one harness, three modes
user_chat / autopilot / business_assist all share the SAME loop. They differ in which skills are loaded, which tools are exposed, which guardrails apply, whose identity is on the wire. Mode is config — not a separate codebase. Cuts duplicated tool-handler/trace/budget plumbing by 3×.
Why instructions, not graphs
Skill = markdown + YAML frontmatter ("when VIP session opens, greet warmly + route + ping #vip"). LLM reads it, picks tool order. n8n/Flowise solve a 2020 problem (operators couldn't code) — in 2026 operators describe intent in English and an LLM picks tools. Graphs are for ETL, not CX.
Engineering decision · explicit memory R/W
Memory is read/written through tools (memory_read, memory_write), never silently injected into the prompt. Auditability: trace shows exactly which memories shaped the output. Bounded context: LLM picks what it needs, not an opinionated retriever stuffing 8K tokens.
Engineering decision · capability boundary
Tools — not the LLM — enforce permissions. Even if the LLM "tries" to call a forbidden tool, the registry rejects and returns a structured error. Capabilities are the security perimeter, not prompt instructions.
Engineering decision · max_steps budget
Default 10 LLM-calls per run. Pre-tool hook rejects redundant calls (same args twice). Trace surfaces step explosion. Stops runaway loops cold.
instruction store
always-on guardrails
explicit R/W
callable capabilities
CONTEXT PACK
typed Go struct · built fresh per run
↻ THE HARNESS LOOP
internal/harness/runner.go
load ctx → pre_run → LLM call → tool calls →
post_tool → ( back to LLM call ) → post_reply → done
max_steps=10 · budget enforced · every step traced
driver pattern
extension surface
append-only
security perimeter
CUSTOMER-FACING
BUSINESS BACKGROUND
OPERATOR COPILOT
SOURCES
docs/rfc2202-automations.md · docs/rfc2203-agentic-harness.md · docs/rfc2201-platform-core.md · docs/design/agentic-infographic.pen Engine: Go + Anthropic SDK · Asynq · Postgres + pgvector · OpenSearch (search + vector) · ClickHouse (trace analytics) · Redis · R2 · MCP gateway (RFC 1900). No new infra primitives.