Jobs

Jobs orchestrate your agents. Each job is a finite state machine (FSM) — you define the states it moves through, what agents execute at each state, and how it transitions forward.

Anatomy of a job

workspace.yml

jobs:
  review-pr:
    title: "Review PR"
    description: "Clones the repo, reviews the diff, posts inline comments."
    triggers:
      - signal: review-pr
    fsm:
      id: review-pr-pipeline
      initial: idle
      states:
        idle:
          on:
            review-pr:
              target: clone
        clone:
          entry:
            - type: agent
              agentId: gh
              outputTo: clone-output
              prompt: "Clone the repo for PR: {{payload.pr_url}}"
            - type: emit
              event: DONE
          on:
            DONE:
              target: review
        review:
          entry:
            - type: agent
              agentId: claude-code
              inputFrom: clone-output
              outputTo: review-output
              prompt: "Review the diff and return structured findings."
            - type: emit
              event: DONE
          on:
            DONE:
              target: completed
        completed:
          type: final
    config:
      timeout: "10m"
      max_steps: 20

The trigger contract

When a signal fires, the runtime resets the FSM to initial and sends { type: <signal-name>, data: <payload> }. The initial state’s on map must have a key that exactly matches the signal name — or the event is silently ignored and no session starts.

# Signal name is "review-pr"
fsm:
  initial: idle
  states:
    idle:
      on:
        review-pr:        # must match signal name exactly
          target: clone

Action types

Each entry array in a state takes one or more actions: Agent action — invoke an agent and optionally capture its output:

entry:
  - type: agent
    agentId: my-agent        # must match an agent declared in agents:
    prompt: "Do the thing"   # optional per-step prompt
    outputTo: my-result      # save output as a named document
    inputFrom: prev-result   # feed a prior step's output as input

Emit action — advance the FSM after the agent finishes:

entry:
  - type: agent
    agentId: my-agent
    outputTo: result
  - type: emit
    event: DONE

Agents do not auto-advance the FSM. Every action state needs an explicit type: emit to trigger the transition. The event name must exactly match a key in the on map.

Passing data between steps

Use outputTo and inputFrom to chain steps:

step-a:
  entry:
    - type: agent
      agentId: agent-a
      outputTo: step-a-result   # saves output as named document
    - type: emit
      event: DONE
  on:
    DONE:
      target: step-b

step-b:
  entry:
    - type: agent
      agentId: agent-b
      inputFrom: step-a-result  # receives step-a's output as task input
    - type: emit
      event: DONE

A step can take multiple prior outputs by passing inputFrom as an array — the engine concatenates them:

summarize:
  entry:
    - type: agent
      agentId: summarizer
      inputFrom: [emails-result, calendar-result]

Running jobs

Signals — external events like webhooks or cron schedules
Studio UI — click Run on any job card in the Studio
API — POST /api/workspaces/:id/signals/:signalId
CLI — friday signal trigger -n <signal> -w <space>

Memory

Jobs can read and write space memory through agents. Memory persists across sessions — agents can recall what happened in previous runs. See Memory.

Inspecting jobs

Use the Job Inspector to visualize the FSM as a , run jobs with custom inputs, and debug executions with the waterfall timeline.

Common gotchas

type: atlas agents ignore the tools array. Built-in agents are self-contained. If you need MCP tools called, use type: llm with an explicit tools array instead.
Missing type: emit — if a state has no emit action, the FSM never transitions and the session hangs.
Emit name mismatch — event: DONE in the emit must match the on: DONE key exactly.
outputTo missing between chained steps — the next step’s inputFrom receives nothing. Always pair them.

Getting started

Core concepts

Guides

Agent SDK

Reference

Resources

Anatomy of a job

The trigger contract

Action types

Passing data between steps

Running jobs

Memory

Inspecting jobs

Common gotchas

​Anatomy of a job

​The trigger contract

​Action types

​Passing data between steps

​Running jobs

​Memory

​Inspecting jobs

​Common gotchas

Anatomy of a job

The trigger contract

Action types

Passing data between steps

Running jobs

Memory

Inspecting jobs

Common gotchas