> Source: https://builder.ema.ai/v2/introduction/key-concepts
> Title: Key Concepts

# 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](/builder/v2/core-concepts/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](/builder/v2/agent-reference).

> [TIP]
> 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](/builder/v2/core-concepts/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](/builder/v2/integrations-data).

> [INFO]
> 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](/builder/v2/core-concepts/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™](/builder/v2/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](/builder/v2/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](/builder/v2/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](/builder/v2/introduction/platform-tour) — see where each concept lives in the interface.
-   [Core Concepts](/builder/v2/core-concepts) — the deeper reference for workflows and execution.
-   [Glossary](/builder/v2/introduction/glossary) — quick definitions for every term.
