1. Ema v2 Docs
  2. Builder Guides
  3. Worked Examples

Worked Examples

The other guides in this section cover each building block on its own. This page puts them together: three complete AI Employee (AIE) builds, start to finish, using the real agent types and workflow nodes you'd reach for in production. Each one names the nodes, shows the input mappings, and links to the reference page for every agent it uses.

Every example assumes you know the basics from Build your first workflow: a workflow is a directed acyclic graph (DAG) of typed nodes (Start, Agent, Transform, Publish, End), you connect them with edges, and you pass data between them with {{...}} input mappings.

Before you start. You need a builder role to create and edit AI Employees. Each example tells you which interaction type to pick at creation, since that's fixed up front.

Example 1 — support-triage AI Employee

The job. A customer message comes in. Classify what it's about, answer the routine questions automatically from your help center, and escalate the sensitive ones to a person before anything goes out.

Interaction type. Chat, or dashboard if you're triaging a queue in batch.

Agents used. Intent Classifier (intent_classification) → Search & Respond (search_respond) with Human in the loop.

The shape

Start ─▶ Intent Classifier ─▶ (billing)   ─▶ Search & Respond + HITL ─▶ Publish ─▶ End
                            └▶ (technical) ─▶ Search & Respond        ─▶ Publish ─▶ End
                            └▶ (other)     ─▶ End

Build it

  1. Start node. Add one Text input, key message, title "Customer message", required.
  2. Intent Classifier (intent_classification). Add it from the Frequently Used group. In its type_config, set the intents you want to route on and a default_intent as a safety net: 
    {
  "intents": ["billing", "technical_support", "other"],
  "default_intent": "other"
}

    Map its input: instructions is sourced from the panel, and the classified text comes from the Start node — the input-mapping editor writes {{workflow_input.message}}. The agent returns {"intent": "<label>"}.

  3. Branch with conditional edges. Drag from the classifier's per-intent output handles. When you drag from an intent handle, the builder stamps the matching output.intent condition onto the new edge automatically — so the billing edge carries output.intent == "billing", and so on. Send other straight to an End node.
  4. Search & Respond (search_respond) on each answerable branch. Attach your help-center knowledge base so the agent answers from your documents (with [N] citations) rather than general knowledge. Map its question input from the Start node's {{workflow_input.message}}. It returns {"answer": "...", "sources": [...]}.
  5. Human in the loop on the billing branch. On the billing Search & Respond agent, add a hitl_config so a person approves the answer before it's sent. A conversation-mode approval is the natural fit for chat: 
    {
  "mode": "conversation",
  "prompt": "Customer has a billing question. Approve this drafted reply?",
  "assign_to": "role:builder",
  "timeout": "1h",
  "timeout_behavior": "fail_run"
}

    The run pauses at this node, notifies an eligible reviewer, and resumes once they respond. See Designing human-in-the-loop forms.

  6. Publish + End. Add a Publish node on each answering branch declaring an answer field (wired from the Search & Respond agent's answer), then connect to End.

Why it's built this way

The Intent Classifier is the only node that should make the routing decision, and conditional edges read its output under the output.* namespace — so routing is explicit and auditable, not buried in an agent's Instructions. The sensitive branch is gated by HITL so a human is always in the loop on money matters, while routine technical questions flow through untouched. See Conditions and expressions for the full condition model.

Example 2 — document-extraction dashboard

The job. Upload a batch of contracts. Pull the key fields out of each one, then check each contract against your compliance rules — all in a table you can review and export.

Interaction type. Dashboard — one row per document, runs in parallel.

Agents used. Data Extractor (extraction) → Rule Validator (rule_validation).

The shape

Start (file input) ─▶ Data Extractor ─▶ Rule Validator ─▶ Publish ─▶ End

Build it

  1. Create a dashboard AI Employee. Set the interaction type to Dashboard at creation. The Dashboard tab becomes the AIE's main view.
  2. Start node. Add a File input, key contract, title "Contract", required. (A dashboard workflow must declare at least one input — see Creating a Dashboard AI Employee.) The file input becomes its own column on the table.
  3. Data Extractor (extraction). Define the fields to pull in type_config.output_schema: 
    {
  "output_schema": {
    "type": "object",
    "properties": {
      "party_name":   { "type": "string" },
      "effective_date": { "type": "string", "format": "date" },
      "contract_value": { "type": "number" },
      "auto_renews":   { "type": "boolean" }
    },
    "required": ["party_name", "effective_date"]
  }
}

    Map its document input from the Start node's {{workflow_input.contract}}. The agent validates its own output against this schema and self-corrects on a near-miss before returning it.

  4. Rule Validator (rule_validation). Wire the extractor's output into it (map the upstream fields, or pass the whole output with {{<extractor_node_id>.output}}) and define the rules to check in type_config.rules: 
    {
  "id": "contract_compliance",
  "type": "boolean",
  "rules": [
    { "rule_id": "R1", "rule_text": "The contract has an effective date." },
    { "rule_id": "R2", "rule_text": "Auto-renewal is disclosed in the contract." },
    {
      "rule_id": "R3",
      "rule_text": "Rate the completeness of the liability section from 0 to 5.",
      "type": "numerical",
      "numerical_rule_config": { "possible_scores": [0, 1, 2, 3, 4, 5] }
    }
  ]
}

    It returns {"rules": [...]} — one verdict, rationale, and cited evidence per rule.

  5. Publish + End. On the Publish node, declare the columns you want in the table — for example party_name, effective_date, contract_value from the extractor and a compliance field from the validator. These become the dashboard's output columns.

Run it

Open the Dashboard tab and Add a row for each contract (or select several files). A row stays in a draft state while its file is processed, then runs automatically. Watch the output columns fill in as each row completes; Show work opens the per-row trace; a row that hits a HITL form pauses for review. When you're done, Export the table as CSV or XLSX.

Why it's built this way

Extraction and validation are deliberately two nodes, not one. The Data Extractor's only job is to turn an unstructured document into schema-conforming JSON — which it can validate and retry on its own. The Rule Validator then reasons over that clean, structured input and produces an auditable, rule-by-rule verdict instead of a single yes/no. Splitting them keeps each agent's contract narrow and makes the dashboard columns map cleanly to "what we extracted" and "whether it passed."

Example 3 — knowledge-base helpdesk AI Employee

The job. An internal helpdesk that answers employee questions from your policy and IT documentation, and asks a clarifying question when the request is ambiguous.

Interaction type. Chat.

Agents used. Search & Respond (search_respond) with mid-execution HITL.

The shape

Start ─▶ Search & Respond (knowledge base + ask_human) ─▶ Publish ─▶ End

Build it

  1. Start node. A chat workflow exposes the reserved per-turn keys (message, conversation_history, user_context) automatically — you don't declare an input schema for a plain chat helpdesk.
  2. Set up the knowledge base. Ingest your policy and IT docs into a knowledge base and attach it to the agent.
  3. Search & Respond (search_respond). Map the user's question to the agent's input. With the knowledge base attached, the agent runs its agentic search-and-refine loop, retrieving chunks with numbered [N] source labels and answering from only that content. Tune the search-iteration count via type_config.max_iterations (default 3) if one pass isn't enough.
  4. Clarify with mid-execution HITL. Leave HITL enabled so the agent can call the built-in ask_human Tool when a question is ambiguous — the run pauses, asks the employee, and continues with their answer in context. (No extra node: this is the agent's own ask_human, described in Human in the loop.)
  5. Publish + End. Declare an answer field on the Publish node, wired from the agent's answer.

Why it's built this way

A single Search & Respond agent covers retrieval, citation, and the clarifying back-and-forth, because all three are exposed to the model through the same agentic loop — knowledge-base search and ask_human are just Tools the model can call. You don't need a separate retrieval node for a straightforward helpdesk; reach for the Knowledge Search Agent preset only when you want retrieval as a discrete, reusable step feeding other nodes.

Where to go next

Last updated: Jul 3, 2026