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

# Runs and work

> A run materializes a recipe as an epic of stories, and surfaces them as tickets people can read, own, and resolve.

A run is one execution instance of a deployed agent. It begins when a deployed agent receives a trigger, a request, a schedule, an event, or direct human input.

```mermaid theme={null}
flowchart TD
    A["<b>Run</b><br/>One execution instance of one pinned agent version,<br/>in one deployment context, with specific inputs"]
    --> B["<b>Epic</b><br/>The run-specific work graph"]
    --> C["<b>Stories</b><br/>Individual work items"]
    --> D["<b>Tickets</b><br/>Visible, owned, discussable work"]
```

## Run

The run is the execution envelope. It records which capability was invoked, which agent version executed, which spec and recipe versions were pinned, which deployment supplied the bindings, what input was received, what mode was used, when execution started, what work occurred, what decisions were made, what outputs were produced, what failed, what required attention, and how execution ended.

A run should be understandable in business language. It should not require you to interpret a wall of model messages or tool-call logs.

## Epic

An epic is the work graph materialized for a particular run.

The recipe is reusable. The epic is run-specific.

The epic represents the complete body of work for the run: the stories to be completed, their dependencies, their current states, their outputs, and their relationship to the overall outcome.

An epic can evolve during a run as bounded decisions, escalations, and additional work become necessary. It stays traceable to the recipe it was instantiated from.

## Story

A story is an individual work item within an epic — one meaningful unit of executable work.

A story may carry a title, purpose, description, required skill or executor, dependencies, inputs, expected output, acceptance criteria, error policy, retry policy, timeout, status, output, evidence, and failure details.

```text theme={null}
EPIC  Onboard Jane Doe
├── STORY  Validate employee information
├── STORY  Create Google Workspace account
├── STORY  Provision approved applications
├── STORY  Notify manager
└── STORY  Verify onboarding completion
```

## Ticket

A ticket is the durable, business-readable collaboration and accountability object around work.

A story belongs to the execution graph. A ticket belongs to the human and AI team operating the capability.

|            | Answers                                                       |
| ---------- | ------------------------------------------------------------- |
| **Story**  | How the agent understands and executes work                   |
| **Ticket** | How the organization sees, owns, discusses, and resolves work |

A ticket may represent work requested, work in progress, work completed, an approval required, an exception, an escalation, a failed story, a human follow-up, an unresolved dependency, or an improvement request.

Examples: *Create Jane's Google Workspace account.* *Manager approval required for Salesforce access.* *Could not complete the security review because evidence was missing.* *Update the onboarding recipe to handle contractors.*

Today a story and a ticket are often one to one. They stay distinct in the model because they serve different purposes: tickets are what make agentic work visible, accountable, collaborative, assignable, discussable, and operable by people.

## Every run leaves an inspectable work graph

A run is not represented only as messages and tool calls. Its epic and stories make the work inspectable, resumable, reviewable, and understandable.

The primary operating experience describes what was requested, what work occurred, what changed, what succeeded, what failed, and what needs attention. Technical traces exist underneath, not in front.

## In the product today

```bash theme={null}
jstm agent run acme-corp/onboarding --input '{"employee":"jane.doe@acme.com"}'
jstm agent run show acme-corp/onboarding/runs/12
jstm agent runs acme-corp/onboarding
jstm agent stories acme-corp/onboarding
jstm ticket list --run-id 5f3a5c81-2d44-4e0b-9a17-0c9d3b7e9b21
```

A run streams progress as it happens. If it needs something from a person mid-run, it pauses and surfaces an input request rather than guessing.

## Next

<Columns cols={2}>
  <Card title="Run an agent" href="/guides/run-an-agent" icon="play">
    Trigger a run and follow it.
  </Card>

  <Card title="Review runs and tickets" href="/guides/review-runs-and-tickets" icon="clipboard-list">
    Read what a run produced.
  </Card>
</Columns>