Skip to content

Tool Configuration

Tools help an agent do real work with less mental effort per reply. Add them when instructions alone are no longer enough to keep the agent accurate, consistent, or efficient.

For the Consultation Desk example, tools are not the starting point. The starting point is still a clear agent role. Add a tool only when you can point to a repeated job the agent should handle more reliably:

  • Look up stable reference material
  • Check the latest public information
  • Hand off to a more specialized agent
  • Collect structured intake details
  • Send or fetch structured data from another system
  • Remember stable user preferences across conversations

Consultation Desk with multiple tools configured

Start with the job, not the menu

Use this decision order:

  1. Does the agent need stable reference material that should stay consistent across conversations?

    • Use Knowledge Base for larger reference material.
    • Use Attachments for small, always-on reference files that should be present every turn.

  2. Does the agent need the latest public information?

  3. Does another agent already do one part of the workflow better?

  4. Do you need the user to provide information in a clean structure?

    • Use Request Form after the conversation reaches that stage.

  5. Does the agent need to send or fetch structured data from another system during the conversation?

    • Use HTTP Request only for a narrow business action, such as creating a callback lead or checking availability.

  6. Do you need to remember stable user preferences across future conversations?

    • Use Memory with narrow rules about what is safe to store.

Keep the first version small

Start with one tool, test it in Live Test, and add the next tool only if it solves a different problem. Most weak tool setups come from adding too many tools before the operator understands the agent's real failure pattern.

The Main Tools in This Section

Tool Use it when Do not use it for
Knowledge Base The agent needs stable documents, SOPs, policies, FAQs, or reference notes Live external information
Web Search The user explicitly needs the latest public information Replacing your own product or policy knowledge
Call Agent Another agent has a clearer, narrower specialty Splitting a simple task just because the tool exists
Request Form You need structured intake after the next step is clear Opening every conversation with a form
HTTP Request The agent needs to send or fetch structured data through an external API Vague “do anything” integrations without a stable contract
Memory You need stable, user-confirmed preferences later Sensitive details, one-time notes, or secrets

Open the Tool Picker

In Editor, scroll to Tools and click Add Tool. The picker shows what is currently available in the workspace.

Tool picker with currently available tool types

Some options stay disabled until their prerequisites exist:

  • Knowledge Bases stays unavailable until the workspace has at least one usable knowledge folder or file.
  • Agent Tools stays unavailable until another agent exists and has a published version you can safely call.
  • Memory is limited to one per agent.

Write Better When to Use Instructions

Most tool mistakes are not product bugs. They come from vague invocation guidance.

Strong When to Use instructions:

  • Describe a real user request
  • Make the trigger narrow enough to avoid unnecessary tool calls
  • Explain priority when more than one source could answer

Weak:

Use this tool when needed.

Strong:

Use this knowledge base when the user asks about consultation types, routing rules, or handoff expectations that should stay consistent across conversations.

Strong:

Only use Web Search when the user explicitly asks for the latest public guidance, and prefer official or medically reviewed sources before answering.

Tool Limits and Operator Habits

  • Total tools per agent: 10
  • Maximum Call Agent tools: 5
  • Maximum Memory tools: 1
  • Tools run sequentially, so every extra tool increases the chance of a slower or less predictable path

In practice, a small, opinionated tool setup is easier to debug than a large one.

For this example, a practical tool stack looks like this:

  • Knowledge Base for service definitions and routing rules
  • Web Search only for latest external guidance
  • Call Agent for the Scheduling Desk specialist handoff
  • Request Form for structured callback intake after the handoff is chosen
  • HTTP Request when the callback workflow should also create a CRM lead or check an external scheduling system
  • Memory for stable user preferences such as language or callback preference

You do not need every tool on day one. Add them in the order your testing shows they are needed.

Next Steps