> Source: https://builder.ema.ai/v2/introduction/what-is-ema > Title: What Is Ema? # What Is Ema? Ema is a platform for building **AI Employees**: configurable automations that read your enterprise data, decide what to do, and carry out multi-step work from start to finish. An AI Employee can answer a customer's question from your knowledge base, classify and route an incoming ticket, extract structured fields from a document, validate a record against a set of rules, or call an external system to make a change — and it can chain those steps together into one workflow. Each AI Employee is built from a **workflow**: a directed acyclic graph (DAG) of typed nodes that Ema's workflow engine validates and runs. You assemble that graph in the **AI Employee builder**, give the reasoning steps **Instructions** in plain language, point them at **knowledge bases** and **Tools**, and add **human-in-the-loop** checkpoints wherever a person needs to approve or supply input. Every LLM call the workflow makes runs through **EmaFusion™**, Ema's model layer. > [INFO] > **AIE** is the abbreviation for AI Employee, used throughout this documentation. ## What an AI Employee is An AI Employee is the unit you build, test, publish, and run. It is defined by a workflow and a set of configuration — a name, the interface it presents to users, its knowledge bases, the Tools it can call, and the people allowed to use it. Getting an AI Employee into production typically means three things: 1. **Give it knowledge.** Add documents and data sources to one or more knowledge bases so the AI Employee can retrieve grounded, citable answers. See [Knowledge bases](/builder/v2/core-concepts/knowledge-bases). 2. **Connect the systems it needs.** Install integrations so the AI Employee has Tools to read from and write to external applications. See [Integrations](/builder/v2/integrations-data). 3. **Shape its behavior.** Write Instructions for each agent, set conditions and checkpoints, then test and publish. See the [Builder guides](/builder/v2/builder-guides). You can build an AI Employee by hand in the builder, start from a [template](/builder/v2/templates), or describe what you want to [Autopilot](/builder/v2/autopilot) and have it build the workflow for you. ## How an AI Employee runs When an AI Employee runs, the workflow engine walks the DAG node by node. The graph is built from a small, fixed set of node types: Node type What it does `start` Entry point. Maps the run's inputs (a chat message, form submission, or API payload) into the workflow. Exactly one per workflow. `agent` An LLM-driven reasoning step. Runs one of the agent types — search and respond, classify, extract, validate, and so on. Most of the work happens here. `transform` A deterministic, non-LLM reshape: extracts and coerces named fields from an upstream value using a list of rules. Never calls a model. `publish` Declares one or more named outputs — the AI Employee's public output contract (a final response, a written-back record, or a generated document). `end` A terminal node that marks the close of a path. There is no dedicated "conditional" or "human" node type. Branching is configured on the **edges** between nodes — each edge carries an optional condition, and the engine follows only the edges whose condition is true. Pausing for a person is configured on an `agent` node: turn on **human-in-the-loop**, and the run pauses durably at that step until a person responds — it can wait minutes or days without losing state. (`feedback_router`, which routes a run on end-user feedback, is an agent type, not a node type.) Because the graph is acyclic, every run has a well-defined path and the engine can validate it before execution. Runs stream their progress step by step. For the full execution model, see [Workflows](/builder/v2/core-concepts/workflows). ## The interfaces an AI Employee can present The same underlying workflow can be surfaced through different interfaces. You choose the **interaction type** when you create the AI Employee: Interface Best for **Chat** Conversational question-and-answer and task completion. The AI Employee keeps conversation history across turns and can pause for human-in-the-loop input inline. **Form** Structured, repeatable runs driven by a defined set of inputs — for example a triage queue or a batch of records to process. **Voice** Phone and voice channels. Voice AI Employees run the same workflow and add voice-specific configuration such as call routing and phone-number assignment. > [INFO] > **Beta.** The Voice AI Employee is a beta feature and is enabled per tenant. Beyond these built-in interfaces, an AI Employee can be invoked programmatically through the [API](/builder/v2/api-reference), letting you trigger runs from any enterprise system or custom application. ## EmaFusion™ **EmaFusion™** is Ema's model layer. Every LLM call an AI Employee makes flows through it, so no agent talks to a model provider directly. EmaFusion™ supports multiple model providers and many models, and it selects an appropriate model for each request rather than forcing every task onto a single model. It also tracks token usage per call for observability and cost accounting. This design gives you three things without changing your workflows: - **Model agility.** New models and providers can be added centrally; your AI Employees pick them up without being rebuilt. - **Cost and performance control.** Routing avoids spending a frontier-model call on a task a smaller model handles well. - **Privacy at the boundary.** Sensitive data is detected and tokenized before it leaves for a model, and only the entity types your tenant has explicitly allow-listed are rendered back to their original values. For the full treatment — model selection, fallback behavior, bring-your-own-model, and token accounting — see [EmaFusion™](/builder/v2/emafusion). ## How Ema differs from RPA and point assistants Ema sits in a different category from the two automation approaches most teams already know: - **Robotic process automation (RPA)** records fixed click paths or hard-coded rules. It's brittle: any change to a screen or a process breaks it, and it can't reason about unstructured content like PDFs, emails, or chat transcripts. - **A point assistant** assists a person inside one application. It speeds up a single task but doesn't own a process end to end or act across systems on its own. An AI Employee combines LLM reasoning with a validated workflow so it can: - run a complete, multi-step process across several systems rather than a single task; - handle unstructured inputs — extracting fields from a document, classifying free text, validating against rules; - pause for a human exactly where judgment or sign-off is required, then resume; and - be observed, governed, and audited end to end, which is what makes it safe to put in production. ## What's next - [Key Concepts](/builder/v2/introduction/key-concepts) — the vocabulary: AI Employees, workflows, agents, knowledge bases, Tools, and roles. - [Platform Tour](/builder/v2/introduction/platform-tour) — where each of these lives in the interface. - [Core Concepts](/builder/v2/core-concepts) — the deeper model of workflows and execution.