Building a Customer Support Agent with Claude and Tool Use

A customer support agent doesn't need many parts: a few tools, a loop that runs them and a system prompt with firm rules. Most of the effort goes into those rules and into deciding which actions need a person to approve them.

Step 1: Define a small set of tools

tools = [
    {
        "name": "lookup_order",
        "description": "Get status, items and delivery date for an order. Use when the customer mentions an order.",
        "input_schema": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
        },
    },
    {
        "name": "search_help_center",
        "description": "Search published help articles. Use before answering any policy question.",
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
        },
    },
    {
        "name": "escalate_to_human",
        "description": "Hand the conversation to a human agent with a short summary.",
        "input_schema": {
            "type": "object",
            "properties": {"summary": {"type": "string"}},
            "required": ["summary"],
        },
    },
]

Tool descriptions matter. Say what each tool does and when Claude should use it.

Step 2: Run the loop

Send the conversation and the tools to Claude. When the response has stop_reason set to tool_use, run each requested tool and send back a tool_result block with the matching tool_use_id. Then call Claude again. The loop ends when Claude replies with text for the customer.

If a tool fails, send the error back with is_error: true instead of leaving it out. Claude can then tell the customer something useful, such as that it couldn't find the order.

Step 3: Write clear rules

The system prompt should say:

• Only describe policies found through search_help_center.
• Never promise refunds, credits or delivery dates that the tools didn't return.
• Hand over to a person for legal threats, safety issues or when the customer asks.
• Keep replies short and easy to read.

Step 4: Require approval for risky actions

Anything that moves money or changes an account shouldn't happen directly from the model's decision. Have the tool create a pending request for a staff member to approve, or ask the customer to confirm first.

Step 5: Test with real conversations

Take 50 past support conversations, including angry and unclear ones, and run them through the agent. Check that it escalates when it should, never invents a policy and handles routine requests without help.

Common problems

• Customer messages and order notes are data, not instructions. Expect people to try "ignore your previous instructions".
• Without logs you can't investigate complaints. Record every tool call with a conversation ID.
• Too many tools too early makes behavior harder to predict. Add new tools one at a time and test each.

Spend most of your time on the rules and the approval steps. The model call itself is the simplest part of the system.