> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duraton.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Durable runs

> The durable runtime under every Duraton agent and job: workflows, steps, triggers, retries, flow control, runners, and the live run record.

This page is for the code path - the durable runtime underneath, in TypeScript. To build an agent
without code, start with [Build your first agent](/start/first-agent).

Everything in Duraton - an AI agent, a nightly job, a webhook handler - is a **workflow**: an ordinary
TypeScript function whose units of work are wrapped in **steps**. Duraton records each
step's result the moment it completes. That one rule is what the rest of the platform is built on: a
crash, restart, or deploy resumes the run at the next step instead of starting over; a step that waits
on a person or a timer holds no worker while it waits; and the record of what ran, in what order, with
what result, exists before anyone asks for it.

This tab is that runtime. It reads the same whether or not there is a model call in the handler - the
AI-specific steps are in [AI](/ai), and the agent authoring layer in [Agent kit](/agent-kit).

## The pieces

| Piece        | What it is                                                                         | Read                                           |
| ------------ | ---------------------------------------------------------------------------------- | ---------------------------------------------- |
| **Workflow** | A named function, triggered by an event, a schedule, or by hand.                   | [Workflows](/core/workflows)                   |
| **Step**     | One durable unit inside a handler. Runs once, result recorded, retried on its own. | [Steps](/core/steps)                           |
| **Run**      | One execution of one workflow, with its own status, steps, logs, and output.       | [Watching a run](/core/realtime)               |
| **Event**    | The message that starts a run. Persisted, and can fan out to many workflows.       | [The event log](/core/workflows#the-event-log) |
| **Runner**   | Your process, holding your workflow code. It dials out with `connect()`.           | [Runners](/core/runners)                       |
| **App**      | The name a runner registers under; workflows are addressed by name + app.          | [Workflows](/core/workflows)                   |
| **Project**  | The isolated slice: its own runs, events, keys, and runners.                       | [Projects](/core/projects)                     |

## What the runtime gives a handler

| Capability       | Surface                                                                                                        | Read                                                       |
| ---------------- | -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Durable work     | `step.run`, `step.sleep`, `step.sleepUntil`, `step.waitForEvent`, `step.poll`, `step.runWorkflow`, `step.emit` | [Steps](/core/steps)                                       |
| Parallel work    | `Promise.all` over steps; each branch is its own step                                                          | [Steps](/core/steps#parallel-steps)                        |
| Failure handling | Per-step retries, `NonRetriableError`, `RetryAfterError`, an `onFailure` handler                               | [Retries](/core/retries)                                   |
| Triggers         | Event triggers with filters and wildcards, cron schedules, manual runs                                         | [Triggers](/core/triggers)                                 |
| Flow control     | `concurrency`, `throttle`, `rateLimit`, `debounce`, `batch`, `priority`, `singleton`, `idempotency`            | [Flow control](/core/flow-control)                         |
| Run control      | Cancel, pause, resume, replay, retry from a step - each recorded with the actor behind it                      | [Control API](/reference/api/control)                      |
| Live record      | `ctx.log`, the streaming run timeline, the project-wide status stream                                          | [Logging](/core/logging), [Watching a run](/core/realtime) |

<Warning>
  A step id (`"triage"`, `"refund"`) is how its saved result is found on the next pass. Keep ids stable
  and unique within a handler, or a replay will not match the work it already did. [Steps](/core/steps#step-ids)
  covers the rules, and [Production](/core/production#step-ids-across-deploys) covers changing them
  safely.
</Warning>

## Next steps

<CardGroup cols={2}>
  <Card title="Durable execution" href="/core/durable-execution">
    What a step guarantees, and the two rules the code between steps has to follow.
  </Card>

  <Card title="Quickstart" href="/start/quickstart">
    Create a project, connect a runner, trigger a run, and restart the runner mid-run.
  </Card>

  <Card title="Recipes" href="/start/recipes">
    One complete, paste-and-run workflow per task.
  </Card>

  <Card title="Production" href="/core/production">
    Routing, deploying with runs in flight, draining, and blue/green.
  </Card>
</CardGroup>