Automate Customer Service with Tool Use
Force a tool call on every turn with tool_choice='required' to build a deterministic customer-service agent.
Maintainer of this project? Claim this page to edit the listing.
1.0.0Add to Favorites
Why it matters
Enhance customer service operations by creating a deterministic LLM agent that reliably uses defined tools for specific customer issues. This ensures consistent and controlled interactions, leading to improved customer satisfaction.
Outcomes
What it gets done
Configure LLM to use specific tools for customer service tasks.
Implement mandatory tool calls for deterministic agent behavior.
Simulate customer interactions using a GPT tester for evaluation.
Develop a contained customer service flow with defined exit points.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/oai-usingtoolrequiredforcustomerservice | bash Overview
Using Tool Required for Customer Service
An OpenAI Cookbook example using tool_choice='required' to build a deterministic customer-service agent, evaluated with a second GPT playing the customer across a multi-turn conversation. Use tool_choice='required' when you need guaranteed tool use every turn for a contained flow like customer service, rather than leaving tool use optional.
What it does
This notebook demonstrates tool_choice='required' on the Chat Completions endpoint, which forces the model to call a tool on every request rather than optionally replying in plain text. It builds a contained customer-service agent around this: config defines tools and instructions the agent sources based on the customer's issue, illustrated with a customer reporting fraud, then generates plausible next steps to keep the conversation going.
When to use - and when NOT to
Use tool_choice='required' when you need deterministic control over a wrapping application's flow - for example, a customer-service agent with defined exit points - rather than leaving it up to the model whether to call a tool at all. Because it's a demo, the agent is instructed to make up plausible values where it lacks a real external system to source information from; a production version would replace that with real backend calls.
Inputs and outputs
The worked example runs a fraud-report scenario through the agent, and instructs a second, separate GPT to play the customer role and generate plausible next messages, keeping the conversation moving without a human in the loop.
Integrations
A multi-turn evaluation wraps the same functions into an execute_conversation loop, where a customer-playing GPT and the customer-service agent go back and forth until a resolution is reached - giving an automated way to stress-test the agent's tool-required behavior across a full conversation rather than just a single turn.
Who it's for
Developers building contained, tool-driven conversational flows - like customer service - who want deterministic tool use guaranteed on every turn, plus a simple pattern for spinning up an automated GPT tester to evaluate the resulting agent end to end.
Source README
Using Tool Required for Customer Service
The ChatCompletion endpoint now includes the ability to specify whether a tool must be called every time, by adding tool_choice='required' as a parameter.
This adds an element of determinism to how you build your wrapping application, as you can count on a tool being provided with every call. We'll demonstrate here how this can be useful for a contained flow like customer service, where having the ability to define specific exit points gives more control.
The notebook concludes with a multi-turn evaluation, where we spin up a customer GPT to imitate our customer and test the LLM customer service agent we've set up.
Config definition
We will define tools and instructions which our LLM customer service agent will use. It will source the right instructions for the problem the customer is facing, and use those to answer the customer's query.
As this is a demo example, we'll ask the model to make up values where it doesn't have external systems to source info.
Example
To test this we will run an example for a customer who has experienced fraud, and see how the model handles it.
Play the role of the user and provide plausible next steps to keep the conversation going.
Evaluation
Now we'll do a simple evaluation where a GPT will pretend to be our customer. The two will go back and forth until a resolution is reached.
We'll reuse the functions above, adding an execute_conversation function where the customer GPT will continue answering.
Conclusion
You can now control your LLM's behaviour explicitly by making tool use mandatory, as well as spin up GPT testers to challenge your LLM and to act as automated test cases.
We hope this has given you an appreciation for a great use case for tool use, and look forward to seeing what you build!
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.