Use case
AI customer-support agent
An assistant that answers customer questions from your help content and account systems, resolves what it can, and hands the rest to a person with context attached. Deflection rate matters less than what happens on the cases it cannot close.
- Source
- Editorial ontology entry — no fetched document behind this page
- Evidence
- none on this page — it links to the pages that hold it
- Category
- Communications
- Typical risk
- high
- Entry
- editorial · reviewed 21 Sep 2026
01What this is
A support agent combines retrieval over help content with actions in back-office systems (order status, refunds, password resets) and a handoff path to a human. It runs in chat, email or voice, and the same knowledge base usually serves all three.
A good deployment restricts the agent to grounded answers with links, defines exactly which actions it may take and under what limits, escalates on uncertainty and on request, and hands over the whole conversation rather than making the customer repeat it. Containment, resolution and escalation quality are tracked separately.
Pitfalls: an agent that cannot say "I do not know"; promises made to customers that create contractual exposure; and a hidden escalation path that traps people in a loop. Consumer-protection and disclosure rules in several jurisdictions require telling the customer they are talking to a machine.
- Typical data
- support tickets, customer data, wiki pages, order data
- Solution classes it admits
- Enterprise SaaS, Private cloud, Self-hosted
02Deployment options
- ASSESSMENT
On a neutral reading of this use case, Private cloud is recommended, Self-hosted is a strong alternative, Model API is a strong alternative and Enterprise SaaS is conditional.
- ASSESSMENT
Read as a generic reading of this page, not a recommendation: no organisation, size, jurisdiction, budget or technical capability has been supplied, so wherever an option depends on one of those, it says "unknown". Ask your own question to get a verdict that accounts for them.
Private cloud
RECOMMENDEDManaged model API or private model deployment in your cloud account
- ASSESSMENT
Two patterns fit inside one account in a region you name: call a managed foundation-model API such as Amazon Bedrock, Microsoft Foundry / Azure OpenAI, or Vertex AI; or deploy an open-weight model on GPU compute you control. Your application, retrieval layer, storage, identity and logs remain in your cloud boundary in both patterns.
- ASSESSMENT
The managed-API pattern can use closed-source frontier models without buying or operating GPUs. It is usually the fastest way to build a custom workflow, but prompts and retrieved context are processed by the managed service, so model availability, retention, abuse monitoring and regional routing must be checked for the exact feature and endpoint.
- ASSESSMENT
The private-model pattern gives more control over weights, serving and network paths, and can use managed endpoints or your own containers. It also makes your team responsible for capacity, patches, model upgrades, evaluation and failover.
- ASSESSMENT
Which account you already have is a real input, not a detail: no existing cloud account was named. An organisation that already has a landing zone, an identity provider and a signed agreement with one provider is buying a feature; one that does not is buying a cloud programme, and those are different projects.
- ASSESSMENT
The cloud provider becomes a data processor in either pattern: you need a DPA, a documented region, and an answer on cross-region routing and where support staff can access the environment from.
- RECOMMENDATION
Start with the managed-API pattern when the workflow is custom but model operations are not the source of competitive advantage; move to private model serving only if evaluation, volume, portability or the data boundary justifies the extra operations. Your stated technical capability is "unknown".
- RECOMMENDATION
Recommended for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.
Model API
STRONG ALTERNATIVEA model vendor’s API behind an application you build and own
- ASSESSMENT
You write and host the application — the interface, the retrieval layer, the database, the access control, the audit log — and call somebody else’s endpoint for the model itself. Two kinds of endpoint sit in this class: a closed model from the vendor that made it (OpenAI, Anthropic, Google Gemini, xAI, DeepSeek, Moonshot, Mistral, Cohere), and an open-weight model served by a managed inference provider (Together, Fireworks, Groq and others).
- ASSESSMENT
Those two are not interchangeable. A closed model can only be obtained from its vendor or from a cloud that licenses it, so the model and the supplier are one decision. An open-weight model can be moved: the same weights run on a managed endpoint today and on your own GPU later, which makes the provider a swappable component rather than a dependency — and makes the licence, not the contract, the document that governs what you may do with it.
- ASSESSMENT
It is the shortest path to a frontier model: no GPUs to buy, no capacity to plan, no serving stack to patch, and you can change model with a configuration line. What it costs instead is a per-token bill that scales with use and a dependency on one supplier’s availability, pricing and deprecation schedule.
- ASSESSMENT
What the supplier sees is the whole prompt: the user's question, the system instructions, and every passage your retrieval layer attached to it — which is usually the most sensitive part, because retrieval is what puts internal documents into the request. For a brief that involves confidential documents and personal data, that is the attribute to check first. What stays yours is everything else: the application, the retrieval index, the identity system, the logs, and the record of who asked what.
- ASSESSMENT
Nothing about a supplier's handling of your data is assumed here. Before real content goes near an endpoint, verify against that supplier's own documents: the data processing agreement, and that it covers the API rather than only the consumer product; whether zero-data-retention or an equivalent no-logging mode is available on your account, and on which endpoints; the default retention period for prompts and outputs, and what triggers human review; the region the request is served from, and whether that is a commitment or a routing preference; the current subprocessor list and how you are notified when it changes; the supported-countries page, which decides whether you may use the service at all.
- RECOMMENDATION
Take this route when the workflow is yours but the model is not the differentiator, and your team can build and run an application. Your stated technical capability is "unknown", which is the attribute this option most depends on. Where the same model is available inside your own cloud account, compare it against private cloud before committing — the application is identical and only the tenancy of the model changes.
- RECOMMENDATION
A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.
Self-hosted
STRONG ALTERNATIVEOpen-weight models on infrastructure you operate
- ASSESSMENT
Documents, queries and embeddings stay on machines you own, using an open-weight model whose licence you review. For a brief that involves confidential documents and personal data, that removes a model-API vendor from the data path rather than governing that transfer by contract.
- ASSESSMENT
It costs you the operational work instead: a GPU server, Docker, Linux, backups and a patching routine. Your stated technical capability is "unknown", which is the attribute this option most depends on.
- ASSESSMENT
No processor agreement, subprocessor list or cross-border transfer assessment is needed for the model itself, because no third party processes the content.
- RECOMMENDATION
Recommended where local processing is preferred (you did not say so) and the content is sensitive (confidential documents and personal data).
- RECOMMENDATION
A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.
Enterprise SaaS
CONSIDER IFFinished closed-source cloud product with enterprise controls
- ASSESSMENT
This is a complete vendor application, not a model API: examples include an enterprise assistant, coding copilot or document product with the workflow, interface, connectors and administration already built. It can use closed-source cloud models while requiring no model hosting or application engineering from your team.
- RECOMMENDATION
Choose it when the product already performs the actual workflow and its controls meet your requirements. Do not choose it only because its underlying model is strong: a finished SaaS product is less flexible than building against a managed API when your process, integrations or review steps are organisation-specific.
- ASSESSMENT
Vendor commitments are treated as unverified until we have fetched the page that makes them. Until then this option carries questions to ask, not assurances: a signed data processing agreement covering the data you will actually put in; a documented data residency commitment naming the region, in the contract rather than a blog post; a written no-training commitment for your content, including uploads and connected sources; stated retention periods and a deletion path you can exercise; an administrative audit log you can export, and SSO with group-based access control.
- RECOMMENDATION
No jurisdiction was named, so this is the check rather than the conclusion: compare the vendor's stated processing locations and subprocessor list against the cross-border transfer rules wherever you operate before uploading anything.
- RECOMMENDATION
Worth considering for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents and personal data, no existing cloud account was named, and you did not ask for local processing.
03Deployment stacks
- Enterprise SaaSCustomer-support AI agent on a SaaS platformA support AI agent — Intercom Fin, Zendesk AI or an equivalent — grounded on your help centre, integrated with your helpdesk and backend, allowed to take a defined set of actions, and handing off to your human team with full context. The vendor runs the model and the platform; you own the content, the integration and the guardrails.
- Private cloudAgent workflow on a managed cloud runtimeA managed agent runtime that handles orchestration, memory, tool invocation and observability; a model from the same cloud; your APIs exposed as tools; private networking; and human approval gates on consequential actions. Same shape as the framework-hosted agent, one tenancy instead of two.
- Self-hostedCustomer-support agent with knowledge base and handoffDify self-hosted as the agent builder and knowledge base, a local model on vLLM behind it, pgvector or Qdrant for retrieval, and n8n for the handoff into your helpdesk. Scoped deliberately: a defined topic list, a refusal path, and a human queue.
- Self-hostedVoice agent (telephony + STT + LLM + TTS)LiveKit Agents or Pipecat as the real-time orchestrator, a SIP trunk for telephony, faster-whisper for speech to text, a local model for the conversation, and a self-hosted TTS voice. Every hop counts against a latency budget of roughly a second.
04Tools by hosting option
Self-hosted9
- HybridDifyPlatform for building LLM applications: visual workflow editor, retrieval pipelines, agent tools, prompt management and an API layer. Available self-hosted or as a managed cloud service.
- HybridFlowiseVisual builder for LLM chains and agents, with retrieval nodes, tool calling and an API or embeddable chat widget for the finished flow.
- FrameworkLangChainLibrary for composing model calls, retrieval and tools into applications, with adapters for most providers and vector stores. A building block, not a deployable product.
- HybridLangflowVisual environment for composing LLM pipelines and agents from components, with export to a Python application or an API endpoint.
- HybridLangfuseTracing, evaluation and prompt management for LLM applications, self-hostable so prompts and responses can stay inside the network being audited.
- FrameworkLangGraphGraph-structured agent framework with explicit state, checkpoints and interrupts — the mechanism behind a human approval step rather than a prompt asking for one.
- HybridLiveKit AgentsFramework for real-time voice and video agents on LiveKit’s WebRTC infrastructure, with turn detection, interruption handling and pluggable speech and model providers.
- HybridOnyxOpen-source enterprise search and chat over company systems, with connectors to common SaaS tools, permission-aware indexing and a self-hosted deployment path.
- FrameworkPipecatOpen-source framework for real-time voice and multimodal agents, composing speech-to-text, model and speech synthesis services into a streaming pipeline with barge-in support.
Private cloud11
- PlatformAmazon BedrockAWS service offering models from several providers behind one API in a chosen region, with VPC endpoints, IAM control, guardrails and knowledge bases for retrieval.
- PlatformAmazon Bedrock AgentCoreAWS runtime for agents: session isolation, tool invocation, memory and an identity boundary, with the model served from Bedrock in the same account.
- HybridDifyPlatform for building LLM applications: visual workflow editor, retrieval pipelines, agent tools, prompt management and an API layer. Available self-hosted or as a managed cloud service.
- FrameworkLangChainLibrary for composing model calls, retrieval and tools into applications, with adapters for most providers and vector stores. A building block, not a deployable product.
- HybridLangfuseTracing, evaluation and prompt management for LLM applications, self-hostable so prompts and responses can stay inside the network being audited.
- FrameworkLangGraphGraph-structured agent framework with explicit state, checkpoints and interrupts — the mechanism behind a human approval step rather than a prompt asking for one.
- HybridLiveKit AgentsFramework for real-time voice and video agents on LiveKit’s WebRTC infrastructure, with turn detection, interruption handling and pluggable speech and model providers.
- PlatformMicrosoft Foundry Agent ServiceManaged agent runtime inside Microsoft Foundry, with tool connections, threads and Entra ID identity. The Azure counterpart to Bedrock AgentCore.
- HybridOnyxOpen-source enterprise search and chat over company systems, with connectors to common SaaS tools, permission-aware indexing and a self-hosted deployment path.
- FrameworkPipecatOpen-source framework for real-time voice and multimodal agents, composing speech-to-text, model and speech synthesis services into a streaming pipeline with barge-in support.
- PlatformVertex AI Agent EngineGoogle Cloud’s managed runtime for deployed agents, including sessions and a memory bank, with the agent framework left to the developer.
Vendor cloud15
- PlatformAmazon BedrockAWS service offering models from several providers behind one API in a chosen region, with VPC endpoints, IAM control, guardrails and knowledge bases for retrieval.
- PlatformAmazon Bedrock AgentCoreAWS runtime for agents: session isolation, tool invocation, memory and an identity boundary, with the model served from Bedrock in the same account.
- HybridDifyPlatform for building LLM applications: visual workflow editor, retrieval pipelines, agent tools, prompt management and an API layer. Available self-hosted or as a managed cloud service.
- HybridFlowiseVisual builder for LLM chains and agents, with retrieval nodes, tool calling and an API or embeddable chat widget for the finished flow.
- SaaSIntercom FinAI support agent that answers customer questions from a company’s help content, takes defined actions and hands conversations to human agents inside Intercom’s inbox.
- HybridLangflowVisual environment for composing LLM pipelines and agents from components, with export to a Python application or an API endpoint.
- HybridLangfuseTracing, evaluation and prompt management for LLM applications, self-hostable so prompts and responses can stay inside the network being audited.
- FrameworkLangGraphGraph-structured agent framework with explicit state, checkpoints and interrupts — the mechanism behind a human approval step rather than a prompt asking for one.
- HybridLiveKit AgentsFramework for real-time voice and video agents on LiveKit’s WebRTC infrastructure, with turn detection, interruption handling and pluggable speech and model providers.
- PlatformMicrosoft Copilot StudioLow-code builder for agents inside a Microsoft 365 tenant, with connectors to Microsoft and third-party systems. The usual next step for an organisation already licensed for Copilot.
- PlatformMicrosoft Foundry Agent ServiceManaged agent runtime inside Microsoft Foundry, with tool connections, threads and Entra ID identity. The Azure counterpart to Bedrock AgentCore.
- HybridOnyxOpen-source enterprise search and chat over company systems, with connectors to common SaaS tools, permission-aware indexing and a self-hosted deployment path.
- SaaSVapiHosted platform for building telephone voice agents, bundling telephony, speech recognition, model orchestration and synthesis behind one API with call analytics.
- PlatformVertex AI Agent EngineGoogle Cloud’s managed runtime for deployed agents, including sessions and a memory bank, with the agent framework left to the developer.
- SaaSZendesk AI agentsAI agents and agent-assist features inside the Zendesk service platform, answering from help centre content and routing or escalating tickets within existing workflows.
05Compliance hot spots
This use case usually raises personal data, transparency, human oversight, automated decision-making, retention, logging, sector rules, bias and fairness, confidentiality, consent, cross-border transfers, data residency, data processing agreement, model training, prompt leakage, security, sensitive data, vendor jurisdiction.
- Personal data
- United Arab EmiratesJapanTaiwanIndiaSingapore
- Human oversight
- Singapore
- Automated decision-making
- European UnionSwitzerlandUnited KingdomUnited Arab EmiratesCanadaUnited StatesSouth KoreaAustraliaBrazilSingapore
- Retention
- Hong Kong
- Logging
- European Union
- Sector rules
- No published jurisdiction page names this topic yet
- Bias and fairness
- CanadaUnited States
- Consent
- China (mainland)
- Cross-border transfers
- European UnionSwitzerlandUnited KingdomUnited Arab EmiratesCanadaUnited StatesChina (mainland)Hong KongTaiwanAustraliaBrazilIndiaSingapore
- Data residency
- United Arab Emirates
- Data processing agreement
- Japan
- Model training
- European UnionSouth KoreaAustralia
- Security
- China (mainland)BrazilIndia
- Sensitive data
- United StatesBrazil
- Vendor jurisdiction
- China (mainland)
06Example questions
Each of these opens the question box with the text already in it. The answer is researched for your organisation, not for this page.
07Related use cases
- CommunicationsVoice agentA system that answers or places phone calls and holds a spoken conversation — booking, triage, reminders, first-line support. The hardest stack in this ontology: telephony, speech recognition, a model, speech synthesis and interruption handling, all under a latency budget.
- CommunicationsTranslationTranslating documents, messages and interfaces between languages while keeping terminology and formatting intact. In East Asian and European operations this is often the highest-volume AI workload in the company.
- CommunicationsMeeting transcriptionTurning internal meetings into a transcript, a summary and a list of actions. Usually a bot that joins the call, or an app that records the room. Value comes from the follow-up, not the transcript.
- CommunicationsEmail draftingDrafting replies in the inbox from the thread, the CRM record and the company style. Small per message, large in aggregate — and the place where a wrong statement leaves the building fastest.
- CommunicationsCRM call summariesWriting the call back into the CRM: a summary, the next step, the fields a rep would otherwise type. The point is not the transcript but that the record exists at all and is consistent across the team.
- CommunicationsCall transcriptionTranscribing telephone calls — support lines, sales calls, advice sessions — usually from a contact-centre or telephony platform rather than a meeting app. Narrow-band audio and regulated recording rules make it a distinct problem.
Improve this page
Sign in to contribute
From the field
0 deployments · 0 questions
Nobody has reported deploying this here yet, and no question has been opened against this page. Both appear once a reviewer accepts them.