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.
Prueba también los modos de fallo. Solicita el estado de una transacción sin proporcionar un número de referencia. Un modelo bien instruido debería pedir al usuario el parámetro faltante o llamar a la herramienta con lo que tiene y dejar que el backend devuelva un error de validación. Quieres ver estos comportamientos en el sandbox, no en producción.
Una vez que los prompts y los esquemas se comporten correctamente, exporta el código JavaScript. AI Studio genera un fragmento limpio que estructura la solicitud de la API con tu system prompt, el mensaje del usuario y las definiciones de las herramientas. Esto se convierte en la base de tu lógica de backend.
Conectando el backend de Express
Toma el código exportado y colócalo en una aplicación Express. La arquitectura es sencilla, pero el bucle de ejecución es la pieza crítica.
Configura un endpoint POST —quizás /chat— que acepte el mensaje del usuario y cualquier historial de sesión. Reenvía esto al endpoint de Gemma 4, al cual puedes acceder a través de una API compatible con OpenAI o mediante el propio endpoint de inferencia de Google, dependiendo de tu elección de hosting.
La respuesta del modelo entra en una de dos categorías. O bien es un mensaje de texto final, o contiene un tool_call solicitando datos. Cuando recibas una llamada a una herramienta, ejecuta la función correspondiente en tu backend. Consulta la base de datos para obtener el saldo. Contacta al procesador de pagos para obtener el estado de la factura. Añade el resultado de la herramienta al historial de la conversación como un nuevo mensaje con el rol tool, y envía todo el array actualizado de vuelta a Gemma 4.
Repite este bucle hasta que el modelo devuelva una respuesta de texto final. Esa respuesta estará fundamentada en los datos reales que proporcionaste. Express facilita esta coordinación porque cada pasada por el bucle es simplemente otra solicitud HTTP, y puedes usar async/await para la ejecución de la herramienta de forma limpia.
Durante las primeras etapas del desarrollo, respalda estas llamadas a herramientas con datos simulados (mock data). Un simple objeto JavaScript que mapee IDs de cuentas de muestra con saldos es suficiente para demostrar que el bucle funciona. El objetivo es validar el patrón de interacción antes de integrarlo con APIs bancarias de terceros que puedan ser inestables.
Del prototipo a la producción
Un prototipo funcional no es infraestructura bancaria de producción, pero el camino de uno al otro es claro.
Reemplaza los datos simulados con APIs bancarias centrales reales. Conecta tu herramienta get_balance al sistema de libro mayor (ledger) a través de REST o gRPC. Conecta pay_bill con tu conmutador de pagos (payment switch) real. Cuando hagas esto, no necesitarás cambiar el modelo ni la lógica de la conversación; solo tendrás que intercambiar la implementación de los manejadores de las herramientas.
Añade Redis para la gestión de sesiones. El estado conversacional en la banca es sensible y está regulado. Necesitas almacenar los historiales de mensajes de forma segura, expirarlos tras un tiempo determinado y garantizar que la sesión de un usuario no se filtre entre solicitudes. Redis gestiona esto con políticas de TTL y búsquedas rápidas de claves.
Cuando el tráfico crezca, traslada la inferencia a vLLM. AI Studio es excelente para prototipar, pero la inferencia autoalojada con vLLM en clústeres de GPU te brinda control sobre la latencia, el procesamiento por lotes (batching) y el coste a escala. Gemma 4 se ejecuta de manera eficiente bajo vLLM, y el comportamiento de llamada a herramientas sigue siendo idéntico.
La verdadera conclusión
Construir un agente fintech confiable tiene menos que ver con el tamaño del modelo y más con las restricciones arquitectónicas. Gemma 4 proporciona suficiente potencia de razonamiento para analizar el pidgin nigeriano con alternancia de códigos (code-switching) y enrutar intenciones complejas, pero la seguridad proviene del bucle de herramientas. Cada saldo se obtiene en tiempo real. Cada pago de factura es confirmado por un sistema externo. Nada se inventa.
Comienza en el navegador con AI Studio, refuerza la lógica en un bucle de Express y sustitúyela por infraestructura bancaria real una vez que los flujos de conversación sean infalibles. Así es como lanzas un bot con el que la gente realmente puede confiar su dinero.
Fuente: Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent
Comunidad de aprendizaje opcional: GyaanSetu AI on Telegram