# Core ideas

A workflow is a saved definition. A run is the record of that workflow doing work, one turn per request, every step written down as it happens.

Trigger: A request arrives → Run: A run holds it → Steps: Steps run in order → Wait: A person decides → Result: The answer

One request through one run. A later request to the same run opens its next turn, with the earlier turns as its history.

## The words

| Word | What it means |
| --- | --- |
| Workflow | A saved definition: the requests it accepts, its steps, the operations they may use and what it returns. It keeps its id when it is renamed or changed. |
| Version | One upload of a workflow, named by the content hash of what was compiled. A turn runs the version that was current when it opened, start to finish. |
| Run | The durable record of one workflow’s work for one owner. A run has no natural end: another request to the same run opens another turn. |
| Turn | One request carried through the workflow, from the request to its answer, a failure or a cancellation. |
| Step | One authored unit of a workflow, written under its kind: ModelCall, ExecuteTool, Branch, ForEach and so on. |
| Operation | Something a step may use, declared once in Operations: a tool, another workflow, or a wait. |
| Wait | A pause for something outside the run, such as a person’s answer. The turn keeps its place until it is answered. |
| Event | One line of the run’s record: a model was asked, a tool answered, a step completed. The engine rebuilds a turn’s state from its events. |

## One engine

Momor Search and every organization’s workflows run on the same engine. Search is the Answer workflow: it calls an Intent workflow to gather sources, then writes the answer. What changes from one workflow to another is the definition: its steps, its tools and where a person decides.

## Everything is recorded

Before the engine does anything outside itself, such as asking a model or calling a tool, it writes down that it is about to. When the answer arrives it writes that too. A turn’s state is rebuilt from those events every time it advances, so a run that stops part-way continues from the first step that did not finish, and a finished step is never run again because a later one was interrupted.

## Models through Gateway

Every model call a workflow makes goes through [Momor Gateway](/docs/gateway/), made by Momor for the organization and paid from its credits, so a Workflow organization needs no Gateway API key. Each AI step can name the models it may use; a step that names none uses the workflow’s `Model`, and a workflow that names none asks for auto: the models the organization lists in Settings › Models, tried in order. Gateway moves to another provider when one fails. The workflow keeps its steps when the models behind it change.

## Four layers of resilience

- **Retries.** Outside calls retry with increasing waits, and stop trying a service that is clearly down.
- **Provider failover.** Each outside dependency can have more than one provider behind it. When one fails after its retries, the next takes over.
- **Model failover.** When a model can’t handle a request or its provider is unreachable, Gateway routes to another that can, skipping models that lack what the request needs.
- **Recovery.** A turn whose attempt fails keeps its record. Resumed, by a caller or automatically, it continues from the first unfinished step.

## Next

- [Workflows and steps](/docs/workflows/workflows-and-steps/): The workflow file, the step kinds and how data moves between steps.
- [Runs and recovery](/docs/workflows/runs/): Turns, their states, and what happens when one fails.