Here's a build I've been playing with building a data-and-AI platform for a fictional bank to help myself learn more about agentic workflows. One lesson learned is, the right AI tool depends entirely on who's asking, and every tool only works if it's grounded. Let me walk it by persona.
The customer: DaaS for governed truths
When a customer asks "what's my balance" or "what did I spend last month," there is exactly one correct answer, and the model should never invent it. So the customer-facing agent doesn't reason about data - it calls Data-as-a-Service (DaaS) endpoints that return precisely what was asked. No hallucination, no helpful "context enrichment," no creativity. A golden path.
That only works because the data foundation underneath is a set of well-defined data products, each owned, versioned, certified, with a data contract, a PII classification, and a data-quality score:
- Deposit Transactions - the posted-activity ledger
- Customer Master - the authoritative customer record
- Overdraft History - aggregated risk signals
- Loan Master - applications, risk scores, approval status
- Knowledge Base - policies and procedures (more below)
The DaaS layer matters twice over. Agentically, the agent - written in Google ADK - binds to these endpoints as tools. Systematically, the same governed endpoints are referenced by other apps and integrations through an API Gateway. One contract, two consumers, zero divergence. When data products are sloppy, DaaS is a thin veneer over chaos. When they're sharp, DaaS becomes the trustworthy interface to your business.
The analyst: democratized analytics, still grounded
Analysts don't want golden paths; they want to ask anything. "Average balance by segment." "Which customers carry the most overdrafts." "Monthly fee revenue." For them I wired up conversational analytics - Google's Gemini Data Analytics - that turns natural language into SQL over the data products.
Here's the catch nobody warns you about: turn a model loose on raw tables and it guesses the joins. In my schema a transaction carries only an account_id, never a customer_id. Ask "deposits by customer" and a naive model either fails or invents a join. Wrong numbers are worse than no numbers.
The fix is a BigQuery knowledge graph that acts as a pseudo-semantic layer. It encodes the entity relationships - transaction to account to customer - as data, and I feed those join keys to the model so it joins correctly instead of guessing. Alongside it sits customer_360, a pre-joined, column-level-secured per-customer rollup. The design is deliberately hybrid: the raw entities and the graph, so the analyst can ask both per-customer questions and granular ones. Democratizing data is not "give everyone a SQL prompt." It's giving them a map.
The shared layer: a knowledge base both can ask
Both personas can ask policy questions - fees, branch hours, terms and conditions, procedures. Those answers live in documents, not tables, so they're handled with retrieval-augmented generation. The corpus is embedded with a BigQuery embedding model and retrieved by VECTOR_SEARCH over a vector table, with answers cited back to the source. The analyst's assistant even routes itself: a small classifier decides per question whether to hit analytics or the knowledge base, so it's one pane of glass, not two.
The takeaway
Grounding is what makes agentic AI trustworthy in a regulated domain. DaaS gives deterministic, intended-only answers for golden paths and for systematic or agentic integration. The knowledge graph lets analysts explore freely without letting the model hallucinate a join. RAG keeps policy answers tethered to real documents. Different personas, different tools, one rule: never let the model make it up.
0 Comments
Leave a Comment