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.Documentation Index
Fetch the complete documentation index at: https://docs.ag2.ai/llms.txt
Use this file to discover all available pages before exploring further.
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
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
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
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_botcan 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:- 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
Annotatedto 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:- The
finance_botnow knows to extract transaction details and check for duplicates before evaluation - The
summary_agentknows 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:- The
finance_botcan now suggest using thecheck_duplicate_paymenttool 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_paymenttool 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