Agentic Text-to-SQL Assistant for a US Banking Group

At a glance

Why did every bank report take a day?

Every report took a day because each question had to become SQL, & only the data teams could write it. The US banking group wanted an agentic text-to-SQL assistant so leaders could ask the warehouse directly.

The bank runs its decisions on a large relational data warehouse. Inside it sit the customer profiles & account activity that bankers watch, along with loan records & insurance policies. Leaders asked questions like which customers hold active policies every day.

SQL is the query language a database answers to, & only the data teams wrote it. Leaders wanted a conversational AI layer over the warehouse that anyone could use.

• A question left a business team as a ticket & came back days later as a spreadsheet.
• Urgent requests queued behind routine ones, because one team wrote all the SQL.
• Each follow-up question restarted the cycle, since a static export can’t answer the next one.
• The data teams spent their days turning English into queries instead of engineering.

People have wanted to talk to databases for a few decades now. A 2019 survey compared 24 natural language interfaces for databases & found that even the strongest leaned on hand-built rules^[1].

What do banks try before a text-to-SQL assistant?

Banks usually try four routes before they build a natural language query assistant, & each route makes sense for some teams.

On a 2023 benchmark of real enterprise databases, the strongest model reached 40% execution accuracy while humans scored 93%^[2]. That gap is the reason the last row of the table exists.

How did we design the agentic text-to-SQL assistant?

We designed the query assistant as an agent that acts on the database & checks its own work. The agent reads the intent behind a question, then pulls the matching slice of schema from a vector database.

A language model hosted on the bank’s own servers then writes the SQL. The model never sees the whole warehouse, & the warehouse never sees the internet.

Mitesh Patel, our AI architect, set the agent architecture & checked every query-safety decision against the bank’s own data access rules.

What technology stack did we use?

Every layer of the stack had to pass one test first, which was whether customer data could ever leave through it. The same layers show up across most of our generative AI development work, with a different database underneath.

How does one question become an answer?

Each question passes through five steps, in the order the assistant actually handles them.

1. Ask in plain English. A business user types a question in plain English, & the agent works out what it means.
2. Find the schema. The agent turns the question into a search & pulls the matching tables & columns from the vector index.
3. Write the SQL. A local language model writes SQL against that slice of schema, following a prompt template made for this step.
4. Run it read-only. The agent runs the query with read-only credentials, & any database error goes straight back to the model to fix.
5. Summarise & suggest. Results come back as a table with a plain-language summary, plus follow-up questions ready to ask next.

Customer data stays inside the bank’s network through all five steps. The loop in step four is what separates a demo from something a bank will sign off.

What changed once the assistant went live?

Once the assistant went live, answers that took hours, sometimes a full working day, started coming back in seconds.

Seconds is the client’s own word, & Brainy Neurals hasn’t measured a latency figure behind it. We won’t print a number we haven’t measured, & Ronak Patel wrote this case study from the build notes & the client’s own account.

Day to day, the change shows up in ordinary meetings. A question raised at ten gets its answer at ten, while the decision is still open. Since the models run on the bank’s own hardware, there’s no per-question API fee, so exploring costs nothing extra.

The assistant runs in production today against the warehouse the data teams once served by ticket. Senior managers & business teams use it directly, suggested follow-ups included.

The data teams still own the schema descriptions & update them as tables change, which is now most of the upkeep. New tables join the vector index in the same week they appear, & no customer data ever leaves the building. Keeping that boundary is what got this AI in banking & finance project approved.

What would we do differently next time?

Four lessons came out of this build, sorted here into what we’d repeat & what we’d avoid.

What we would repeat

• Describe the schema first, because the plain-language data dictionary moved accuracy more than swapping models did.
• Collect the real questions early, since executives asked shorter, vaguer questions than we imagined.
• Put the effort into the loop, where a model that reads its own error message beats a bigger model that can’t.
• Show the query, because people trusted the assistant once they could open the SQL & rows behind every summary.

What we would avoid

• Building the data dictionary second, which is what we did, & next time it comes first.
• Designing for imagined questions, because the real ones arrived full of shorthand & the prompts had to change.
• Swapping models to chase accuracy, since most of our gains came from the loop & almost none from model swaps.
• Leading with accuracy claims, because one expandable panel did more for adoption than any number.

Where else does this pattern fit?

Natural language database queries turn plain questions into SQL & return short answers wherever decision makers wait on technical teams.

The vocabulary changes from one industry to the next, while the loop underneath stays the same. Porting takes a described schema & a fresh vector index, plus question tuning with the people who will actually ask.

Services behind this case study

An AI proof of concept is the quickest way to test natural language database queries on your own schema. AI consulting helps pick the model & the network boundary first. An AI readiness assessment checks your data layer, & the industries hub shows where the pattern runs.

Similar case studies