> Source: https://builder-docs.ema.ai/core-concepts/gwe-overview
> Title: Generative Workflow Engine (GWE) Overview

# Generative Workflow Engine (GWE) Overview

The Generative Workflow Engine (GWE) is the orchestration layer that powers every AI Employee in Ema. GWE is best understood as an **interpreter for a limited programming language**: it executes a program (workflow) by running a series of function calls (actions) in sequence, mediating data flow between them as defined by the workflow configuration.

Each AI Employee runs on an adaptive, multi-agent workflow built with GWE. The engine is responsible for:

-   **Parsing and validating** workflow definitions.
-   **Executing** workflows by orchestrating actions in topological (DAG) order.
-   **Mediating data** between actions via typed bindings and ports.
-   **Storing results** for downstream consumption and audit.
-   **Tracking version history** so that workflow changes can be reviewed, compared, and reverted.

## Visual Canvas

The Workflow Builder provides a visual canvas for designing and inspecting workflows.

To access the Workflow Builder:

1.  Navigate to the **AI Employees** page and select an AI Employee.
2.  On the configuration page, click **Go to Workflow Builder**.

The canvas displays:

-   **Trigger block**: The entry point that activates the workflow (e.g., a chat message, an email, a document upload, a dashboard row).
-   **Agent blocks**: Nodes representing individual actions in the workflow. Each block shows the agent's name, description, and input/output connections.
-   **Connecting lines**: Edges that illustrate data flow -- how outputs from one agent become inputs for the next.

### Interacting with the Canvas

-   **Drag** blocks to rearrange the layout.
-   **Zoom** in and out for better visibility.
-   **Click** an agent block to open its configuration panel, where you can:
    -   View and edit the agent's name, description, inputs, and outputs.
    -   Rename or remove the agent.
    -   Access advanced settings (e.g., EmaFusion model selection).

### Shared Configuration

A shared configuration section lets you add resources used by multiple agents:

-   Connected applications and data sources.
-   Default EmaFusion settings (can be overridden at the agent level).

## Code View

The **Code** tab provides a read-only, code-based representation of the workflow for deeper inspection. This view shows the raw workflow definition, which is useful for:

-   Debugging complex data flows.
-   Understanding the exact binding and conditional configuration.
-   Comparing workflow versions.

## Issues Tab

The **Issues** tab lists any errors or misconfigurations detected within the workflow. Common issues include:

-   Missing required bindings.
-   Type mismatches between connected ports.
-   Unreachable actions due to conditional logic.
-   Required outputs that are not produced on all execution paths.

See [Workflow Validation](/legacy-docs/core-concepts/workflow-validation) for details on the static validation system.

## How Workflows Execute

Under the hood, GWE compiles a workflow definition into a **directed acyclic graph (DAG)**:

1.  Each **node** in the graph is an action instance -- a call to a specific agent with bound inputs.
2.  Each **edge** is a binding -- a connection that carries data from one action's output to another's input.
3.  The engine executes actions in **topological order**, ensuring that every action's inputs are available before it runs.
4.  At each step, the engine assembles input data from upstream outputs, invokes the action provider (typically via RPC), and stores the output for downstream consumers.

The actual data values (the user's query, a search result, an API response) are not known until runtime. The workflow definition specifies the _structure_ of data flow; runtime execution fills in the values.

```
Trigger --> Action A --> Action B --> Action C --> Output
 \ ^
 \--> Action D ----------/
```

In this example, Action C depends on both Action B and Action D. The engine runs A first, then B and D in parallel (since neither depends on the other), and finally C once both B and D have completed.

> For detailed coverage of how actions, bindings, and conditionals work, see:
> 
> -   [Workflows and Actions](/legacy-docs/core-concepts/workflows-actions)
> -   [Conditionals](/legacy-docs/core-concepts/conditionals)

## Access Requirements

Action

Required Role

View the Workflow Builder

Admin or Manager on the AI Employee

Edit the workflow

Admin on the AI Employee

Create new AI Employees

Admin or Builder at the tenant level

Users without admin or manager access can use the AI Employee but cannot view or modify its workflow.

* * *

**Next**: [Workflows and Actions](/legacy-docs/core-concepts/workflows-actions)