How EmaFusion™ Works
EmaFusion™ turns a single "complete this" request from an agent into a per-call model decision. It assembles a list of candidate models, removes any that can't do what the request needs, orders the survivors by your optimization priority, then runs them one at a time — scoring each answer's confidence — until one clears the bar. This page walks the pipeline end to end so you can predict which model handles a given step and why.
Two routing paths
How a model call is resolved depends on whether intelligent EmaFusion™ routing is enabled for your tenant. The platform reports this to the AI Employee builder as a gate status, and the Configuration card adapts to it.
- Routing enabled — the full pipeline below runs: candidate selection, capability filtering, optimization, and confidence-based cascading across the model catalog. The Configuration card shows EmaFusion™'s model-selection modes and optimization priorities.
- Routing not enabled — calls go to the models from your configured providers using each provider's primary/fallback order. There is no per-task confidence cascade. The Configuration card shows the equivalent provider-based model settings.
Intelligent routing reports as enabled only when the per-tenant gate is on and the platform has a live connection to the model-routing service. A half-configured state reports as not enabled, so the builder never shows routing controls that would fail at run time.
The rest of this page describes the routing-enabled pipeline.
The routing pipeline
When an agent makes a completion request, EmaFusion™ processes it in this order:
- Validate and normalize — the request must contain at least one message. Messages are normalized into a consistent shape before anything else runs.
- Cache check (optional) — if the request opted into caching, EmaFusion™ checks for a cached response keyed on the tenant, the request messages, and any output schema. A hit returns immediately and is recorded with the reason
cache_hit. - Assemble candidates — EmaFusion™ builds the candidate list from the model catalog. It only considers models that have at least one enabled provider behind them, so it never wastes an attempt on a model nobody can actually call.
- If the AI Employee (or agent) is set to Let Fusion Pick, the candidate list is the full set of linked completion models.
- If it's set to Limit to Specific Models, the candidate list is your chosen models, intersected with the models that actually have a provider.
- Detect required capabilities — EmaFusion™ inspects the request and derives the capabilities the model must support (see Capability filtering).
- Rank (best-effort) — candidates are scored by a ranking step that estimates which models suit the specific prompt. If that ranking is unavailable, EmaFusion™ falls back to static accuracy rankings and continues.
- Filter by capability — any candidate that lacks a required capability is dropped. If filtering leaves nothing, the request fails with a clear "no models available with required features" error.
- Optimize — the surviving candidates are ordered by your optimization priority.
- Cascade with confidence scoring — EmaFusion™ calls candidates in order, scoring each answer's confidence, and returns the first that clears the threshold.
- Record telemetry — EmaFusion™ logs which model was selected, how deep the cascade went, the confidence score, the candidates considered, the optimization criteria, and the call duration. Request and response bodies are not stored.
Capability filtering
Not every model can do everything. Some can call tools (functions), some can return strictly structured JSON, some support log-probabilities. EmaFusion™ derives the capabilities a request needs and only routes to models that have them. The mapping is:
| If the request… | Required capability |
|---|---|
| asks for log-probabilities | LOG_PROBABILITY |
| includes tools for the model to call | FUNCTION_CALLING |
| asks for a JSON-object response format | JSON_MODE |
| provides a JSON schema for the output | STRUCTURED_OUTPUT |
| looks like a live / web-lookup question | KNOWLEDGE_GROUNDED |
A model is kept only if its catalog entry lists every required capability. One special case: if requiring KNOWLEDGE_GROUNDED would eliminate all candidates, EmaFusion™ drops that one requirement and retries, so a live-data question still gets an answer rather than failing outright.
This is also why the AI Employee builder disables incompatible models in the picker: when you restrict an agent to specific models, models that lack a capability the agent needs are shown disabled with a reason, preventing a configuration that would fail at run time.
Optimization priority
When more than one candidate survives filtering, EmaFusion™ orders them by the optimization priority you set. There are four priorities (the builder labels are in parentheses):
| Priority | How candidates are ordered |
|---|---|
| Auto (Balanced) | Balances cost and latency — each candidate gets a blended score from its normalized cost and its estimated latency, and the best blend wins. This is the default. |
| Fastest | Lowest estimated latency first, based on the model's time-to-first-token and tokens-per-second against the expected output size. |
| Cheapest | Lowest effective cost first, summing prompt and completion token cost. Reasoning ("thinking") models are penalized because their output tokens dominate cost. |
| Most accurate | Ordered by Ema's benchmarked accuracy ranking — higher-ranked models first. |
The optimization priority sets the order candidates are tried in; it doesn't pin a single model. The confidence cascade then walks that order.
The optimization priority is only meaningful when EmaFusion™ has more than one model to choose from — that is, in Let Fusion Pick mode, or in Limit to Specific Models mode with two or more models selected. With a single selected model there is nothing to rank, so the priority control is hidden.
Confidence and cascading
EmaFusion™ doesn't just call the top-ranked model and return whatever comes back. It scores each response's confidence and cascades to the next candidate if the answer is weak.
How confidence is measured. EmaFusion™ uses self-reported confidence: it appends an instruction to the request asking the model to emit a per-sentence confidence marker in the form ((x%)). After the response comes back, EmaFusion™ averages those markers into a single 0–100 score, then strips the markers from the text before returning it — so the confidence machinery is invisible in the final output.
Thresholds. A response is accepted when its confidence meets the threshold for the active optimization priority:
| Optimization priority | Confidence threshold |
|---|---|
| Auto (Balanced) | 75 |
| Fastest, Cheapest, Most accurate | 60 |
The cascade. EmaFusion™ tries candidates in optimization order, up to a maximum of three:
- Call the next candidate and score its confidence.
- If the score meets the threshold, return that response immediately. The result is recorded with the reason
success. - If it doesn't, keep the response as a fallback and move to the next candidate.
- If no candidate clears the threshold within three attempts, EmaFusion™ returns the highest-confidence response it saw. This is recorded with the reason
backtrack.
If a candidate errors (for example, the provider is unreachable), EmaFusion™ skips it and tries the next one. Only if every candidate errors does the request fail.
EmaFusion™ also has a logit-based confidence mode that scores answers from the model's token log-probabilities using five weighted signals (log-probability, stability, entropy, perplexity, and top-token margin). It is wired into the pipeline but currently falls back to self-reported confidence, because the model adapters don't yet return raw log-probabilities. You don't configure this — EmaFusion™ uses self-reported confidence today.
The model catalog
EmaFusion™ routes across a broad, regularly updated catalog spanning many providers and model families — OpenAI GPT and reasoning (o-series) models, Anthropic Claude, Google Gemini, and others, plus embedding models for document ingestion and search. Each catalog entry records the model's context window, per-token cost, latency characteristics, and capability set, which is exactly the metadata the routing pipeline uses above.
The catalog is maintained by Ema. New models are added centrally, so AI Employees set to Let Fusion Pick automatically gain access to them with no rebuild. Which catalog models are actually available to your AI Employees depends on the providers your administrator has configured and enabled — see EmaFusion™ setup.
To see the exact models available in your workspace, open Admin → Workspace → LLM Providers. The Models section lists every model discovered from your connected providers, with its model ID and per-1K token costs, and a toggle to enable or disable it workspace-wide.
Token tracking
Every model call EmaFusion™ makes is recorded with its token usage — prompt tokens and completion tokens — attributed to the run, step, and agent execution that triggered it. This per-call record is independent of the run-level token totals shown in the workflow run view, and it gives a precise, per-model accounting for billing and audit.
What's next
- EmaFusion™ setup — choose a model-selection mode and optimization priority, override per agent, and configure providers.
- Autopilot — build and edit AI Employees, including their model configuration, through a conversation.