1. Ema v2 Docs
  2. Emafusion
  3. Setup

EmaFusion™ Setup

EmaFusion™ is configured at two levels: a default on the AI Employee, which every agent inherits, and an optional per-agent override for steps that need something different. Separately, an administrator configures the providers (the credentials EmaFusion™ uses to reach the models). This page covers all three, plus using your own providers (BYOM).

Configure the AI Employee default

The AI Employee-level configuration is the model behavior every agent uses unless it explicitly overrides it.

  1. Open the AI Employee from AI Employees.
  2. Go to the Configuration tab and, on the AI Employee Configuration card, select Edit.
  3. Under Model Selection, set the mode and, where applicable, the Optimization Priority (both described below).
  4. Select Save Configuration.

Model selection

Model selection has three modes:

ModeWhat it does
Let Fusion PickEmaFusion™ automatically selects the best model for each task from all available models, ordered by your optimization priority. This is the default and the recommended starting point.
Limit to Specific ModelsEmaFusion™ chooses only from the models you select. A multi-select picker appears; models that lack a capability the AI Employee's agents need are shown disabled with the reason. With two or more models selected, the optimization priority still applies.
Custom ModelsMarked Coming soon and not selectable.

Optimization priority

When EmaFusion™ has more than one model to choose from, the Optimization Priority sets the order it tries them in. It's shown in Let Fusion Pick mode, and in Limit to Specific Models mode when you've selected two or more models.

PriorityOptimize for
Auto (default)A balance of accuracy, latency, and cost, chosen per task type.
FastestThe lowest response time.
CheapestThe lowest cost.
Most accurateThe highest benchmarked accuracy for the task.

See How EmaFusion™ works for how the routing logic uses the priority when ranking and cascading between models.

Start with Let Fusion Pick and the Auto priority. This gives EmaFusion™ the widest selection and the best per-task routing. Only restrict models when you have a specific reason: a compliance requirement, a cost ceiling, or a latency target.

Override per agent

Every agent in a workflow inherits the AI Employee's model configuration by default. When one step needs a different model (say a reasoning model for a planning agent, or a faster model for a latency-sensitive step), you can override the default on just that agent.

  1. Open the AI Employee's workflow in the editor.
  2. Select the agent you want to change.
  3. In the agent's panel, find the Model configuration section.
  4. Turn on Override default configuration.
  5. Set a model-selection mode and optimization priority for this agent, exactly as you would at the AI Employee level.

While the override is off, the agent shows a summary of the inherited configuration: the inherited model-selection mode (all models or a count of selected models) and the inherited optimization priority. Any change to the AI Employee default flows through automatically. Turning the toggle off again re-binds the agent to the AI Employee default.

Use agent-level overrides sparingly. Overriding the AI Employee default everywhere defeats EmaFusion™'s per-task routing. Prefer setting a sensible AI Employee default and overriding only the agents that genuinely need something else.

Capability warnings

When you restrict an agent (or the AI Employee it inherits from) to specific models, the builder checks those models against the capabilities the agent needs (such as structured output or function calling). If a selected model is missing a required capability, the builder shows a compatibility warning. To resolve it, either select a compatible model, switch the agent to Let Fusion Pick, or override the agent with a model that has the capability.

Use your own providers (BYOM)

By default, EmaFusion™ routes through the model catalog. If you'd rather have an AI Employee run only on the models from your own configured LLM providers (for example, to keep all traffic on a specific Azure OpenAI deployment), turn on Use my own providers on the AI Employee's AI Employee Configuration card.

  • The toggle is set on the AI Employee and applies to every agent under it.
  • When it's on, the model picker draws from the models discovered from your configured providers rather than the EmaFusion™ catalog, and the optimization priority control is hidden (your providers' models don't carry the catalog's routing metadata).
  • There is no agent-level "own providers" override. This is an AI Employee-wide choice.

If you turn on Use my own providers but have no LLM providers configured, your AI Employee has no models to run on. Add a provider under Admin → Workspace → LLM Providers first (see below).

Configure providers

Providers supply the API keys EmaFusion™ uses to reach models. Adding a provider with a valid key automatically discovers that provider's models and makes them available to your AI Employees. Provider management is an administrator task.

Who can do this. The LLM Providers page lives inside Workspace Management, which is open to system-admin and environment-admin roles.

Add a provider

  1. Go to Admin → Workspace → LLM Providers (the legacy path Admin → Providers redirects here).
  2. In the Providers section, select Add Provider.
  3. Fill in the Add LLM Provider dialog:
    • Name — a label for this provider, such as "My OpenAI Provider".
    • Provider Type — OpenAI, Anthropic, or Azure OpenAI.
    • API Key — the provider's API key. It is encrypted at rest and never shown again after you save it.
    • Primary / Fallback (optional) — mark this provider as the primary or the fallback for the workspace.
    • For Azure OpenAI, two extra fields appear: Base URL (your Azure resource endpoint; required for Azure, and must start with https://) and an optional Deployment prefix (set this if your Azure deployments are named like my-company-gpt-4o — enter my-company; leave it empty if deployment names match the model names exactly).
  4. Select Create.

On create, the platform validates the API key with a lightweight call to the provider and records the result. The provider row shows the key status: Valid, Invalid (with the validation message), or Unknown. This lets you confirm a key works without leaving the page. If the key is valid, the provider's models are discovered automatically and appear in the Models section.

For Azure OpenAI providers, Ema also queries the resource's deployment list on create and populates the Models table with exactly the deployments found on your resource. Ema repeats this automatically at startup and once a day, so the table stays in step with changes you make in the Azure portal.

A provider with an invalid API key will cause workflows that use its models to fail. The Providers page shows a warning banner listing any providers with invalid keys.

Manage models

The Models section lists every model discovered from your connected providers, with its display name, model ID, and per-1K-token prompt and completion costs. Use the Enabled toggle on each row to make a model available or unavailable for workspace-wide use. Only enabled models with a valid-key provider behind them are eligible for EmaFusion™ routing.

For Azure OpenAI providers, the Models table shows only the deployments that exist on your resource. The table is updated automatically at startup and once a day. If you have just deployed a new model in Azure and don't want to wait for the next automatic update, select Sync deployed models above the table to refresh immediately. A model you disable stays off across restarts and automatic syncs.

Document ingestion and search require an embedding model. If the platform's embedding model isn't available or enabled, the Providers page shows a warning telling you which model ID to enable. If you have an Azure provider, deploy that model in Azure first, then click Sync deployed models to add it to the table; Ema also picks it up within a day. If the model is already in the table, turn on Show all discovered models and enable it.

Sync deployed models (Azure OpenAI)

The Sync deployed models button appears in the Models card when you have at least one Azure OpenAI provider. Selecting it runs the same deployment sync that happens at startup and daily, for your workspace right now. The button is disabled when the environment cannot deliver provider credentials to the model routing layer (the same condition shown in the BYOM sync warning on the Providers page).

After the sync completes, a notification reports how many models were added, removed, enabled, and how many deployment names were recorded. If a provider's resource could not be reached, its models are left as they are and a separate warning names the affected provider.

The sync is also available via the API for system-admin and builder-admin roles (or the model.manage capability):

POST /models/refresh

No request body is needed. The response describes what changed per Azure provider and in total:

{
  "providers": [
    {
      "provider_id": "uuid",
      "display_name": "My Azure Provider",
      "outcome": "refreshed",
      "source": "list",
      "models_added": 1,
      "models_deleted": 0,
      "models_enabled": 0,
      "models_disabled": 0,
      "deployment_names_recorded": 1
    }
  ],
  "models_added": 1,
  "models_deleted": 0,
  "models_enabled": 0,
  "models_disabled": 0,
  "deployment_names_recorded": 1
}

outcome is one of refreshed (resource answered and at least one row changed), unchanged (resource answered and rows already matched), unreachable (resource could not be listed or probed, so rows were left as they are), or failed (resource answered but a row could not be written). source is list or probe when the resource answered.

The endpoint returns 503 while the environment cannot deliver provider credentials to the model routing layer or the startup sync has not completed, 409 while another sync of the workspace is already running, and 429 within a few seconds of the workspace's last sync.

Delete a provider

Use the actions menu on a provider row to delete it. Models that depended only on that provider stop working, so confirm no active AI Employee relies on them first.

What's next

Last updated: Oct 12, 2026