Deterministic execution for AI systems

LLMs plan.
Code executes.

Most AI systems run inside the LLM loop — think, act, observe, repeat. The LLM is in the critical path for every step.

That makes execution non-deterministic, expensive, and impossible to audit.

RiteSmith breaks the loop: the LLM plans once, RiteSmith defines the system, and Trama executes it deterministically.

LLM / Agent → understands intent
RiteSmith → generates the system
Trama → executes it reliably
decide → define → execute

The LLM decides once. Execution no longer depends on it.

Generated systems are reusable

RiteSmith does not regenerate systems every time. It searches existing artifacts first and only generates when needed.

Powered by Trama
User intent received
{
  "intent": "process order refund",
  "constraints": { "requires_approval": true }
}
LLM planner reasoning
[
  "validate_request",
  "check_policy",
  "refund_payment",
  "notify_user"
]
Ritesmith forging workflow
Validate Policy Refund Notify
Trama execution durable
Validate Policy Retry refund Notify
Reliable result completed
{
  "status": "completed",
  "traceable": true,
  "recoverable": true
}

The problem with pure AI agents

LLMs are powerful, but they are not execution engines. Putting them in the critical path of every step creates systems that are hard to reason about, expensive to run, and impossible to audit.

No system boundary

Execution is non-deterministic — the same input can take different paths every run.

No persistent record

State lives in prompts. There is no versioning, no artifacts, no audit trail.

LLM cost on every step

Logic is recomputed on every call instead of being generated once and reused.

Token cost tells the whole story

Both approaches complete the task successfully. The difference is what it costs. An LLM loop re-sends the full context on every API call — tokens compound. RiteSmith generates the workflow once; Trama runs it without touching the LLM again.

LLM + MCP tools loop
① [system prompt + tool schemas] loaded into context 4,500 tok
② [MCP] search_artifacts("refund workflow") → no results +1,050 tok 7s
↳ thinking… no match, try a web search +320 tok
③ [MCP] web_search("enterprise refund SLA policy") → 8 snippets +2,280 tok 9s
↳ thinking… too generic, need internal policy doc +290 tok
④ [MCP] read_file("policies/refund.md") → 2,600 words +3,380 tok 11s
↳ thinking… must validate against live order +240 tok
⑤ [MCP] orders_api.get(…) → 200 +680 tok 8s
⑥ [MCP] payments_api.check(…) → approved +680 tok 9s
↳ thinking… synthesizing, generating refund decision +2,100 tok 14s
~60,000
tokens billed  ·  context re-sent each API call
~58s
median latency
RiteSmith + Trama
① [ritesmith:search_artifacts] "refund workflow" ~1,100 tok 2s
✓ artifact found  refund-workflow v3 (Trama workflow) 180 tok
② [trama:execute] workflow=refund-workflow-v3 ~400 tok 3s
✓ orders-api  GET /order/… → 200  (Trama runtime) 0 tok
✓ payments-api  POST /refund → approved 0 tok
✓ notification-api  POST /alert → sent · workflow complete 0 tok
first run — no artifact yet
③ [ritesmith:plan] intent → semantic plan (measured, 0.2.0) ~6,600 tok 7s
✓ compiled + validated  loops, joins, state → Trama workflow, by code 0 tok
✓ artifact saved  refund-workflow v3 · reused on all future runs
ALT if step fails → Trama returns structured failure to RiteSmith — no blind LLM retry
first run
~7,700 tok
latency
~12s
on repeat
~1,500 tok
latency
~5s
~8× fewer tokens on first run  ·  40× fewer tokens on repeat. The workflow runs in Trama's runtime — the LLM is not in the loop.

Generation got 3× cheaper in 0.2.0

The model now writes a short semantic plan, and RiteSmith compiles loops, joins, state and continuation into the Trama workflow with code. The model writes less, and it makes fewer mistakes in the part that used to break.

Tokens per valid workflow
20,785
6,646
3.1× fewer
Cost per valid workflow
$0.0153
$0.0043
3.6× cheaper
Workflow generation, median
20.1 s
7.3 s
2.8× faster
Valid on first request
70% workflows
77%
Luau scripts: 94%, 5.2 s, 2,910 tok

Same 51-task corpus (31 Luau scripts, 20 Trama workflows), gpt-5-mini at low effort, three runs per task: the October 8 baseline compared with 0.2.0 (October 10, 2026). Token and cost figures include failed attempts and repairs and are divided by valid artifacts. Running the workflow afterwards uses no LLM tokens unless a step calls an LLM capability. Method and raw results.

Planning is not execution

Ritesmith keeps the intelligence where it belongs: in planning. Execution remains deterministic, observable, and recoverable.

Pure LLM agents

Flexible, but unpredictable.

Static workflows

Reliable, but rigid.

Ritesmith

Adaptive planning with deterministic execution.

How Ritesmith works

The LLM submits an intent. RiteSmith generates the execution system. Trama runs it with retries, state, callbacks, compensation, and observability.

1. Intent

The LLM understands the goal and submits it to RiteSmith.

2. Generate

RiteSmith searches existing artifacts first. When something is missing, the LLM writes a short semantic plan (calls, waits, conditions, parallel branches, bounded loops). RiteSmith compiles that plan into a Trama workflow and writes missing logic as strictly type-checked Luau scripts. Everything is validated before it is registered.

3. Execute

Trama runs the workflow with retries, state, sleep, callbacks, and observability. The LLM is no longer in the loop.

Powered by Trama

Ritesmith does not reinvent orchestration. It builds on top of Trama, a lightweight saga orchestrator for reliable distributed workflows.

What Trama provides

Durable workflow state, retries, compensation, callbacks, observability, and production-grade execution semantics.

The forge behind predictable AI systems

Ritesmith is built around a simple principle: intelligence should design the path, but reliable infrastructure should execute it.

Ritesmith forge illustration

Build predictable AI systems

Use LLMs where they shine: reasoning, planning, and adaptation. Keep execution reliable, auditable, and controlled.

Get started on GitHub