Overview

Your Sim workspace is where your AI systems live. A system is made of two things. Workflows are the procedures it runs. Resources are the data those procedures work with: tables, knowledge bases, and files.

A workflow is a visual program made of blocks. Like a recipe, it's a fixed set of steps you write once and run again and again, each time with new input. Each block does one step of work, and connections set the order the blocks run in.

Here's a simple one. It takes an incoming customer message, classifies its category and urgency, and returns the result:

The parts of a workflow

Trigger

A trigger is where a workflow begins and what it hands in. Every workflow has exactly one. The Start trigger takes input directly — from the editor while you build, and from an API call or a chat once deployed. For runs that should start on an event or a timer, you swap in a webhook or schedule trigger, and the downstream blocks don't change.

In our example, the Start trigger receives the customer message. Later blocks read it by name, as <start.input>.

Block

A block is a single step, and each does one thing: an Agent reasons with a model, a Function runs code, a Condition branches, a Loop repeats. Some blocks are deterministic (Function, Condition); others are model-driven (Agent) and can vary run to run. That difference is the first thing to know when debugging.

Our example has one Agent block, configured with a model and a prompt, that reads the message and returns a classification.

Connection

A connection wires one block to the next and sets the execution order: the block at the arrow's head runs after the one at its tail. Once a block has run, the blocks after it can read its output by reference.

You read an earlier output with a connection tag, written <blockName.field>: name the block, then the value you want. The Agent's prompt reads the message with <start.input>; a later block could read the Agent's answer with <agent.content>.

Most workflow issues are data issues, not crashed blocks: a reference points at a value that isn't there, or a block on the path didn't run. See how blocks pass data for outputs, references, and types.

Output

An output is what a block produces; later blocks read it through connection tags. By default the workflow's output is its last block's output. In our example that's the Agent's { category, urgency }. There's no separate return step.

On reuse, the consumer picks which outputs it wants by name: a chat deployment, a table column, or an API call each select block outputs individually. It's the same idea as connection tags, applied at the workflow's edge. (For precise HTTP control, add a Response block.)

Kinds of blocks

Core blocks come in three kinds: blocks that do work (Agent, Function, API), blocks that direct the flow (Condition, Router, Loop, Parallel), and blocks that shape the run (Response, Guardrails, Wait, and more).

Two larger families do more specific jobs:

• Integrations connect to an external service — Gmail, Slack, Notion, a database — with hundreds available. An agent can also call them as tools.
• Triggers are the blocks that start a workflow.

How a workflow starts

A trigger decides what starts the run and what input it receives. Native triggers need no connected account: Start (manual, API, or chat), Schedule (a timer), Webhook (any inbound HTTP request), RSS (a new feed item), and Table (a row change in a Sim table). Integration triggers fire on an event in a connected service — a GitHub push, a new email — and hand it to the workflow.

How it runs

When a workflow runs, blocks execute in dependency order: a block runs as soon as the blocks it depends on have finished, so independent branches run in parallel. Conditions, loops, and parallel blocks change the path data takes.

Workflows in context

A workflow is where the rest of the workspace becomes behavior. On their own, tables, knowledge bases, files, and integrations are just resources. Workflows are where they do something.

• Mothership builds and edits workflows in natural language.
• Tables, knowledge bases, files, and integrations feed data, memory, artifacts, and actions into a workflow.
• Deployments expose a workflow as an API, chat, or MCP server.
• Logs record every run so you can verify what happened, step by step.

Next