Tool-calling for merchant support agents

Merchant support workflows have a repeatable structure: look up the merchant, check the account status, review the recent transaction history, run a diagnostic, draft a response. Each step is a well-defined operation that a support agent does repeatedly. Tool-calling — giving an LLM a set of narrowly-scoped tools it can invoke — turns the LLM into a first-line agent for these workflows.

Written July 2025 from a pilot with internal support tooling.

The tools that make sense

• Merchant lookup. Given a merchant ID or email, return account status, activation date, KYC state.
• Transaction lookup. Given a transaction ID or reference, return the transaction record and its history.
• Decline diagnosis. Given a declined transaction, return the decline code with plain-English context.
• Draft ticket response. Given the diagnosis, produce a draft response the agent can send.

What the tool contract should require

• Each tool has an input schema, an output schema, and an error taxonomy.
• Tools that read data are scoped to the merchant the user has permission to see.
• Tools that write anything require explicit confirmation.
• Tool failures are structured errors the LLM can reason about.

The safety net

• No tool executes a write without confirmation. The LLM can propose a refund, an account status change, a ticket update — the agent confirms.
• Every tool call is logged. The agent can audit what the LLM did on their behalf.
• Rate limits per tool per user. The LLM cannot invoke the same tool repeatedly without hitting a cap.

Tool-calling for merchant support is one of the AI-in-commerce use cases where the productivity benefit is real and the guardrails are tractable. It's not a replacement for support agents. It's a boost.