Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hellofriday.ai/llms.txt

Use this file to discover all available pages before exploring further.

Jobs are the workflows that 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]

​
Conditional branching

Transitions can be arrays with guard functions — the first passing guard wins: 
decide:
  entry:
    - type: agent
      agentId: router-agent
      outputTo: decision
    - type: emit
      event: DONE
  on:
    DONE:
      - target: path-a
        guards: [isPathA]
      - target: path-b
        guards: [isPathB]
      - target: fallback
functions:
  isPathA:
    type: guard
    code: |
      export default function isPathA(context) {
        return context.results['decision']?.route === "a";
      }

​
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 <workspace>

​
Memory

Jobs can read and write workspace 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. Bundled 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 in a pipeline — the next step’s inputFrom receives nothing. Always pair them.