Claude/ChatGPT Prompt to Build a Customer Support Agent With Tools

What this prompt does

This prompt has the model act as a senior conversational-AI engineer and specify a customer support agent tightly enough to build today. You provide the [product], the [tools] the agent can call, the [model_stack], and the [escalation_channel], and it returns concrete artifacts: a system prompt, tool schemas with rate limits, a memory design, escalation logic, a ticket payload, and guardrails — not vague advice.

The structure works because it separates the easy part (chat) from the parts teams underestimate. [tools] defines the agent's real capabilities and the JSON schemas it needs, [escalation_channel] drives the handoff path for frustrated or stuck users, and [model_stack] grounds the architecture in a concrete runtime. Asking for an ASCII diagram plus the full prompt and every tool schema forces a buildable spec instead of a wishlist. The memory design and guardrail layer cover the operational realities that decide whether a support agent stays trustworthy under real traffic.

When to use it

• You're building a support chatbot wired to a real product backend, not a demo.
• You need tool definitions with JSON schemas and rate limits on sensitive actions.
• You want escalation logic that hands off to humans before the bot loops on hard tickets.
• You need a memory design covering what to persist, summarise, and forget.
• You want structured ticket payloads created in your CRM automatically.
• You need guardrails for PII redaction, prompt injection, and tool-failure fallbacks.
• You want a spec concrete enough to start building today rather than a strategy doc.

Example output

Expect an ASCII architecture diagram showing the agent, its [tools], memory, and the [escalation_channel]; then the full system prompt defining scope, tone, and refusal rules; then every tool schema with its JSON contract and rate limits. You'll also get the conversation-memory design covering what to persist, summarise, and forget, the escalation logic triggered by frustration signals, the structured ticket payload for the CRM, and the guardrail layer for PII, injection, and tool failures. It's a spec you can hand to a build, not a list of intentions.

Pro tips

• List [tools] precisely (e.g. search_kb, lookup_order, create_ticket, escalate_to_human) — they define the agent's real power and shape every JSON schema.
• Get the escalation logic right early, or the bot loops on hard tickets and burns trust before you notice.
• Set [escalation_channel] to your actual destination (e.g. a Zendesk queue) so the handoff payload matches reality.
• Match [model_stack] to what you'll deploy; it changes how tool calling and memory are wired.
• Treat rate limits on sensitive [tools] as non-negotiable — an unthrottled create_ticket or order lookup is an abuse vector.
• Ask the model to spell out the tool-failure fallback so the agent degrades gracefully instead of returning errors to customers.