Key Concepts

This page defines the building blocks you'll use to build on Ema. Read it once and the rest of the documentation will make sense. Each concept links to its full reference.

AI Employee

An AI Employee (AIE) is the unit of automation you build, test, publish, and run. It bundles a workflow with everything that workflow needs: an interface (chat, form, or voice), one or more knowledge bases, the Tools it's allowed to call, and the people allowed to use it.

An AI Employee performs work, not just a single task. Where a lone model call answers one prompt, an AI Employee runs an entire process — retrieve, decide, act, and hand off to a human when needed — and does it the same way every time.

Workflow

A workflow is the definition behind an AI Employee. It is a directed acyclic graph (DAG) of typed nodes: each node is a step, each edge is the data and order flowing between steps, and "acyclic" means the graph never loops back on itself, so every run has a well-defined path the engine can validate ahead of time.

The node types are a small, fixed set:

Node type	Role in the graph
`start`	Entry point; maps the run's inputs into the workflow. Exactly one per workflow.
`agent`	An LLM-driven reasoning step that runs one of the agent types.
`transform`	A deterministic, non-LLM reshape: extracts and coerces named fields from an upstream value. Never calls a model.
`publish`	Declares one or more named outputs — a response, a record write-back, or a document.
`end`	A terminal node that marks the close of a path.

Two things you might expect to be node types are not. Branching is configured on the edges: each edge can carry a condition, and the engine follows only the edges whose condition is true. Pausing for a person (human-in-the-loop) is a setting on an agent node, not a separate node. The feedback_router agent type — which routes a run on end-user feedback — is likewise an agent type set on an agent node, not a node type of its own.

Nodes pass data downstream by reference: a later node reads an earlier node's output using a template reference like {{node_<id>.output.<field>}}. Workflows are versioned — you publish a version, and you can compare versions and revert. For the full model, see Workflows.

Agent

An agent is what an agent node runs: an LLM-driven step configured for one kind of work. You give an agent Instructions (its system guidance, written in plain language), wire its inputs, and — depending on its type — point it at knowledge bases and Tools. Ema provides a set of built-in agent types you configure from templates:

Agent type	What it does
`search_respond`	Searches knowledge bases and external Tools in a reasoning loop, then returns a synthesized, citable answer.
`intent_classification`	Classifies input text into one of a set of intents you define. The label is commonly used in edge conditions to branch the workflow.
`extraction`	Extracts structured data from source text, conforming to a JSON Schema you supply.
`rule_validation`	Evaluates documents and inputs against a list of rules, returning a per-rule verdict with cited evidence.
`respond`	Generates a free-form natural-language reply from your Instructions, with no type-specific behavior added.

Beyond the built-in types, Ema supports code-execution agents (a code_execution agent runs your JavaScript or TypeScript in a sandbox) and custom agents (purpose-built agents dispatched to a dedicated execution service). For the complete catalog, configuration, and input/output schemas, see the Agent reference.

Agents are configured, not coded. The difference between a billing-support agent and a returns agent is usually their Instructions, knowledge bases, and Tools — not different software.

Knowledge base

A knowledge base is a collection of documents and synced data sources that an AI Employee retrieves from. Ema chunks and embeds the content so that a search_respond agent can find the most relevant passages for a question and ground its answer in them, with citations back to the source. You can upload files directly or sync from connected sources such as SharePoint, Google Drive, and Confluence. See Knowledge bases.

Integration and Tools

An integration connects your tenant to an external application. Once installed, an integration exposes one or more Tools — the discrete read and write operations an agent can call, such as "look up a customer" or "create a ticket." Tools are how an AI Employee acts on the outside world rather than only talking about it.

Integrations are managed centrally so that credentials and permissions are governed in one place, and every outbound Tool call passes through the platform's privacy boundary before it leaves. See Integrations and data.

Ema uses Tools for the operations an agent can call. Older material may call these "actions" — they are the same thing under the current model.

Human-in-the-loop

Human-in-the-loop (HITL) lets a workflow pause and bring a person into the run. You turn it on for an agent node — there is no separate "human" node — and a node with HITL enabled can:

ask a human an open question and use the answer to continue;
request approval before a consequential step proceeds; or
present a form for a person to complete.

The run pauses durably at the checkpoint — it holds its state and can wait minutes or days — and resumes from exactly where it left off once the person responds. This is what makes it safe to automate processes that need judgment or sign-off. See Human-in-the-loop.

EmaFusion™

EmaFusion™ is the model layer beneath every agent. Rather than binding a workflow to one model, EmaFusion™ selects an appropriate model per request across multiple providers, tracks token usage, and applies privacy controls at the model boundary. Builders rarely configure it directly — it's the substrate that makes agents work. See EmaFusion™.

Autopilot

Autopilot is Ema's in-app assistant. Instead of building a workflow by hand, you describe what you want in plain language and Autopilot creates and edits the workflow, configures agents, sets up knowledge bases, and connects Tools for you — asking for approval before anything destructive. See Autopilot.

Roles

Access in Ema is governed by roles. The roles you'll encounter most as a builder or administrator are:

Role	What it can do
`builder`	Create, edit, test, and run AI Employees and workflows; manage knowledge bases.
`builder_admin`	Everything a builder can do, plus manage model providers and API keys.
`user`	Run and use published AI Employees, but not edit them.
`user_admin`	Manage members and their access within the workspace.
`system_admin`	Full administrative control of the workspace, including SSO and workspace settings.

The platform defines additional roles (for example env_admin for environment-level administration and no_access to revoke access). For the complete role model and the permissions each role carries, see Administration.

How the concepts connect

Putting it together: you build an AI Employee whose workflow is a DAG of typed nodes. The agent nodes run agents that read from knowledge bases and call Tools exposed by integrations; an agent node with human-in-the-loop enabled brings in a person; edges branch the path on conditions; and every model call goes through EmaFusion™. Roles decide who can build versus who can use, and Autopilot can assemble the whole thing for you from a description.

What's next

Platform Tour — see where each concept lives in the interface.
Core Concepts — the deeper reference for workflows and execution.
Glossary — quick definitions for every term.