Workflows & crews

The model at a glance#

• A workflow is a reusable configuration that owns a crew.
• A crew is an ordered list of agents.
• A run is one execution of a workflow against a single input.
• A run is made of steps — one per agent in the crew.

Workflows#

A workflow is the unit you create once and run many times. It stores a name, an optional description, a default model, and the crew that processes each run. Workflows have a status of active or paused; triggering a run against a paused workflow returns 409 Conflict.

Crews & agents#

A crew is an array of 1–10 agents. Each agent is a single role with its own system prompt, and optionally its own model that overrides the workflow default. An agent has these fields:

The default crew

If you create a workflow without specifying a crew, LoopLlama provisions a two-agent default: a planner that breaks the request into ordered steps, followed by a writer that produces the final output.

Defining a custom crew

Pass a crew array when creating a workflow. Agents run top-to-bottom; design the prompts so each role builds on the last.

{
  "name": "Spec reviewer",
  "model": "claude-sonnet-4-6",
  "crew": [
    {
      "role": "researcher",
      "systemPrompt": "Extract the key claims and open questions from the input. Be exhaustive and concise."
    },
    {
      "role": "writer",
      "systemPrompt": "Using the research, draft a clear one-page summary with a 'Risks' section."
    },
    {
      "role": "reviewer",
      "model": "openai/gpt-5.4",
      "systemPrompt": "Critique the draft for accuracy and gaps, then output a corrected final version."
    }
  ]
}

Runs & steps#

Triggering a run executes the crew sequentially. The first agent receives the run's input; every subsequent agent receives the original input plus a transcript of the prior agents' output. The final agent's output becomes the run's output.

A run moves through these statuses:

Each step persists its own input, output, model, token counts, model cost, and timestamps — so you can inspect exactly what every agent saw and produced. See the Runs reference for the full object shape.

Team agents#

A crew entry can be written inline (just a role and a prompt that belong to that one workflow) or linked to an agent on your team by setting agentId. A team agent is a standing member of staff: it has a name, its own instructions and tools, a status, a work history across every workflow it appears in, and its own memory. Edit it once on its profile (or with PATCH /v1/agents/{id}) and every workflow picks the change up on its next run.

• Pausing an agent takes it offline: any run that reaches one of its steps fails with a clear message until you resume it.
• Deleting an agent keeps run history; workflows that linked it fall back to their stored snapshot and run those steps inline.
• Hire from the prebuilt catalog, create one from scratch, or promote an inline step with Save to team in the workflow editor.

Triggers#

Schedules make a workflow proactive; triggers make it reactive. A trigger starts a run when something happens, with no one asking:

• Webhook — a private URL any system can POST to. The body (JSON, form or text) becomes the first agent's input.
• New email (Gmail or Outlook) — the connected mailbox is checked about once a minute; each new message that matches the optional search starts one run, with the sender, subject and body as input.
• New Slack message — a channel the bot is in is checked the same way; each new human message (optionally only @mentions) starts one run.

Every trigger can carry instructions that are prepended to the event, so the first step knows what to do with it (“triage this email and draft a reply for approval”). Runs started by a trigger show as triggered in the run list and have trigger: "event" in the API. A trigger pauses itself after five consecutive failures (a disconnected mailbox, say) so nothing spins unattended, and polling never backfills: only messages that arrive after the trigger exists are seen.

Follow-up tasks#

An agent with memory can also owe itself work. During a run it can call schedule_followup with a title, details and a due time (“check whether Acme replied, Thursday 9am”); you can assign one from the dashboard or the API too. When the time comes a run of the owning workflow starts on its own with the task as input, and the task is marked done when that run completes (retried in an hour if it fails, up to three times). Open tasks are shown to the agent in its prompt so it never schedules the same thing twice, and it can close them with complete_task. Runs started this way show as follow-up in the run list and have trigger: "task" in the API.

Memory#

By default a run starts from nothing: an agent knows only its system prompt and the input in front of it. Turn on memory (memory_enabled on the workflow, or the “Steps remember between runs” toggle in the dashboard) and each inline step carries context from one run to the next, scoped to its role within that workflow. A linked team agent has its own memory setting (memory_enabled, on by default) and its memory follows it into every workflow it works in. Two agents never read each other's notes.

• Notes are durable facts the agent decides to keep with its memory_remember tool — a customer's preference, an account detail, a lesson from a mistake. You can also write notes for it from the dashboard or the API to brief it before its next run. Pinned notes are always in the prompt; the rest are included newest-first within a budget.
• Journal entries are written by the system after every step the agent completes: what it was asked, what it produced, and which tools it used. The last few are in the prompt so the agent knows what happened last time.
• memory_recall searches everything older than what fits in the prompt, and memory_forget removes a note that turned out to be wrong.

Usage & metering#

Every completed or failed run records a usage event capturing the number of steps, the input/output tokens consumed, and the model cost at each provider's list price. Steps roll up into your monthly workflow steps — the unit the platform bills on — and model cost is passed through at cost with no markup. One step is one agent reasoning turn. See Rate limits & usage for plan limits and overage pricing.