Actions

Jetty supports a number of pre-built actions that work alongside runbooks. A runbook hands a whole job to an agent. An action does one well-defined piece of work with no agent in the loop: call a model, fan out over a list, fetch a file, grade an output. Put the two together and a single run can prepare inputs before a runbook starts, hand the runbook its data, and score what it produced afterwards.

An action is one entry in a workflow's step_configs. Each entry names an activity — the unit of work Jetty knows how to run — plus the config that activity needs, and the workflow's steps list sets the order. The runbook activity is itself an action, which is how a runbook task becomes a one-step workflow and how other actions slot in before and after it. Actions pass data to one another through path expressions.

Actions fall into four families: AI models, control flow, data processing, and evaluation. The tables below list a representative slice of each, not the whole registry.

Path expressions

Actions don't share variables. They read each other's data through path expressions: dot-notation strings that point at a value somewhere in the run. Any config field ending in _path takes a path instead of a literal value, so prompt_path: "init_params.user_prompt" means “use the value found at that path as this step's prompt.”

Pattern	Points at
`init_params.<field>`	An input to the run, as passed by the caller or defaulted by the task.
`<step>.outputs.<field>`	Something an earlier action produced. `steps.<step>.outputs.<field>` is the explicit form of the same path.
`<step>.inputs.<field>`	The resolved input an earlier action received.
`…[0].<field>`	One element of an array output.
`…[*].<field>`	Every element of an array output, collected into a list.

Wire a later action to an earlier one by pointing its *_path at earlier_step.outputs.…; the order in steps guarantees the source has produced its output first.

{
  "init_params": { "user_prompt": "Explain quantum computing simply" },
  "step_configs": {
    "analyze": {
      "activity": "litellm_chat",
      "model": "gpt-4o",
      "prompt_path": "init_params.user_prompt"
    },
    "grade": {
      "activity": "simple_judge",
      "content_path": "analyze.outputs.text",
      "criteria": "Clear, correct, and under 200 words"
    }
  },
  "steps": ["analyze", "grade"]
}

analyze reads its prompt from the run's inputs and grade reads the text analyze produced. Pass a different user_prompt at run time and both steps follow, with nothing in the workflow to edit.

Where a value comes from

A parameter can be set in more than one place. Inside a step it resolves in priority order: literal in step config → *_path in step config → literal in init_params → *_path in init_params → the activity's declared default. init_params themselves merge shallowly, caller over task definition. That is why a deployed runbook task reads its agent, model, and instruction through *_path fields, and why the same task can be rerun with a different agent, model, or input without being redeployed. The full rules are in the machine instructions.

Magic variables inside a fan-out

When list_emit_await fans out over a list, each child run can reach a few magic variables through template expressions, written as {{ expression }}:

Variable	Meaning
`$item`	The current item.
`$index`	The current index, 0-based.
`$parent_id`	The parent run's trajectory id.
`$item_len`	The length of the current item.
`$item_type`	The type name of the current item.

Path expressions show up in a few other places too. A bearer token for an attached MCP server (mcp_auth_token) accepts one, so the token can come from init_params or an earlier step. The inputs recorded on every run are the values these paths resolved to. And because the wiring between actions is just paths, Jetty can draw any workflow as a graph: each action a node, each path reference an edge. The live syntax reference is GET /api/v1/step-templates/path-expressions.

AI models

These call language, image, and video models. Each family needs the matching provider key configured; see runtimes and Integrations for how Jetty resolves credentials at run time.

Category	Activity	What it does
AI models	`litellm_chat`	One chat completion against any of 100+ providers via LiteLLM.
AI models	`litellm_batch`	Many completions in one step: fan out a list of requests.
AI models	Gemini steps	Prompt and reader activities plus `gemini_image_generator`.
AI models	AWS Bedrock	Invoke models hosted on Bedrock.
AI models	`replicate_text2image`	Replicate models for text-to-image and the rest of the Replicate catalog.

Control flow

These shape how a workflow runs: branching, looping, fanning out across many inputs, and pulling data back out of prior runs.

Category	Activity	What it does
Control flow	`list_emit_await`	Fan out over a list and run children in parallel.
Control flow	`conditional_branch`	Take one path or another based on a value.
Control flow	`number_sequence_generator`	Produce a numeric range to iterate over.
Control flow	`loop_counter`	Track iterations in a loop.
Control flow	`extract_from_trajectories`	Pull values out of earlier runs into the current run.

Data processing

The glue steps: moving text and files around, attaching metadata, and reaching out over HTTP.

Category	Activity	What it does
Data processing	`text_concatenate`	Join text fragments into one string.
Data processing	read / download / save file steps	Read, fetch, and persist files through Jetty storage.
Data processing	metadata	Attach or read metadata on an asset.
Data processing	`webhook`	Call out to an external HTTP endpoint mid-workflow.

Evaluation

These grade and analyze runs, the steps that drive run-based evaluation.

Category	Activity	What it does
Evaluation	`simple_judge`	LLM-as-judge: score on a 1–5 scale or a categorical rubric.
Evaluation	`select_trajectories`	Filter prior runs into a set to analyze.
Evaluation	`visualize_correlation`	Plot how scores or signals relate across runs.

Discovering actions programmatically

This catalog is a snapshot, while the live registry is the source of truth. The API calls actions step templates: list the full set from your editor with list-step-templates (MCP) or listStepTemplates (SDK), then inspect any one to see its exact config shape.

Ready to wire these together? See writing runbooks for the runbook-first path, or machine instructions for the programmatic workflow surface.