momor.ai
Open Search
DocsOpen Workflows
Get started / Core ideas

Get started

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.

  1. TriggerA request arrivesAPI key or signed-in person
  2. RunA run holds itOne turn per request
  3. StepsSteps run in orderEvery one recorded
  4. WaitA person decidesWhen a step asks
  5. ResultThe answerKept with the run
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

WordWhat 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, 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

Updated Oct 22, 2026
Esc