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 using each agent's input mapping.

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) → Custom Agent (custom) with a knowledge base attached, using Human in the loop.

The shape

Start ─▶ Intent Classifier ─▶ (billing)   ─▶ Custom Agent + HITL ─▶ Publish ─▶ End
                            └▶ (technical) ─▶ Custom Agent        ─▶ 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: the Instructions field is set in the panel, and the classified text comes from the Start node's message field. The agent returns the matched 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. Custom Agent (custom) on each answerable branch. Add it from Frequently Used and attach your help-center Knowledge Base. Declare a Text input named question and map it from the Start node's message field. In Instructions, reference {{input.question}} and ask the agent to answer only from the attached documents with source citations. Set an output schema with a required string field named answer so the Publish mapping below has a stable field to read.
5. Human in the loop on the billing branch. On the billing Custom 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 Custom 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 contract field. 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) and define the rules to check in the agent's Rules configuration:

   {
     "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] }
       }
     ],
     "boolean_aggregation": "all"
   }

   It returns {"rules": [...]} — one entry per rule with the following fields:

   Field	Type	Description
   rule_id	string	Echoes the rule_id you configured.
   data_sufficiency	boolean	Whether the input contained enough information to evaluate the rule.
   rationale	string	Step-by-step reasoning for the verdict.
   boolean_output	boolean	Present for boolean rules. The pass/fail verdict.
   numerical_output	integer	Present for numerical rules. A score drawn from the rule's possible_scores.
   not_applicable	boolean	Whether the rule doesn't apply to this input.
   evidences	array	Verbatim quotes and page numbers from the source documents that support the verdict.

   For example, rule R1 might return:

   {
     "rule_id": "R1",
     "data_sufficiency": true,
     "rationale": "The contract states an effective date of 2025-01-15 in Section 1.2.",
     "boolean_output": true,
     "not_applicable": false,
     "evidences": [
       {
         "text": "This Agreement shall become effective as of January 15, 2025.",
         "source_origin": "contract.pdf",
         "source_page_number": 1
       }
     ]
   }

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. Custom Agent (custom) with a knowledge base attached and mid-execution HITL.

The shape

Start ─▶ Custom Agent (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. Custom Agent (custom). Add it from Frequently Used. Declare a Text input named question and map it from {{workflow_input.message}}. In Instructions, reference {{input.question}} and ask the agent to search the attached Knowledge Base, answer only from its documents, and cite the sources it uses. Set an output schema with a required string field named answer. The agentic loop defaults to 20 iterations; configure type_config.max_iterations to adjust the budget.
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 Custom Agent can search a Knowledge Base and ask clarifying questions through the agentic loop. Knowledge-base search and ask_human are Tools the model can call. If you need retrieval as a separate reusable step, configure another Custom Agent with a Knowledge Base and an output schema for the evidence the next agent needs.

Where to go next

• Creating a Dashboard AI Employee — the full mechanics behind Example 2's table.
• Build your first workflow — nodes, edges, input mappings, and the save / test / publish model used throughout.
• Agent Reference — every agent type, with the configuration and output contract for each.
• Core concepts — workflows, agents, knowledge bases, conditions, and human in the loop.