# Presenting Vario — Structure Guide

## Core Narrative Arc

### 1. A modern LLM call, in vario language

Show what the audience already knows — a single LLM call — but describe it using vario's abstractions. Make the familiar strange:

```
produce(n=1, model=sonnet) → done
```

That's it. One Item in, one Item out. No scoring, no comparison, no quality signal. Point out what's implicit:
- **Sequential**: you wait for the full response before you can do anything
- **No provenance**: you got text back, but no metadata about confidence, cost, or alternatives
- **No quality signal**: was this the model's best effort? Its worst? You have no idea
- **No fallback**: if it's bad, start over manually

This isn't a criticism — it's just describing the mechanics. The audience should nod along.

### 2. The same language, strictly more powerful

Now extend — using the exact same vocabulary (produce, score, reduce, Item, props):

```
produce(n=5, models=[sonnet, gemini, grok]) → score(rubric) → reduce(top_1)
```

Nothing new was invented. We just:
- Changed n from 1 to 5
- Added a scoring step
- Added a selection step

The language was always capable of this — a single call was just the degenerate case. Every improvement is a parameter change or an additional pipeline stage, not a new concept.

### 3. Everything falls out naturally

Once you have the pipeline model, advanced capabilities aren't features to be explained — they're consequences:

| Capability | How it falls out |
|---|---|
| **Multiple models** | `produce(models=[...])` — change a parameter |
| **Anytime best answer** | Heap — Items scored as they arrive, best always readable |
| **Iterative refinement** | `repeat(score → revise)` — another stage in the pipeline |
| **Corpus processing** | `source(dir) → fan_out(models) → task → evaluate` — Items are Items whether 1 or 10,000 |
| **Real-time self-monitoring** | Context tracks spent/limits; repeat checks convergence — the pipeline observes itself |
| **Effort control** | Budget limits, stop conditions, recipe selection — all pipeline parameters |
| **Debate/consensus** | `reduce(method=vote)` or `reduce(method=consensus)` — a reduce variant |
| **Provenance** | Item.history accumulates automatically — every op adds what it did |

None of these required new primitives. They're all compositions of: produce, score, revise, reduce, source, fan_out, task, evaluate, repeat.

## Why This Framing Works

- **No jargon wall**: audience starts with what they know
- **No "problem statement" needed**: you're not arguing something is broken — you're showing a natural generalization
- **The power is in the composability**: each piece is simple, the insight is that they compose
- **Self-evident value**: once you see `produce(n=5) → score → top_1`, you immediately understand why it's better than `produce(n=1)` — you don't need to be convinced
- **Invites exploration**: audience thinks "what if I changed *this* parameter?" which is exactly the right reaction

## Presentation Flow

1. **"Here's how you use an LLM today"** — single call, in pipeline notation
2. **"Here's the same notation, with one number changed"** — n=5, and now you need scoring
3. **"Add scoring, and now you have quality signal"** — the first non-obvious win
4. **"Add selection, and now you have the best answer"** — best_of_n recipe, ~$0.03
5. **"Everything else is just more stages"** — show the capability table above
6. **Live demo**: `vario ab math haiku --strategy best_of_n --sample 5` — vario evaluating itself
7. **Vision**: the recipe becomes emergent — you specify quality criteria, not process

## Anti-Patterns to Avoid

- Don't start with "the problem with single LLM calls" — that's adversarial framing
- Don't enumerate features — show how they fall out from the model
- Don't compare to LangChain/DSPy first — that's defensive positioning
- Don't show the architecture diagram early — nobody cares until they care about the idea