> For the complete documentation index, see [llms.txt](https://angoor-ai.gitbook.io/angoor-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://angoor-ai.gitbook.io/angoor-ai/tutorials/setup-a-simple-voice-agent/tool-configuration.md).
# Tool Configuration
Tools are specialized AI components that perform specific tasks within an Agent or Flow. While an Agent manages conversations and generates responses, Tools perform focused operations such as classification, routing, extraction, validation, orchestration, and decision-making. Think of an Agent as an employee and a Tool as a specialist the employee consults whenever a specific task needs to be completed.
#### 3.1 Why Use Tools
In a simple system, the Agent does everything. In a scalable enterprise system, complex responsibilities are delegated to Tools — intent classification, lead qualification, sentiment analysis, call routing, state detection, workflow orchestration, data extraction, and form validation. This separation improves performance, maintainability, accuracy, and scalability.
Consider a customer-support agent. The Agent holds the conversation, but determining whether the caller wants to book an appointment, raise a complaint, check account details, or speak to a human requires classification logic. Instead of embedding that logic in the Agent, a Tool performs the classification and returns the result — keeping the Agent prompt clean and the system easy to manage.
**Navigate to:** `Configuration → Tools`
#### 3.2 Tool Lifecycle
Every Tool follows the same lifecycle: it receives information, processes it using its prompt and model, and returns a structured output that Agents and Flows can use.
#### 3.3 Creating a Tool
1. Navigate to the Tools page.
2. Click New.
3. Configure the Core settings.
4. Configure the model.
5. Save the Tool.
Once created, the Tool becomes available inside Agents and Flows. Every Tool contains four tabs: Core (prompt and business logic), Settings (model and behavior), Analytics (usage and performance), and Playground (testing environment).
#### 3.4 The Tool Prompt
The Tool Prompt defines how the Tool processes information. Unlike Agent prompts, Tool prompts are usually more focused, more deterministic, and task-specific.
For example, a Call Orchestrator Tool may be responsible for analyzing the conversation transcript and deciding whether the conversation is active or completed, returning exactly one of:
* `welcome_message`
* `conversation`
* `cut_call`
**Writing effective Tool prompts**
A good Tool prompt clearly defines the task, the expected inputs and outputs, limits unnecessary creativity, and returns structured results.
Example:
`TASK You are a specialized tool that performs one focused job: {{describe the single task — e.g. classify, route, extract, validate, or analyze}}. Do only this task. Do not hold a conversation or add commentary.`
`INPUTS You will receive:`
* `conversation_history: the transcript or context to work from`
* `{{any other variables the tool needs, e.g. current_state, customer_name}}`
`WHAT TO DO`
* `Read the inputs carefully.`
* `{{state the exact logic — e.g. "classify the input into one of the categories below" / "extract the requested field" / "decide pass or fail"}}.`
* `Base the result only on the information provided. Do not assume or invent details that are not present.`
`POSSIBLE OUTPUTS Return exactly one of the following:`
* `{{option_1}}`
* `{{option_2}}`
* `{{option_3}} {{(for extraction tools, instead describe the exact format, e.g. a JSON object with named fields)}}`
`RULES`
* `Stay strictly within this task; ignore anything outside its scope.`
* `When uncertain, choose the safest / most conservative option: {{name the default, e.g. "prefer option_2 when in doubt"}}.`
* `Be consistent: the same input should always produce the same output.`
`OUTPUT FORMAT Return ONLY the result — no explanation, no punctuation, no extra text.`
#### 3.5 Tool Inputs — Knowledge Base, Variables, Forms
#### Overview
Beyond its prompt, a Tool can draw on three input sources that let it make dynamic decisions instead of acting on static instructions: a Knowledge Base, Variables, and Forms.
#### Refer Knowledge Base
Lets a Tool make decisions using your business information, just as Agents do.
**Use cases:** Product categorization, FAQ matching, policy validation, service recommendation.
**Example:** A routing Tool checks the "Support Policy" knowledge base to decide whether a refund qualifies for auto-approval or must be escalated.
#### Refer Variable
Variables pass live information into a Tool, making it reusable across workflows. Without them a Tool processes only static data; with them it adapts to each call.
**Common variables:**
* `conversation_history` — the full conversation transcript
* `current_state` — the current workflow state
* `customer_name` — the caller's identity
* `ticket_id` — a support reference
**Example:** The Call Orchestrator reads `conversation_history` and `current_state`, then returns the updated state (`welcome_message`, `conversation`, or `cut_call`).
#### Connect Form
Connects a Tool directly to a Form so submitted data is processed automatically and acted on in real time.
**Example:** A Lead Capture Form (Name, Email, Phone Number, Product Interest) is evaluated by the Tool to determine lead quality, follow-up priority, and routing path.
#### 3.6 Conditional Prompts in Tools
Conditional Prompts let a Tool change behavior based on conditions. Example: when customer sentiment equals Negative, an additional instruction "Prioritize escalation recommendations" is applied automatically.
#### Example
**Scenario:** Make a routing Tool prioritize escalation when a caller is unhappy.
**WHEN (condition)**
| Field | Operator | Value |
| ----------- | -------- | ---------- |
| `sentiment` | Equals | `negative` |
**Instruction (applied when true):**
> "Prioritize escalation recommendations and flag the conversation for human follow-up."
**Result:** When the condition is met, the Tool automatically adjusts its logic for that call — without changing its base prompt.
#### 3.7 Tool Settings — Metadata, Features & Model
The Settings tab controls operational behavior. Metadata (Name, Description) and Tags (Routing, Classification, Validation, Analytics, Automation) improve discoverability as the number of Tools grows. Custom Features add capabilities.
#### Overview
The Settings tab controls a Tool's operational behavior — how it is organized, what extra capabilities it has, and how much conversation context it works with.
#### Tags
**Description:** Labels used to categorize and organize Tools. You can search existing tags or add new ones.
**Why it matters:** As the number of Tools grows, tags make them easy to find, filter, and manage.
**Examples:** `Routing`, `Classification`, `Validation`, `Analytics`, `Automation`
#### Custom Features
**Description:** Toggles that give the Tool additional processing capabilities.
#### Include Context as User Message
**Description:** Injects additional context into the Tool's prompt as a user message.
**Why it matters:** Useful when external information must be considered during processing.
**Example:** The caller's account tier is passed in as context so a routing Tool can factor it into its decision.
#### Uses History
**Description:** Lets the Tool access previous conversation history rather than only the current input.
**Why it matters:** Enables better context awareness, improved decision-making, and stateful workflows.
**Example:** A state-detection Tool reviews the last several turns to decide whether the conversation has genuinely ended.
**Current value:** `Enabled`
#### History Top K
**Description:** Controls how many previous messages the Tool can access as context.
**Why it matters:** Higher values give the Tool more context but increase token usage, so set it to match the complexity of the task.
**Recommended values:**
* Simple classification: `3`
* Customer support: `5`
* Complex workflows: `10`
**Example:** With History Top K set to `3`, a classification Tool sees the last three messages — enough to judge intent without wasting tokens on older turns.
**Model parameters**
Tools are powered by a model (example: O4 Mini, Fast response, 128K tokens). Model parameters control how outputs are generated through three modes:
| Mode | Produces | Recommended for |
| -------- | --------------------------------------- | -------------------------------------------------------------------------- |
| Creative | More varied outputs | Content/idea generation, brainstorming — not routing or classification |
| Balanced | A balance of creativity and consistency | General-purpose tools, mixed workloads |
| Precise | Deterministic, predictable outputs | Routing, classification, state detection, validation — most workflow tools |
**Temperature, Top P & Max Tokens**
Temperature controls randomness: lower is more predictable and consistent, higher is more creative and varied.
| Use case | Temperature |
| ------------------ | ----------- |
| Classification | 0.1 |
| Routing | 0.1 |
| Validation | 0.2 |
| Content generation | 0.7 |
**Top P** controls response diversity (0.7–0.9 for workflow tools). **Max Tokens** sets the maximum output length; since most workflow tools return short outputs (a state name, a classification label, a routing decision), very large token limits are rarely necessary.
#### 3.8 Analytics & Playground
The Analytics tab provides visibility into Tool performance: invocation count, success rate, failure rate, token consumption, and response latency. Monitoring these helps identify optimization opportunities. The Playground is used to test Tool behavior before deployment — one of the most important development stages. Without testing, incorrect outputs may reach production, routing may fail, and workflows may break; with proper testing, prompts are validated, edge cases identified, and output quality improved.
#### 3.9 Example — The Call Orchestrator Tool
One of the most important Tools in voice workflows is the Call Orchestrator Tool. Its purpose is to analyze the conversation and determine its current state. It acts as the decision engine for the Flow.
| State | Description |
| ---------------- | ---------------------- |
| welcome\_message | Initial greeting stage |
| conversation | Active discussion |
| cut\_call | Conversation completed |
**Also:** return structured outputs, use Precise mode (most business workflows need consistency over creativity), and test extensively with real-world conversation examples before deployment.