Tools: Extending Agent Capabilities
In our financial compliance example, we’ve built a system that can process transactions, flag suspicious ones for human approval, and generate summary reports. But what if we need to check for duplicate payments? Our agents currently have no way to access historical transaction data or perform specific calculations outside their knowledge.
This is where tools come in - they bridge the gap between your agents’ intelligence and the external world.
The Need for Specialized Tools
As our financial compliance system evolves, we might need to:
- Check new transactions against a database of past payments
- Calculate risk scores based on complex algorithms
- Connect to third-party fraud detection APIs
- Access internal company systems and databases
These tasks go beyond what an LLM can do with just its internal knowledge, requiring specialized functionality that connects to external systems.
Understanding Tools in AG2
In AG2, tools provide a structured way for agents to interact with the outside world. Think of tools as specialized functions that agents can choose to use when appropriate.
An Analogy for Tools:
Continuing our hospital emergency room analogy from the Group Chat pattern:
- Think of tools like specialized medical equipment in the hospital (MRI machines, blood analyzers, EKG monitors)
- When a specialist (agent) examines a patient, they might determine “We need an MRI scan to diagnose this properly”
- However, the specialist doesn’t operate the MRI machine themselves
- Instead, a technician (executor agent) with expertise in that specific equipment runs the scan
- The technician returns the scan results to the specialist, who then interprets them to continue treatment
Just as hospital specialists rely on specialized diagnostic equipment operated by trained technicians, AG2 agents can call upon tools that are executed by designated executor agents. This separation ensures that each component focuses on what it does best: the specialist on diagnosis and treatment decisions, and the technician on properly operating complex equipment.
This approach separates “deciding what to do” from “actually doing it,” creating a more robust and controlled execution model.
How Tool Usage Works in AG2
Tool usage in AG2 follows a simple but powerful two-step process:
- Selection: An agent (driven by its LLM) decides which tool is appropriate based on the given task
- Execution: A separate executor agent invokes the tool and returns the results
!!! note For a more detailed explanation of how tools work in AG2, check out the Tools Overview documentation.
Enhancing Our Financial System with Tools
Let’s enhance our financial compliance system by adding a powerful new capability: duplicate payment detection.
The Challenge
Duplicate payments are a common problem in financial systems. A company might accidentally pay the same invoice twice, or a fraudster might try to get multiple payments for the same service.
Our current system can detect suspicious transactions but has no way to check if a transaction is a duplicate of one that’s already been processed.
Our Tools Solution
Here’s how we’ll enhance our system:
- Create a function that checks a transaction against a database of previous payments
- Register this function as a tool that our
finance_bot
can use - Modify the workflow to check each transaction for duplicates before processing it
- Automatically reject duplicate payments without requiring human approval
Implementation: Creating a Duplicate Detection Tool
First, let’s create a function that checks for duplicate payments:
In this code:
- We created a mock database function to simulate retrieving past transactions
- We defined a duplicate detection function that compares a new transaction against past ones
- The function uses
Annotated
to provide clear parameter descriptions, which helps the agent understand how to use the tool - The function’s docstring will be used to describe the tool to the LLM
- The function checks if the transaction is a duplicate based on vendor, amount, memo and transaction is within 7 days
- It returns a dictionary indicating whether the transaction is a duplicate and why
Updating Our Agents for Tool Usage
Now let’s update our agent system messages to incorporate duplicate checking:
We’ve updated both agent system messages:
- The
finance_bot
now knows to extract transaction details and check for duplicates before evaluation - The
summary_agent
knows to include the reason for rejection, which might be duplicate detection
Registering the Tool
Next, we need to register our duplicate detection function as a tool:
With this registration:
- The
finance_bot
can now suggest using thecheck_duplicate_payment
tool when appropriate - We will continue using a Group Chat and an internal tool executor will execute all tool recommendations automatically
Generating Test Data with Duplicates
Let’s create sample transactions that include duplicates:
Putting It All Together
Now let’s run our enhanced financial compliance system with duplicate detection:
Understanding the Enhanced Workflow
When we run this enhanced financial compliance system, here’s what happens:
Complete Code Example
Here’s the complete, ready-to-run code for our enhanced financial compliance system with duplicate detection:
???+ info “Complete Code Example”
How to Run This Example
- Save the code above to a file (e.g.,
financial_compliance.py
) - Set your OpenAI API key in your environment variable or use your preferred model provider
- Make sure you have AG2 installed:
pip install ag2[openai]
- Run the script: python
financial_compliance.py
Example Output
When you run this code, you’ll see a workflow similar to this:
Best Practices for Tool Usage
When implementing tools in your AG2 systems, consider these best practices:
- Descriptive Parameter Annotations: Use Annotated types with clear, concise descriptions for each parameter. This helps the LLM understand exactly what information it needs to provide when calling the tool.
- Meaningful Function Descriptions: Provide detailed function docstrings when registering tools that clearly explain the tool’s purpose. This guides the LLM in selecting the right tool for the right situation.
- Intuitive Parameter Names: Use predictable, consistent, and self-explanatory parameter names that align with how the LLM might think about the data. Avoid abbreviations or technical jargon in parameter names.
- Explicit Guidance in System Messages: Include clear instructions in your agent’s system message about when and how to use specific tools. For example: “First check if the transaction is a duplicate using the
check_duplicate_payment
tool before evaluating it.”
Next Steps: Structured Outputs
Currently, our summary agent tries to follow instructions but has flexibility in how it structures its response. For integration with other systems, we need more control over the output format.
This is where structured outputs come in. In the next section, we’ll enhance our financial compliance system to:
- Define exact schemas for transaction reports using Pydantic models
- Ensure all required fields are present and properly typed
- Guarantee consistent output structure for integration with downstream systems
- Automatically validate outputs before they’re sent to other services
By combining tools (which extend what our agents can do) with structured outputs (which constrain how our agents respond), we’ll create a robust financial compliance system that can seamlessly integrate with other enterprise systems.