A support bot that makes up account balances is not just useless in a digital bank. It is dangerous. Financial conversations demand exact numbers, verified payees, and an audit trail for every claim. Large language models excel at conversation, but they hallucinate. When a user asks, “How much remain for my account?” the model must reach for a database, not imagination. That is exactly what function calling enforces, and it is the core of this build.
Google’s Gemma 4 gives developers a capable 31-billion parameter model that can follow complex instructions and carry on natural dialogue, including in regional dialects. Paired with Google AI Studio, it becomes a rapid prototyping environment where you can define tools, test edge cases, and export working JavaScript before you touch a server. The goal here is a fintech support agent that checks account balances, tracks transaction status, and pays bills. Crucially, it responds in Nigerian Pidgin when the user does, matching tone without ever improvising financial facts.
Why Function Calling Matters for Financial Bots
Without function calling, a language model treats every question as a creative writing exercise. Ask it for a balance and it might invent a plausible-sounding figure drawn from patterns in its training data. That failure mode is unacceptable when real money is involved.
Function calling reverses the flow. The model’s job is not to know the balance. Its job is to recognize intent, choose the correct tool, and extract parameters. When a user writes “Check my balance,” Gemma 4 emits a structured JSON request—something like a call to get_balance with an account_id. Your backend executes that call against the core banking system, gets the real figure, and feeds it back into the conversation. Only then does the model generate the human-facing sentence. Every answer comes from a tool call to a backend. Because the model is gated by external logic, hallucinations stop at the API boundary.
This pattern also creates clear audit trails. Each tool request and its corresponding result are logged in the message history. Regulators and risk teams can inspect exactly when a balance was checked and what number the user received.
Designing the Agent in Google AI Studio
The workflow starts inside Google AI Studio. Select gemma-4-31b-it, the instruct-tuned variant optimized for dialogue and instruction following.
Next, write system instructions that set hard boundaries. For a digital bank, the tone should be professional, direct, and calm. But the instructions must go further. Tell the model explicitly that it never estimates account data, never assumes a transaction status, and never completes a bill payment without confirming the tool result. If the user writes in Nigerian Pidgin, the model should reply in Nigerian Pidgin. If the user switches to English, the model follows. The system prompt is where you encode trust and safety policy in plain language.
Then define the tool schemas. Think of these as contracts between the model and your backend. You need at least three:
get_balance
Parameters:account_id(string, required)
Returns: current balance and currency.get_transaction_status
Parameters:transaction_reference(string, required)
Returns: status such as pending, completed, or failed, plus a timestamp.pay_bill
Parameters:biller_code(string, required),amount(number, required),account_pin(string, optional depending on your flow)
Returns: confirmation reference or error message.
Each schema uses a standard JSON format describing the function name, description, and parameter properties. The description fields matter immensely. Write them so the model understands when to invoke each tool. Ambiguous descriptions lead to wrong tool selection, so be specific: “Use get_balance when the user wants to know their current account balance. Do not use it for transaction history.”
Prototyping in the Browser
Before you write a single Express route, test the entire conversation flow inside AI Studio’s chat panel. This saves days of backend rework. Type a query in Nigerian Pidgin: “Wetin remain inside my account?” Watch whether Gemma 4 correctly emits a get_balance call or whether it tries to answer from training data. If it gets the parameters wrong—perhaps using account_number instead of account_id—you fix the schema description right there.
Testa anche le modalità di errore. Richiedi lo stato di una transazione senza fornire un numero di riferimento. Un modello ben istruito dovrebbe chiedere all'utente il parametro mancante o chiamare lo strumento con ciò che ha, lasciando che il backend restituisca un errore di validazione. Vuoi osservare questi comportamenti nel sandbox, non in produzione.
Una volta che i prompt e gli schemi si comportano correttamente, esporta il codice JavaScript. AI Studio genera uno snippet pulito che struttura la richiesta API con il tuo system prompt, il messaggio dell'utente e le definizioni degli strumenti. Questo diventerà la base della tua logica backend.
Collegare il backend Express
Prendi il codice esportato e inseriscilo in un'applicazione Express. L'architettura è semplice, ma il ciclo di esecuzione è l'elemento critico.
Configura un endpoint POST — magari /chat — che accetti il messaggio dell'utente e la cronologia della sessione. Inoltrali all'endpoint di Gemma 4, che puoi interrogare tramite un'API compatibile con OpenAI o l'endpoint di inferenza di Google, a seconda della tua scelta di hosting.
La risposta del modello rientra in una di due categorie. O è un messaggio di testo finale, o contiene una tool_call che richiede dati. Quando ricevi una chiamata allo strumento, esegui la funzione corrispondente sul tuo backend. Interroga il database per il saldo. Interroga il processore di pagamento per lo stato della bolletta. Aggiungi il risultato dello strumento alla cronologia della conversazione come un nuovo messaggio con il ruolo tool e invia l'intero array aggiornato a Gemma 4.
Ripeti questo ciclo finché il modello non restituisce una risposta testuale finale. Quella risposta sarà basata sui dati reali che hai fornito. Express rende facile il coordinamento perché ogni passaggio nel ciclo è solo un'altra richiesta HTTP e puoi gestire l'esecuzione dello strumento in modo pulito con async/await.
Durante le prime fasi di sviluppo, supporta queste chiamate agli strumenti con dati mock. Un semplice oggetto JavaScript che mappa degli ID account di esempio ai saldi è sufficiente per dimostrare che il ciclo funziona. L'obiettivo è convalidare il pattern di interazione prima di integrarsi con API bancarie di terze parti potenzialmente instabili.
Dal prototipo alla produzione
Un prototipo funzionante non è un'infrastruttura bancaria di produzione, ma il percorso per passare dall'uno all'altro è chiaro.
Sostituisci i dati mock con vere API core banking. Collega il tuo strumento get_balance al sistema del registro contabile tramite REST o gRPC. Collega pay_bill al tuo reale switch di pagamento. Quando lo fai, non devi cambiare il modello o la logica della conversazione; devi solo sostituire l'implementazione degli handler degli strumenti.
Aggiungi Redis per la gestione delle sessioni. Lo stato conversazionale nel settore bancario è sensibile e regolamentato. È necessario memorizzare le cronologie dei messaggi in modo sicuro, farle scadere dopo un timeout prestabilito e garantire che la sessione di un utente non possa trapelare tra le richieste. Redis gestisce tutto questo con le policy TTL e ricerche rapide delle chiavi.
Quando il traffico aumenta, sposta l'inferenza su vLLM. AI Studio è eccellente per la prototipazione, ma l'inferenza self-hosted con vLLM su cluster GPU ti offre il controllo su latenza, batching e costi su scala. Gemma 4 funziona in modo efficiente sotto vLLM e il comportamento di tool-calling rimane identico.
La vera lezione
Costruire un agente fintech affidabile riguarda meno la dimensione del modello e più i vincoli architettonici. Gemma 4 fornisce una capacità di ragionamento sufficiente per analizzare il Nigerian Pidgin con code-switching e instradare intent complessi, ma la sicurezza deriva dal ciclo degli strumenti. Ogni saldo viene recuperato in tempo reale. Ogni pagamento di bollette è confermato da un sistema esterno. Nulla viene inventato.
Inizia nel browser con AI Studio, rinforza la logica in un ciclo Express e sostituisci con un'infrastruttura bancaria reale una volta che i flussi di conversazione sono a prova di bomba. È così che si rilascia un bot a cui le persone possono effettivamente affidare i propri soldi.
Fonte: Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent
Community di apprendimento opzionale: GyaanSetu AI on Telegram