> Source: https://builder.ema.ai/v2/core-concepts/agents > Title: Agents # Agents An **agent** is a reasoning node inside a [workflow](/builder/v2/core-concepts/workflows) — a node whose `type` is `agent`. It uses an LLM (selected by EmaFusion™) to do one well-defined job: classify an input, search and answer, extract structured data, validate against rules, or follow free-form Instructions. You don't write agent code. You pick an **agent type**, give it **Instructions**, and configure its inputs, attached **Knowledge bases**, and **Tools**. The platform handles the model selection, the retrieval, and the tool-calling loop. Agents are configured from **templates** — reusable starting points that bundle an agent type, an input schema, an Instructions template, default LLM behavior, and type-specific settings. Dragging a template into a workflow copies its configuration onto the node. From then on, the node carries its own inline copy: editing the template later never changes a published workflow. > [INFO] > **Templates are a starting point, not a live link.** An agent node stores its full configuration inline in the workflow DAG. The template catalog exists only to seed new nodes, so templates are always safe to edit or delete without affecting any running AI Employee. ## The agent types You choose an agent type when you create an agent. The four typed agents below each carry type-specific configuration and produce a validated, predictable output shape. Two more types — Respond and Custom — round out the picker: Respond is a plain LLM step, and Custom is the escape hatch. > [INFO] > These are the underlying agent **types** — the execution behaviors. The builder's **Add an Agent** library ships **15 ready-to-use agents** built on these types, grouped into Frequently Used, Generation, Planning & Resources, and Custom Agents. For the full list and how to configure each one, see the [Agent Reference](/builder/v2/agent-reference). Agent type `agent_type` value What it does Intent Classification `intent_classification` Labels an input as one of a fixed set of intents you define. The label drives [edge conditions](/builder/v2/core-concepts/conditions-and-expressions) so the workflow branches on it. Search & Respond `search_respond` Searches attached knowledge bases (RAG) and answers in natural language with source citations. Runs an iterative search-refine loop. Extraction `extraction` Pulls structured data out of text or documents into a JSON shape you define, validated against your schema. Rule Validation `rule_validation` Evaluates inputs against a tree of business rules and returns a verdict with supporting evidence per rule. Respond `respond` Follows your Instructions to generate a response, with no built-in retrieval or extraction behavior. The simplest LLM step. The picker also offers **Custom** (`custom`), for advanced cases where you author the behavior yourself. ### Intent Classification Give it a list of intents (categories). It reads the input and returns one of them as `output.intent`. Branch on the result with edge conditions — for example, route `"billing"` to one agent and `"technical"` to another. Intent classification is the standard way to fork a workflow on what the user wants. See [Conditions and Expressions](/builder/v2/core-concepts/conditions-and-expressions) for the branching mechanics. ### Search & Respond Attach one or more knowledge bases and write Instructions for tone and scope. The agent embeds the query, retrieves the most relevant chunks, and composes an answer that cites the sources it used. It runs an agentic search-refine loop bounded by `max_iterations` (default 20, capped at an absolute ceiling of 50) so it can search again if the first pass is thin without looping forever. This is the core type behind a knowledge-base Q&A AI Employee. See [Knowledge Bases](/builder/v2/core-concepts/knowledge-bases). ### Extraction Define an output schema (the fields and types you want), give the agent the text or documents to read, and it returns structured JSON matching that schema. The agent validates its own output against your schema and retries once with the validation error fed back if the first attempt doesn't conform. Large inputs are handled automatically by splitting the work and merging the results. Pair it with a [`transform` node](/builder/v2/core-concepts/workflows#node-types) when you need to reshape or default the extracted fields without spending tokens. ### Rule Validation Provide a set of business rules (which may be nested into rulesets). The agent evaluates the input against them and returns, per rule, a verdict, a rationale, and the evidence it relied on, plus an aggregate result. Rules that can be checked deterministically don't consume LLM calls; only the rules that need judgment go to the model. Use it for compliance checks, eligibility scoring, and document review. ### Respond and Custom - **Respond** is a plain LLM step: it follows your Instructions and returns a response, with no retrieval or schema behavior layered on. Reach for it when you just need the model to write something based on upstream data. - **Custom** is the escape hatch for behavior the standard types don't cover, including dispatching to your own external service. Custom agents are an advanced feature — see the [Agent reference](/builder/v2/agent-reference). ## Configuring an agent Regardless of type, an agent node shares a common set of configuration: - **Instructions** — the natural-language guidance the model follows. Reference upstream data and named inputs with `{{...}}` (see [Conditions and Expressions](/builder/v2/core-concepts/conditions-and-expressions#passing-data-with-variables)). Always use the term Instructions, not "prompt." - **Inputs** — map the data the agent consumes from the run input (`{{workflow_input.field}}`) and from upstream nodes (`{{node_id.output.field}}`). - **Knowledge bases** — the document collections the agent may search. Each attachment can carry a folder filter to scope retrieval. See [Knowledge Bases](/builder/v2/core-concepts/knowledge-bases). - **Tools** — the integration functions and MCP servers the agent may call. The agent exposes them to the model and runs a tool-calling loop. Tool parameter binding comes from the integration's published function schema at run time. - **EmaFusion™ behavior** — by default the agent inherits the workflow's model behavior; you can override it per node. See [EmaFusion™](/builder/v2/emafusion). - **Human in the loop** — optionally attach a `hitl_config` block so the agent can pause for an approval, a form, or a question. See [Human in the Loop](/builder/v2/core-concepts/human-in-the-loop). ## How an agent runs When the workflow executor reaches an agent node, it: 1. Resolves the node's inputs from the run input and upstream outputs. 2. Calls the agent runtime with the node's full inline configuration. 3. The runtime composes the system Instructions, retrieves from any attached knowledge bases, and exposes the selected Tools to the model. 4. The model reasons and, if needed, calls Tools or searches again in a loop, until it produces a final answer. 5. If the agent calls the human-in-the-loop tool, the run pauses; it resumes with the person's response folded back into the agent's context. 6. The runtime validates the output (for the typed agents) and returns it. The executor stores it as the step output for downstream nodes. Agent execution on the hot path is stateless — the workflow service owns the run history, and the agent runtime holds no per-run state between calls. That keeps execution horizontally scalable. ## Where to go next - [Agent reference](/builder/v2/agent-reference) — per-type configuration in depth, including Custom agents. - [Knowledge Bases](/builder/v2/core-concepts/knowledge-bases) — what Search & Respond retrieves from. - [Human in the Loop](/builder/v2/core-concepts/human-in-the-loop) — pausing an agent for human input. - [Conditions and Expressions](/builder/v2/core-concepts/conditions-and-expressions) — branching on an agent's output.