Skip to content

Tools

Tools let an Agent take actions – fetch data, call external APIs, execute code. Lookfor agents supports three categories of tools:

  1. Built-in tools – These are the tools provided by lookfor.ai. THe availability of tools to an agent depends on the type of the MAS the agent belongs to.
  2. Agents as tools – Agents can be used as tools. This is a powerful feature that allows you to create a very flexible and specialized MAS. We will cover this in the Agents as tools section.
  3. API tools – You can create your own API tools. By doing this you can use any API you want. We will cover this in the API tools section.

1. Built-in tools

Section titled “1. Built-in tools”

The built-in tools are different for each type of the MAS. See the list of the tools for each type:

If you have a new tool idea/request, please let us know.

2. Agents as tools

Section titled “2. Agents as tools”

Sometimes you want an Agent to assist another Agent without fully handing off the conversation. To do that, add an agent to the tool list of the agent.

Under the hood lookfor does the following:

  • Creates a single input parameter.
  • Runs the sub‑agent with that input when the tool is called. Notice that the sub-agent will not be able to see the conversation history. It won’t know it is a part of a MAS. It will think that it runs solely for that input.
  • Returns the last message as tool’s output to the caller agent.

Let’s say you want to create a MAS that translates French and Turkish texts to English. You can create three agents for that.

  • French Translator Agent
  • Turkish Translator Agent
  • Orchestrator Agent

You can add the French Translator Agent and the Turkish Translator Agent to the tool list of the Orchestrator Agent. When the Orchestrator Agent is called, it will run either/both of the agents based on the input like a tool. Let’s say half of the input is in French and half of the input is in Turkish. Orchestrator agent will run the French Translator Agent with the French part of the input and the Turkish Translator Agent with the Turkish part of the input. Translator agents will not have the conversation history. They will not know that they are a part of a MAS. They will think that they run solely for that input and will return the translated text. Orchestrator agent will return the result of the two agents, edit the text if needed, and return the final result as its output.

3. API tools

Section titled “3. API tools”

These are the tools that you can create yourself. You can create your own API tools. By doing this you can use any API you want. Let’s say your customers ask estimated delivery time for an order. If your shipping management system has an API to get the estimated delivery time, based on the location of the customer and the order, you can create a tool to call that API. To create a tool you need to define the followings:

  • Name – the name of the tool.
  • Description – a description of what the tool does.
  • Parameters – the parameters of the tool.

Here is an example of a tool definition. If you want to create an API tool, click on + on the tool list. Then you can fill the tool definition.

{
  "name": "Get Estimated Delivery Time Tool",
  "description": "Get the estimated delivery time using the location and product to be delivered.",
  "parameters": {
    "zipCode": " string",
    "productName": "string"
  },
  "Endpoint URL": "https://api.yourcompany.com/delivery-time/{zipCode}?product={productName}",
  "Method": "GET"
}

Forcing tool use

Section titled “Forcing tool use”

Supplying tools doesn’t guarantee the agent will use one. You can force tool use with Tool Choice setting in the advanced settings of the agent configuration:

  1. 'auto' (default) – the agent decides whether to use a tool.
  2. 'required' – the agent must call a tool (it can choose which one). If you remember every handoff is a tool, you can use this setting to force the agent to delegate to another agent.
  3. 'none' – the agent must not call a tool.

What happens after the tool is used?

Section titled “What happens after the tool is used?”

The behavior of the agent after the tool is used is determined by the Tool Use Behavior setting in the advanced settings of the agent configuration. There are two options for the Tool Use Behavior setting:

  • run_llm_again (default) – run the LLM again with the tool result. (e.g. if the tool is a web search, the agent will run again with the search result) Notice that the agent can call another tool after the first tool is used.
  • stop_on_first_tool – treat the first tool result as the final answer. (e.g. if the tool is a web search, the agent will stop and return the search result as its answer)

You can also configure the Tool Use Behavior setting to stop when any of the listed tools is called.

What is lookfor’s tool philosophy?

Section titled “What is lookfor’s tool philosophy?”

We believe that tools should be small and have a single responsibility. They should be like Lego blocks. You can combine them to create complex tools. If you have a set of Lego blocks, there are almost inifinite number of things that you can build with them. That is also similar, we don’t know what is the limit of the things that can be done with combining tools and agents in a MAS. We just know that we will keep adding more atomic tools as primitives and explore more patterns to combine them. Rest of the things are up to you. Do not forget to let us know if you have any tool ideas or requests.