Introduction

LADR vs. Alternatives

Comparison of LADR to other tools that orchestrate multi-step LLM execution. The axis of comparison is not feature count but where execution lives: in imperative application code, in a programmatic framework, or in a declarative runtime.

Summary

Tool	Paradigm	Execution location	Memory model	Spend control
Raw OpenAI client	Imperative in-app code	Caller process	None	None
LangChain	Imperative Python chains	Caller process	Per-chain state	None enforced
LlamaIndex	Imperative, retrieval-centric	Caller process	Index + docstore	None enforced
DSPy	Programmatic prompt optimizer	Caller process (training)	Training set	N/A (training time)
instructor / BAML	Structured-output extractor	Caller process	None	None
LADR	Declarative YAML, runtime-bounded	Redeo runtime	Slates	Runtime-enforced ceilings

The key distinction is where execution lives. In LangChain and raw API code, the caller's process owns the loop — spend limits are advisory, termination is the developer's responsibility. In LADR, the runtime owns the loop. Budget enforcement is structural, not conventional.

LADR vs. LangChain

LangChain provides Python primitives (chains, agents, tools) composed imperatively. LADR provides a YAML schema executed by the Redeo runtime.

Concern	LangChain	LADR
Sharing	Ship a Python package with dependencies	Share a single YAML file
Spend cap	Caller-side code; bypassable by bugs	Runtime-enforced; not bypassable
ToT authoring	Typically 100+ lines of Python	~30 lines of YAML
Caller integration	Caller imports LangChain	Caller uses any OpenAI client
Custom tool calls	Supported	Not supported
Arbitrary Python logic	Supported	Not supported by design

Use LangChain when the workflow needs arbitrary Python tool calls or is tightly coupled to an existing application. Use LADR when the workflow is a reasoning strategy that should be shared, versioned, and budget-bounded.

LADR vs. DSPy

DSPy and LADR solve different problems and compose cleanly.

DSPy searches the space of prompt phrasings and few-shot examples given a training set and a metric. Its output is a better one-shot prompt. DSPy operates on what each call says.

LADR declares the structure of a multi-step search. Its output is a runtime strategy. LADR operates on how calls compose.

The two layers are orthogonal. A typical production setup: DSPy tunes the system prompt for each step's role; LADR composes the steps into a strategy. The DSPy-tuned prompt becomes the literal value of systemPrompt: on each step.

Question	DSPy	LADR
Is the prompt phrasing optimal?	Yes, DSPy searches prompt space	No, LADR takes prompts as given
Should I draft N and pick the best?	No	Yes, that is a Tree-of-Thoughts ladder
Will the pipeline cap spend at X dollars?	No	Yes, via `executionBudget.maxSpend`
Does the strategy persist across calls?	No, DSPy output is a tuned prompt string	Yes, slates persist across invocations

LADR vs. raw OpenAI calls

A raw OpenAI call:

python

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}]
)

A ladder call:

python

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}],
    base_url="https://api.redeo.ai/v1/{author}/{ladder}"
)

Same request shape. Same response shape. The difference is what runs server-side: a raw call is one LLM invocation; a ladder call is a multi-step execution with gates, parallel fan-out, persistent memory, and a hard spend ceiling.

The trade-off is straightforward. A ladder is slower (more LLM calls in series or parallel) and more expensive (more tokens consumed) than a raw call. Use a ladder when answer quality justifies the cost; use a raw call when a single response is sufficient.

LADR tradeoffs

LADR is opinionated. The tradeoffs:

Declarative means less flexible. A ladder cannot express arbitrary logic. If a workflow requires inline Python functions, custom database queries, or arbitrary side effects, use a different tool. Dynamic steps let the ladder rewrite parts of its own config at runtime, but the rewritten config is still YAML within the LADR grammar.
Runs on the Redeo runtime. A ladder executes inside the Redeo runtime (or a self-hosted LADR instance). It cannot run inside an arbitrary Python process.
A new vocabulary. LADR is a small language, but it is still a language. The grammar is documented under Language.
YAML authoring. LADR configs are YAML. Foundry provides a visual editor that emits YAML, so direct YAML authoring is optional.
Retrieval is keyword-based. retrieve: is keyword, metatag, path, and glob based. Semantic-similarity retrieval is planned. For workloads that require semantic retrieval today, slates are not yet a complete replacement for vector RAG.