Regulated AI Customer Support System

A financial technology company handling sensitive customer information engaged Mercury to design an AI-assisted support system that would deflect at least 50% of support cases from requiring direct human involvement.

The engagement delivered a response architecture where approved knowledge travels with visible sources, customer context stays bounded, human review remains required, and unsupported questions follow defined escalation paths to people rather than into fluent guesswork.

The organization needed to address two competing pressures in its support queue. Customers feel delay immediately. The cost of a wrong answer arrives later and lands harder when the subject involves sensitive information. The team worked under both clocks at once: answer quickly, and be right about matters where a mistake outlasts the ticket.

Mercury's objective was to introduce AI-assisted drafting without weakening the control a support organization must maintain over consequential responses. That meant designing the assistance around the workflow itself — connecting approved knowledge to the drafting surface, bounding what customer context could inform a draft, keeping all generated content in draft status for human review, and defining what should happen when the material behind an answer was thin.

The assignment focused on making the basis of every draft inspectable and giving unsupported questions a destination that did not depend on each agent improvising a handoff.

Generation models produce fluent language even when the underlying knowledge cannot support the answer. The polish conceals the gap. A reviewer must detect an unsupported claim inside confident prose, which is harder than noticing a missing answer.

Speed of drafting was never the scarce resource. Confidence in what the draft rested on was. The organization had an approved knowledge base, but that material was not connected to the drafting surface in a way that made each draft's basis visible during review. A reviewer could approve language without seeing the source beneath it.

Customer context created a second risk. Ticket history and prior records change what a question means. The same records carry sensitive information that must stay within deliberate limits. Without explicit rules for what could inform a draft and what stayed outside the drafting surface, useful history could move into a response path without passing through a human review point.

Escalation was informal. Low-confidence answers, sensitive categories, and judgment calls depended on individual agents recognizing the boundary and deciding what to do next. That created variance in handling and made it difficult to learn from the cases that needed human ownership.

Ground every draft in knowledge a reviewer can see

The binding constraint was reviewability. A support person can only approve what they can verify. Mercury integrated the approved knowledge base into the drafting step so each generated draft carried its sources into review. A reviewer could open the source behind a sentence, compare it with the customer's question, and decide whether the draft overstated its material.

The tradeoff was coverage. Questions outside the approved material received no routine draft. That narrowing was deliberate. It converted a hidden failure mode — the confident draft with no basis — into a visible condition the workflow could act on. A missing draft became a signal rather than a silent risk.

Bound the context before it reaches the drafting surface

Mercury designed context assembly as a bounded input. The engagement defined which material could inform a draft, which material stayed outside the drafting surface, and where a person inspected what had been assembled. Some genuinely useful ticket history stayed out of drafts to keep sensitive information inside a reviewable path.

Every designed route from assembled context toward a customer-facing response included a human review point. The structure made context assembly inspectable in its own right. When an output needed investigation, the team could examine the evidence set that shaped it alongside the model behavior.

Treat escalation as the system working

Mercury defined escalation routes as part of the response path rather than leaving handoffs to individual judgment. Unsupported questions, sensitive categories, low-confidence answers, and judgment-dependent cases followed defined routes to designated human ownership. Assistance stayed draft-only. A person remained responsible for anything a customer received.

The tradeoff was pace. A designed handoff moves slower than a generated reply. In exchange, uncertainty acquired a destination. A stalled draft became a signal about knowledge-base coverage, context-boundary fit, or categories that should remain with specialists. Daily support work and knowledge maintenance connected through the same workflow.

The engagement delivered a response architecture the organization can use to govern AI-assisted drafting. Drafts exist only where approved knowledge supports them, carry that knowledge visibly into review, and reach a customer only through a responsible person. Where support runs out, the question follows a defined route to human judgment.

Source absence acquired a job in the workflow. A routed question can show where the knowledge base needs attention, where a context boundary needs refinement, or which categories belong with specialists. The design connects support operations and knowledge maintenance rather than treating them as separate concerns.

For Mercury, this engagement demonstrates the kind of work required when AI assistance must operate under consequential constraints. The result is engineering and delivery evidence: knowledge-base integration, support workflow design, bounded context, escalation paths, and AI-assisted response infrastructure delivered under sensitive-information constraints. This case does not make claims about live deployment, production operation, support-performance figures, autonomous customer responses, or business outcomes.

The organization came to Mercury with a specific problem: introduce AI-assisted drafting without loosening control over what reaches customers who trust the organization with sensitive information. Mercury answered that problem by designing the assistance around the workflow — making every draft's basis visible, bounding customer context, and defining escalation before any draft reached review.

The engagement established a durable operating principle: treating an unsupported question as a routing event gives uncertainty a destination. A credible support system makes three things visible before a response reaches the customer: the source behind the draft, the person who owns the review, and the path a hard case follows out of routine handling. Teams can apply that test to their own queue before any model choice.