Zum Hauptinhalt springen

Core Concepts

Before you build automations, it helps to know the moving parts and how they fit together. This page explains the concepts using everyday language — no programming background required.

The big picture​

Read top to bottom: a trigger fires, the steps run one after another, each step can read from and write to a shared scratchpad called memory, and at any point a step can consult an AI model, look something up in a knowledge base, or pause to ask the user something.

Triggers — when does it run​

Every automation has exactly one trigger. The trigger answers the question: what makes this automation start?

Triggers fall into a few flavors:

  • Time-based — a fixed schedule. "Every weekday at 7:00."
  • Event-based — something happening outside the platform. A new email, a new file, a new database row, a webhook call.
  • User-initiated — for agents, the user starting a chat or submitting a form.

You can read about each trigger in detail under Integrations.

Steps — what does it do​

Steps are the sequence of actions the automation runs after the trigger. Each step uses exactly one integration (call an AI model, send an email, query a database, write a file, …) and has its own configuration.

Steps run in order, top to bottom. The output of one step is typically the input of the next, via the shared memory.

Memory — the scratchpad​

Memory is the place where steps drop their results so that later steps can pick them up. Think of it as a shared whiteboard inside this one run of the automation.

  • A step that fetches data writes to memory under a name you choose (for example customer_record).
  • A later step reads from memory by referring to that name.

A few things to know:

  • Memory is per run. The data lives as long as the run lives. The next run starts with a fresh whiteboard.
  • Memory survives across pauses. If the automation pauses to ask the user something and comes back ten minutes later, everything in memory is still there.
  • Memory is private to the run. Other automations cannot see it.

You do not need to manage memory yourself — when you configure a step, fields marked as "input from memory" or "output to memory" do the wiring for you.

Conditions — should this step actually run​

You can attach a condition to any step. If the condition evaluates to false, the step is skipped and the automation continues with the next step. Conditions come in two flavors:

  • Deterministic — a formula like customer_priority == 'high'. Pure logic, no AI involved, instant.
  • Natural language — a sentence like "Run this only if the customer's previous message sounded urgent." The platform asks an AI model to evaluate the sentence against the current memory.

Use deterministic conditions whenever your check is purely logical. Use natural-language conditions when the decision genuinely requires judgement.

Waiting points — interaction with the user​

Some steps are designed to pause the automation and wait for the user. Two common cases:

  • An interactive workflow that needs a human decision in the middle.
  • An agent that asks the user a clarifying question.

When this happens, the run is suspended. The conversation appears in the Inbox. Once the user answers, the automation resumes from where it stopped, with the answer available in memory.

Personas — how an AI behaves​

A persona is a named description of how an AI should act. It usually contains the role ("You are a friendly assistant for a logistics company"), the tone, and any rules you want enforced ("Never reveal internal cost figures").

You can define personas once and reuse them across automations. This keeps tone consistent across all your agents.

Models — which AI engine​

A model is a configured connection to an AI provider — OpenAI, Anthropic, Mistral, or a self-hosted Ollama. Steps that talk to AI pick a model. Different steps can use different models if that makes sense (for example a small fast model for triage, a large slow model for the final answer).

See the Models section for details.

Knowledge — your own data​

A knowledge is your own document store — handbooks, FAQs, product specs, scraped web pages — that the AI can search. Steps that use knowledge don't send your entire knowledge base to the AI; they search it first and send only the relevant pieces.

See Knowledge for the details.

Output formats — what the AI returns​

When a step calls an AI model, you can specify an output format:

  • Natural — plain text. Good for emails, summaries, answers in chat.
  • JSON — structured data with a free-form shape. Good when a later step needs to process specific fields.
  • Structured — JSON conforming to a schema you describe. The platform generates the schema for you from a list of fields. Use this when the exact shape matters.

Putting it all together — a small example​

Here is a tiny but realistic workflow:

  1. Trigger — every weekday at 7:00.
  2. Step 1 — query the support database for tickets opened in the last 24 hours. Output to memory as tickets.
  3. Step 2 — call an AI model with a prompt like "Summarize these tickets, grouped by priority". Input from memory: tickets. Output to memory: summary.
  4. Step 3 — send an email to the team lead with summary as the body.

That is it. Three steps, one trigger, one model. The whole automation can be built in fifteen minutes once you know the building blocks.

What to do next​