Financial services — commercial bankingConversational AI and knowledge graphs

An AI support agent that resolves routine banking inquiries and hands the rest to people

A national commercial bank answered every support inquiry by hand, from document requests to login problems. We built a triage-and-escalation agent system on AWS Bedrock over a knowledge graph of the bank’s own documents — delivered in six weeks.

Three example inquiries — a request for the standard provisions document, a request to raise a high-priority ticket for a login bug, and a request to speak to a person — enter a triage agent, which recognises the intent and routes each to a specialist: general banking for policies, products and procedures; account support for account requests and documents; technical support, which creates, routes and tracks tickets; and escalation, which hands the conversation to a person with its full history. A response generator assembles one answer with action buttons. All agents read one shared knowledge graph of the bank’s normative data, procedures and FAQ library, searched by GraphRAG and kept in sync with the document store. Along the bottom: 70% of routine inquiries automated, 60–70% faster responses, 85% correlation with human-agent satisfaction scores, and 25% lower customer-service cost.
The customer asks the way they would ask a colleague. The triage agent decides who answers — an agent or a person.

Project snapshot

Client
A national commercial bank with a busy customer support operation
Industry
Financial services — commercial banking
Business function
Customer support and service operations
Challenge
Every support inquiry — a request for a standard document, an account question, a login problem — was answered by hand, by searching policies and procedures spread across the bank’s document store. Response times were slow, service cost grew with volume, and the same people handled routine requests and complex banking matters.
Solution
A chat-based support agent, reachable in Teams and on the web in two languages. A triage agent recognises the intent and routes each inquiry to a specialist — general banking, account support, technical support or escalation — all answering from a GraphRAG knowledge graph of normative documents, procedures and FAQs. Tickets are created and tracked automatically; complex matters reach a human agent with the full history attached.
Result
60–70% faster support responses, 70% of routine inquiries resolved automatically, answers that track human-agent satisfaction scores at 85% correlation, 50% higher operational efficiency and 25% lower customer-service cost — delivered in six weeks.

Key outcomes

60–70%
Faster support response times
70%
Of routine inquiries resolved automatically
85%
Correlation with human-agent satisfaction scores
25%
Lower customer-service cost

The client

A commercial bank where every answer was looked up by hand

A national commercial bank with a busy customer support operation. Its policies, procedures and FAQs were well documented. Finding the right one, in the right version, for each inquiry was the slow part.

The bank wanted support that answered faster and cost less, without lowering the bar its customers were used to.

The challenge

Routine requests and banking judgement in one queue

Every inquiry was answered by a person searching the document store. A request for a standard document, a login problem and a question that needed a banker all waited in the same line.

The knowledge behind every answer

3
sources — normative data, procedures, FAQs
2
working languages, both first-class

Cost rose with volume, and the routine requests set the pace for the complex ones.

Constraints

What we had to design around

  • JudgementA bank cannot let a model improvise on an account or a regulation. The agent could finish routine requests, but anything that needed a banker had to reach one — with the conversation so far, not a blank ticket.
  • Source of truthThe answers already existed, in normative documents, procedures and an FAQ library in the bank’s document store. The agent had to answer from those, and from the current version of them.
  • Where people already areStaff and customers already worked in chat. The agent had to live in Teams and a web chat, not in a new portal nobody opens.
  • Two languagesInquiries arrive in two languages. Both had to be first-class, not a translation layer bolted on.
  • GrowthCustomer support was the first use case, not the last. The architecture had to take new agents without rebuilding the ones already running.

Our approach

Triage first, then specialists, on one graph

A single chatbot that tries to answer everything ends up guessing at the hard questions. In banking, a confident wrong answer costs more than a slow right one.

So we split the work. A triage agent decides what each inquiry is. Specialists own one kind of request each, and one of them exists only to hand over to a person. All of them answer from a knowledge graph of the bank’s own documents, because support questions are about connections — which procedure applies to which product, which version replaced which — and a graph answers those directly.

The solution

Five layers, from a question to a resolved inquiry

  1. Chat interface — A Teams bot and a web chat behind one secured API. Answers stream back with action buttons — email this document, raise a ticket — so the next step is one click.
  2. Triage agent — Recognises the intent of each inquiry, routes it to the specialist that owns it, and keeps the conversation state, so “send me that one” knows which document “that one” is. Built on Agno.
  3. Specialist agents — General banking, account support, technical support and escalation. Each runs a Claude model on AWS Bedrock, with shared tools for context understanding, data retrieval, GraphRAG search and reasoning. A response generator assembles the final answer.
  4. Knowledge graph — The bank’s normative data, procedures and FAQ library, broken into entities and relationships and searched by GraphRAG — a hybrid of graph traversal and vector similarity, with sub-second queries.
  5. Actions and ingestion — An MCP server creates, routes and tracks tickets in the existing helpdesk. ETL jobs and real-time functions keep the graph in sync with the document store. A cache, guardrails and a feedback log run underneath everything.
The multi-agent architecture. On the left, a Teams chat window sends the query in and receives the response. In the centre, a group of customer support agents: a triage agent that performs orchestration and a response generator agent, with four specialists — general banking, account support, technical support and escalation. On the right, a tools column with context understanding, data retrieval, GraphRAG and reasoning tools, which read a knowledge base of normative data, procedures data and an FAQ library, and connect to external systems for the document store and ticketing. Along the bottom, background operations run a cache, guardrails and feedback, backed by a cache database and feedback logs.
Triage in the middle, tools on the right. The guardrails and feedback loop underneath apply to every agent.
The retrieval flow. A message from the Teams chat window passes through a secured API into search: the query is turned into a query vector, run through a knowledge graph search combining nearest-neighbour and hybrid retrieval, and the relevant sub-graph is retrieved along with the related documents. The knowledge base above holds normative data, procedures data and the FAQ library. Answer generation uses the sub-graph and documents, then passes to response generation, which streams the reply back through the API to the chat.
One question in, one sub-graph out. The answer is generated from the documents the graph found, then streamed back to the chat.
Five epics over six weeks. Week one: foundation and data pipeline — ETL for banking documents and FAQs, and real-time ingestion into a knowledge data lake synced from the document store. Week two: the GraphRAG knowledge base — graph database, entity extraction, relationship mapping, and hybrid graph and vector search with sub-second queries. Weeks three and four, highlighted as the core: the multi-agent system — Agno orchestration, specialist support agents, shared memory and conversation state, and Claude on AWS Bedrock for each agent. Week five: integration and ticketing — tickets created and routed through an MCP server with real-time status tracking, connected to the existing helpdesk, with a full audit trail. Week six: front end and production — a Teams bot and web chat in two languages, infrastructure as code, CI/CD with automated tests, and monitoring and security.
The graph lands in week two because every agent built after it answers from it.
6 weeksfrom kick-off to a production support agent, in Teams and on the web

Responsible by design

Four rules for an agent that speaks for a bank

  • Escalate

    Routine is finished; banking judgement is handed over.

    A document request or a ticket completes on its own. A matter that needs a banker goes to a person, who opens it with the whole conversation in front of them.

  • Ground

    Answers come from the bank’s documents, not the model’s memory.

    Every specialist searches the same knowledge graph. An answer about a procedure traces back to the procedure, and to its current version.

  • Guard

    Every reply passes guardrails before it is sent.

    Guardrails sit between the agents and the customer, so an answer outside policy is stopped before anyone reads it.

  • Trace

    Every automated action leaves a record.

    Tickets, emails and handovers are written to an audit trail, and feedback on each answer is logged, so quality can be checked, not assumed.

The first rule shapes the rest. The aim is not an agent that replaces the support team. It is a team that spends its day on the inquiries that need a banker, because the agent answered the rest.

Results

What changed for customer support

  • 60–70% faster support responses — the answer comes from the knowledge graph in seconds, instead of from a person searching the document store.
  • 70% of routine inquiries resolved automatically, with complex banking matters escalated to a person, conversation attached.
  • 85% correlation with human-agent satisfaction scores, so customers rate the agent’s answers in step with the team’s.
  • 50% higher operational efficiency through consistent service quality — the same question gets the same, current answer every time.
  • 25% lower customer-service cost, on a framework that takes new agents, so the next banking use case plugs into the same triage and the same graph.

The routine stopped setting the pace. The people who knew the bank best got their time back for the questions only they could answer.

Beyond the numbers

What else changes

The bank’s documentation stops being a library and becomes something you can ask. Which procedure changed, which version is current, what applies to this product — one sentence instead of a search.

And because triage, tools and the graph are shared, the next agent — for another department or another channel — is an addition, not a rebuild.

If your support team answers the same questions every day

The first question is how much of the queue is routine. That is answerable from a week of your inquiries, before anything gets built.