DEV Community: Tanush

Building MoneyBuddy: A Multilingual Financial AI Voice Agent for Bharat with Murf Falcon🎙️

Tanush — Sat, 15 Aug 2026 14:19:46 +0000

What started as a simple voice agent became something much bigger over the last ten days.

I built MoneyBuddy, a multilingual AI voice agent for the Financial Services track of the 10 Days of Voice Agents — VoiceForBharat Edition.

The goal was simple:

Make financial guidance easier to access through a natural voice conversation.

Instead of forcing users to navigate complicated forms, search through scheme websites, or understand financial terminology on their own, MoneyBuddy lets them simply talk.

Over ten days, it evolved from a basic voice conversation into a system with persistent memory, financial tools, outbound calling, human escalation, analytics, and specialist-agent handoffs.

And the biggest lesson was that building a useful voice agent is much more than connecting an LLM to a microphone.

The Problem I Wanted to Solve

Government financial schemes can provide meaningful support, but discovering whether a scheme is relevant, understanding eligibility, finding required documents, and knowing what to do next can be difficult.

For many users, especially people who are more comfortable speaking than typing, voice can make that interaction much more natural.

That became the idea behind MoneyBuddy:

A voice-first financial companion that explains, guides, and knows when it should stop and ask for help.

MoneyBuddy focuses on:

Government-scheme guidance
Financial literacy
Eligibility information
Document guidance
Fraud awareness

It is intentionally not a banking transaction system.

MoneyBuddy does not ask users for OTPs, PINs, passwords, CVVs, full card numbers, or sensitive banking credentials.

What MoneyBuddy Became

The project started with a simple voice loop:

User speaks → AI understands → AI responds

By the end of the challenge, it had grown into a much larger system.

MoneyBuddy can now:

Speak using an Indian voice powered by Murf Falcon
Understand English, Hindi, and Hinglish
Follow financial safety guardrails
Show real-time agent states in the frontend
Display a live transcript
Remember returning callers using SQLite
Retrieve memory through function tools
Retrieve government-scheme information through a domain tool
Chain stored caller information into financial lookups
Make outbound phone calls
Ask permission before human escalation
Create escalation requests
Track call outcomes through analytics
Hand conversations to a Government Scheme Specialist
Return conversations from the specialist to the main agent

The important shift was this:

A voice agent becomes a real application when you add state, tools, memory, safety, observability, and failure handling around the conversation loop.

How MoneyBuddy Works

At the core, MoneyBuddy combines four major components:

Deepgram STT — converts speech into text.
Gemini LLM — handles reasoning, conversation, routing, and tool selection.
Murf Falcon TTS — converts generated responses back into speech.
LiveKit — handles real-time audio transport.

For outbound phone calls, LiveKit SIP connects the voice agent to telephony.

The complete architecture

flowchart LR
    U["👤 User<br/>Browser / Phone"] --> LK["LiveKit<br/>Real-time Audio"]

    LK --> STT["Deepgram STT<br/>Speech → Text"]
    STT --> LLM["Gemini LLM<br/>Reasoning + Routing"]

    LLM <--> MEM["SQLite<br/>Caller Memory"]
    LLM <--> TOOL["Financial Tools<br/>Scheme Data"]

    LLM --> SPEC["Government Scheme<br/>Specialist Agent"]

    MEM --> LLM
    TOOL --> LLM
    SPEC --> LLM

    LLM --> TTS["Murf Falcon<br/>Text → Speech"]
    TTS --> LK
    LK --> U

This separation is important.

The LLM is not responsible for everything.

Memory is handled through tools.
Scheme information comes from grounded data.
Human escalation is handled through a dedicated tool.
Specialist routing is handled separately.
LiveKit manages real-time communication.

That made the system easier to reason about and safer to extend.

📸 MoneyBuddy Frontend

The frontend was redesigned around the actual states of a voice conversation.

Instead of displaying only a microphone button, MoneyBuddy clearly communicates whether it is:

Ready
Connecting
Listening
Speaking
Call ended

It also provides:

Live transcript
Microphone permission guidance
Language selection
Financial safety messaging
Reconnection/loading states
Call-ended controls

The interface is intentionally simple.

The user should understand what to do without knowing anything about LiveKit, STT, LLMs, or TTS.

1. Giving MoneyBuddy an Indian Voice

The first challenge was getting a voice agent working end-to-end.

I chose an Indian voice because the target experience is designed for Indian users.

MoneyBuddy uses Murf Falcon for text-to-speech.

Voice quality matters especially for a financial assistant.

A system that gives correct information but sounds robotic, unnatural, or difficult to understand quickly loses trust.

Murf Falcon became an important part of the project because voice-agent UX is heavily affected by the time between:

User stops speaking → Agent starts speaking

That made latency a product decision, not just an engineering metric.

2. Personality, Guardrails, and Multilingual Conversations

Once the basic voice loop worked, MoneyBuddy needed a clear job and strict boundaries.

I defined three primary objectives:

Government-scheme guidance
Financial literacy
Fraud awareness

Then I added financial safety rules.

MoneyBuddy must never request:

OTPs
PINs
Passwords
CVVs
Full card numbers
Sensitive banking credentials

It also cannot promise guaranteed scheme approval or financial outcomes.

Voice-first prompting

A response that looks good in a chat window can sound terrible when spoken.

For voice, I had to think differently.

MoneyBuddy uses:

Short sentences
Natural phrasing
Simple vocabulary
Clear pauses
No raw JSON
No markdown-style responses
No unnecessary technical terminology

I also added support for Hindi and Hinglish.

The goal was not to make users adapt to the system.

The system should adapt to the way users naturally communicate.

3. Building a Frontend for Voice

The frontend became more than a microphone interface.

It visually represents the current state of the agent:

Ready → Connecting → Listening → Speaking → Call Ended

The live transcript makes it clear who said what.

Microphone permission errors are also handled explicitly instead of leaving the user wondering why nothing is happening.

For a voice product, this feedback is essential.

When there is no visible state, a few seconds of network delay can feel like the entire application has crashed.

4. Giving MoneyBuddy Memory

A returning caller should not have to start from zero every time.

I added persistent SQLite memory.

A caller record can contain:

user_id
name
language_preference
facts
last_interaction

But there was an important architectural decision here.

I did not want to dump the entire database into the system prompt.

Instead, MoneyBuddy has function tools for memory operations.

For example:

@function_tool
async def lookup_caller(user_id: str):
    """Look up a caller's saved profile and relevant financial facts."""
    return get_caller(user_id)

The model decides when it needs caller information and calls the function.

This creates a much cleaner separation:

Application data → Tool → LLM

rather than:

Entire database → Prompt → LLM

I also added sanitization before storing financial information so sensitive credentials are not persisted as normal caller facts.

Most importantly:

MoneyBuddy asks for permission before saving information.

5. Giving the Agent Real Financial Data

Memory alone isn't enough.

The agent also needs reliable domain information.

For Day 5, I added a grounded local dataset containing Indian government financial schemes such as:

PM Kisan Samman Nidhi
PM Suraksha Bima Yojana
PM Jeevan Jyoti Bima Yojana
Atal Pension Yojana
PM Mudra Yojana

MoneyBuddy accesses this information through a function tool.

Instead of relying entirely on the LLM's internal knowledge, the agent can retrieve structured scheme information when required.

The dataset also contains recency information so the agent can communicate when its information was last updated.

The principle was simple:

When an answer depends on structured domain data, use a tool instead of hoping the LLM remembers the correct answer.

6. Making MoneyBuddy Call Users

On Day 6, MoneyBuddy stopped waiting for users to initiate every conversation.

I added outbound calling through LiveKit SIP.

The use case was:

A reminder for someone already identified as eligible for a government scheme with an approaching deadline.

Outbound calling requires a different conversational design.

The user did not ask for the call.

So the opening needs to establish three things immediately:

Who is calling.
Why they are calling.
How the user can stop the call.

That makes the interaction more transparent and respectful.

Outbound interaction

flowchart TD
    A["📞 Outbound Call Started"] --> B["User Answers"]

    B --> C["MoneyBuddy identifies itself"]
    C --> D["Explains reason for calling"]
    D --> E["Provides opt-out"]

    E --> F{"User response"}

    F -->|Continue| G["Deliver scheme reminder"]
    F -->|No / Stop| H["End call respectfully"]

    B -->|No answer| I["Call outcome recorded"]
    B -->|Busy| I
    B -->|Immediate hang-up| I

One limitation remained here: carrier-level retry handling for busy, no-answer, and voicemail outcomes was not implemented as a custom retry queue.

The challenge was primarily about demonstrating the outbound interaction itself, so I kept the implementation focused rather than adding an unnecessary retry infrastructure.

7. Knowing When AI Should Ask a Human

One of the biggest lessons from this challenge was:

A good AI agent should know when it should stop.

For MoneyBuddy, human escalation is triggered for situations such as:

Possible financial fraud
Problems requiring a decision the AI cannot make

The agent prepares a short summary containing only useful information:

What happened
What the agent already checked
Urgency
Preferred language
Preferred follow-up method

Before sharing that information, MoneyBuddy asks the caller for permission.

Sensitive credentials such as OTPs, PINs, passwords, and account numbers are excluded.

The caller receives a reference ID and an explanation of what happens next.

Human escalation flow

flowchart LR
    U["User"] --> M["MoneyBuddy"]

    M --> Q{"Needs human help?"}

    Q -->|No| C["Continue conversation"]

    Q -->|Yes| S["Explain what will be shared"]
    S --> P{"Caller gives permission?"}

    P -->|No| N["Do not create request<br/>Continue safely"]
    P -->|Yes| E["Create Escalation"]

    E --> R["Reference ID"]
    R --> X["Explain next step"]

This was an important safety boundary.

The AI doesn't silently send the user's information somewhere just because it thinks escalation is useful.

8. Measuring the System Instead of Guessing

A voice application needs observability.

As part of the challenge, I built a call analytics layer that records call outcomes and exposes them through a dashboard.

The dashboard is designed to track:

Total calls
Successful calls
Failed calls
Success rate
Call history
Failure categories
Track-specific outcomes
Latency

Rather than presenting test-suite results as real-world call statistics, I kept the distinction clear.

The implementation was validated through automated testing across the different challenge features.

By Day 9, the specialist routing tests passed:

14/14 tests passed

The broader behavioral test suite passed:

16/16 tests passed

And the backend pytest suite passed:

4/4 tests passed

These results demonstrate that the core workflows were functioning as implemented, while the dashboard provides the foundation for collecting real call metrics as the system is used.

This distinction matters.

Automated tests tell me whether the system behaves correctly under defined scenarios. Real call metrics tell me how the system performs with actual users.

For this challenge, I chose not to invent latency or call-success numbers that I could not independently verify.

9. The Multi-Agent Step

The final major technical step was turning MoneyBuddy into a multi-agent system.

The main agent remains the general financial assistant.

When the user needs deeper government-scheme knowledge, MoneyBuddy can hand the conversation to a dedicated:

Government Scheme Specialist

The specialist has its own role, instructions, and boundaries.

The user should not have to explain the entire problem again.

Specialist handoff architecture

flowchart TD
    U["👤 User"] --> M["MoneyBuddy"]

    M --> Q{"Does the request<br/>need specialist knowledge?"}

    Q -->|No| M

    Q -->|Yes| A["Announce handoff"]
    A --> H["Handoff Tool"]

    H --> S["Government Scheme<br/>Specialist"]

    S --> C["Continue same conversation"]

    C --> D{"Task complete?"}

    D -->|No| S
    D -->|Yes| R["Return to MoneyBuddy"]
    D -->|Topic changed| R

    R --> M

This is one of the places where a multi-agent architecture becomes useful.

Instead of giving one giant prompt to one giant agent, each agent gets a narrower responsibility.

10. Solving Handoff Latency

The specialist handoff introduced another voice-specific challenge.

If the system waited for the specialist's entire LLM response before speaking, the user could experience an awkward silence.

So I changed the flow.

The specialist can immediately acknowledge the handoff:

await session.say(
    "Hi, I'm the Government Scheme Specialist. "
    "I'll help you with that."
)

Then the detailed response can continue generating.

The goal is to separate:

"The specialist has taken over."

from:

"The specialist has finished generating the complete answer."

That small architectural change makes the handoff feel much faster.

11. Deterministic Agent Identity

Another interesting problem appeared in the frontend.

Initially, the UI could try to determine which agent was active by inspecting transcript text.

That is unreliable.

For example, if the normal MoneyBuddy agent happened to say the word "specialist", the frontend could incorrectly display the specialist state.

So I changed the architecture to use explicit application state / LiveKit participant metadata.

Conceptually:

active_agent = "moneybuddy"

or:

active_agent = "specialist"

The frontend reads the state directly.

This led to another useful lesson:

UI state should come from application state, not guesses extracted from conversation text.

12. The Design Decision I Changed

One of the most important design decisions I changed during the challenge was how MoneyBuddy handled memory.

The initial temptation was to load stored caller information directly into the system prompt.

It works, but it creates problems.

The prompt becomes larger.

The model receives information it may not need.

And the separation between application data and model instructions becomes weaker.

So I changed the architecture to:

Caller needs information
        ↓
Memory lookup tool
        ↓
SQLite
        ↓
Relevant data returned
        ↓
LLM uses only what it needs

This made the memory architecture cleaner and easier to control.

13. The Hard Parts

The hardest part wasn't getting an LLM to answer questions.

It was making all the components behave reliably together as a real-time voice application.

Multilingual voice handling

Hindi and Hinglish required more than simply changing the prompt.

STT, language detection, LLM output, writing script, and TTS configuration all had to work together.

Voice formatting

Text that looks fine on a screen can sound terrible when spoken.

I had to continuously simplify responses, remove formatting artifacts, and keep sentences short.

Handoff latency

Switching agents introduced another potential delay.

The solution was to immediately speak the specialist introduction rather than waiting for the complete response.

Agent identity

Transcript-based UI detection caused unreliable specialist labels.

Explicit state solved that problem.

Keeping previous days stable

Every new feature had to coexist with everything already built.

I maintained separate day branches and repeatedly ran the existing test suites before pushing changes.

This helped prevent later features from accidentally breaking earlier functionality such as memory, analytics, or guardrails.

14. Testing and Reliability

One thing I deliberately focused on throughout the challenge was not just adding features, but verifying that existing features remained intact.

By Day 9, the project had dedicated tests covering:

Behavioral agent behavior
Memory functionality
Financial guardrails
Day 8 analytics
Day 9 specialist routing
Specialist handoff behavior
Fallback handling

The final Day 9 routing test suite passed:

14/14 tests

The broader behavioral suite passed:

16/16 tests

And the backend pytest suite passed:

4/4 tests

These are automated test results, not real-user success metrics.

That distinction is important.

15. Running MoneyBuddy Yourself

The complete Day 10 repository is available here:

https://github.com/tanush326k/murf-livekit-starter/tree/day10

The project contains a backend voice agent and a Next.js frontend.

The main architecture looks roughly like:

murf-livekit-starter/
│
├── backend/
│   ├── src/
│   │   ├── agent.py
│   │   ├── prompt.py
│   │   ├── db.py
│   │   ├── schemes_data.json
│   │   └── outbound.py
│   │
│   └── tests/
│
└── frontend/
    ├── components/
    ├── app/
    └── styles/

Main components

The project uses:

Python
LiveKit
Deepgram
Gemini
Murf Falcon
SQLite
Next.js

Environment variables

Create your local environment configuration and add your own credentials.

For example:

MURF_API_KEY=your_key_here
DEEPGRAM_API_KEY=your_key_here
GOOGLE_API_KEY=your_key_here

LIVEKIT_URL=your_livekit_url
LIVEKIT_API_KEY=your_livekit_api_key
LIVEKIT_API_SECRET=your_livekit_api_secret

Never commit real API keys to GitHub.

After installing the backend and frontend dependencies, start the required services, open the frontend, allow microphone access, and start a conversation.

The exact setup commands are documented in the repository.

16. Troubleshooting

The agent connects but doesn't speak

Check the backend logs first.

Then verify:

LiveKit credentials
Deepgram configuration
Gemini configuration
Murf credentials
TTS voice configuration

A voice agent is a pipeline.

One broken component can make the entire application appear silent.

Hindi is understood but sounds wrong

Check both sides of the pipeline.

The STT configuration must support multilingual input.

The TTS configuration must use the appropriate Indian voice configuration.

The LLM should also return Hindi using Devanagari when Hindi output is expected.

The specialist handoff feels slow

Don't wait for the entire specialist response before starting audio.

Give the specialist an immediate spoken introduction and then continue generating the detailed response.

The frontend shows the wrong active agent

Don't infer agent identity from transcript text.

Use explicit application state or LiveKit participant metadata.

17. What I Would Improve Next

If I continued building MoneyBuddy beyond the challenge, I would focus on production readiness.

The next areas would include:

Stronger multilingual evaluation
More comprehensive government-scheme sources
More robust telephony retry handling
Better tool observability
Stronger authentication and privacy controls
Better human-support workflows
More detailed latency breakdowns
Production-grade monitoring
Larger-scale testing with real conversations

The goal would be to move from a challenge project toward a system that could be responsibly used in a real financial-support environment.

What Ten Days Taught Me

The biggest lesson from this challenge is that building a voice agent isn't primarily about choosing the biggest model.

It's about everything around the model.

You need:

Good speech recognition.
Fast text-to-speech.
Clear instructions.
Strong guardrails.
Useful tools.
Persistent state.
Reliable transport.
Observability.
Human escalation.
Graceful failure handling.

The LLM is only one part of the system.

Once voice becomes the interface, latency, state, turn-taking, and response formatting become product decisions — not just engineering details.

MoneyBuddy started as an agent that could hear me and talk back.

Ten days later, it can remember users, access financial data, make outbound calls, escalate difficult situations, measure conversations, and hand complex questions to a specialist.

That progression was the most valuable part of the challenge.

Final Takeaway

If you're building your own voice agent, my biggest advice is:

Don't start by trying to make it do everything.

Make it talk.

Then give it a job.

Then give it boundaries.

Then give it tools.

Then give it memory.

Then make it reliable.

And only after that, start making it smarter.

Project

MoneyBuddy — Day 10 Repository

https://github.com/tanush326k/murf-livekit-starter/tree/day10

Challenge:
10 Days of Voice Agents — VoiceForBharat Edition

Built with:
LiveKit • Deepgram • Gemini • Murf Falcon • Python • Next.js • SQLite

If this project helps you build your own voice agent, I'd love to see what you create.

My First Experience with SigNoz

Tanush — Sat, 11 Jul 2026 03:49:48 +0000

Modern applications, especially AI agents and distributed systems, need more than logs to understand what is happening. That's why I explored SigNoz, an open-source observability platform built on OpenTelemetry.

Setting up SigNoz with Docker was simple. After connecting a sample application, I could view logs, metrics, and traces from a single dashboard within minutes.

My favorite feature is distributed tracing. Instead of guessing where requests slow down or fail, SigNoz clearly shows the complete request journey across services, making debugging much easier.

The built-in dashboards provide valuable insights into CPU usage, memory, request latency, throughput, and error rates. Having centralized logs alongside metrics and traces saves time by eliminating the need to switch between multiple tools. I also liked the alerting feature, which helps detect issues before they affect users.

For AI applications, observability is essential. AI agents make multiple API calls, use tools, and perform complex workflows. SigNoz makes it easier to understand each step, identify failures, measure latency, and optimize performance.

Overall, my experience with SigNoz was excellent. It combines logs, metrics, traces, dashboards, and alerts into one intuitive platform. Among all its features, distributed tracing impressed me the most because it provides deep visibility into application behavior and simplifies troubleshooting.

I'm excited to use SigNoz in future AI and cloud-native projects.

From Hackathon Chaos to Clean CLI: Reviving My Daily Routine Analyser with GitHub Copilot

Tanush — Sat, 23 May 2026 15:43:49 +0000

🧠 What I Built

I revived a C-based CLI project called Daily Routine Analyser, originally built during a hackathon under extreme time pressure.

At its core, the tool helps users break down their 24-hour day into:

Study 📚
Sleep 😴
Exercise 🏃
Leisure 🎮

It then calculates a simple productivity score out of 10 and provides insights about daily balance.

What started as a rushed prototype has now been transformed into a clean, modular, and readable CLI application with improved structure and logic.

👉 GitHub Repo: https://github.com/tanush326k/daily-routine-analyser

🎬 Demo

🔗 GitHub Repository:

https://github.com/tanush326k/daily-routine-analyser

💻 How it works:

User enters daily activity hours
Program validates total ≤ 24
System evaluates habit balance
Outputs:
- Time breakdown
- Habit insights
- Final productivity score (/10)

🔁 The Comeback Story

The original version of this project was written during a hackathon in a highly rushed environment.

🔴 Before (Hackathon Version)

Everything inside a single main() function
No modular structure
Hardcoded logic and repetitive flow
Built just to “make it work”

It functioned — but it wasn’t maintainable or scalable.

🟢 After (Revived Version)

When I revisited it, I focused on turning it into something cleaner and more structured:

Refactored code into modular functions
Improved scoring logic clarity
Added structured thinking using struct
Enhanced readability and maintainability
Cleaned up nested loops and logic flow

The goal wasn’t just to fix it — it was to make it feel like a real project, not a hackathon leftover.

🤖 My Experience with GitHub Copilot

GitHub Copilot played a key role in this revival process.

It helped me:

Break down a large main() function into smaller reusable functions
Suggest cleaner implementations for scoring logic
Improve structure using struct for better data organization
Reduce unnecessary nesting and improve readability
Speed up refactoring decisions

Instead of writing everything from scratch again, Copilot acted like a pair programmer helping restructure legacy code into something clean and modern.

💡 Key Takeaway

This project taught me that:

“A hackathon project is not the end — it’s the starting point.”

Even simple ideas can become meaningful software when revisited with better structure and tools.

🚀 Future Improvements

Save daily logs to CSV
Weekly progress tracking system
Graph-based visualization
Habit streak tracking system
Possible GUI/web version

👨‍💻 Closing Note

This project represents my journey from:
“just getting it working” → “making it well-designed and maintainable.”

And GitHub Copilot helped accelerate that transformation significantly.

🧠 Hermes Agent Assistant — A Modular AI Agent System with Planner, Executor & Memory

Tanush — Sat, 23 May 2026 14:43:32 +0000

🚀 What I Built

I built Hermes Agent Assistant, a lightweight agentic AI system designed to demonstrate how modern AI agents can be structured using a modular architecture instead of a simple, single-prompt response model.

The system takes an abstract user task, breaks it down into structured steps using a dedicated planner, executes those steps sequentially via an execution engine, utilizes targeted tools, and stores the interaction context in a persistent memory system.

⚙️ Why I Built This

Most AI applications today are simple wrappers around LLMs that rely on a single input-output loop. I wanted to understand and demonstrate how production-grade, autonomous agent systems operate internally. Specifically, I wanted to explore how:

Planning can be decoupled from execution to allow for complex error handling and multi-step reasoning.
Tools can be dynamically integrated into an agent's reasoning loop.
State and memory can persist across tasks to enable true contextual continuity.

Hermes Agent is my architecture simulation built to solve this problem in a highly accessible, lightweight, and scalable format.

🧠 System Architecture & Workflow

The codebase is split cleanly into four autonomous components that mirror real-world AI agent meshes:

       User Request (e.g., /run?task=...)
                     │
                     ▼
       ┌───────────────────────────┐
       │         PLANNER           │ ➔ Slices abstract goals into 
       └─────────────┬─────────────┘   structured, sequential steps.
                     │
                     ▼
       ┌───────────────────────────┐
       │        EXECUTOR           │ ➔ Orchestrates task completion 
       └─────────────┬─────────────┘   by processing each step.
                     │
                     ▼
       ┌───────────────────────────┐
       │       TOOLS LAYER         │ ➔ Provides functional utilities 
       └─────────────┬─────────────┘   (simulated web search, logic, maths).
                     │
                     ▼
       ┌───────────────────────────┐
       │      MEMORY SYSTEM        │ ➔ Persists execution logs statefully 
       └───────────────────────────┘   into local JSON storage.

📡 Production Showcases & Links

🌐 Live Production Demo: hermes-agent-tanush.onrender.com
💻 Open Source Repository: https://github.com/tanush326k/hermes-agent-assistant.git
🆔 Cloud Deployment Service ID: srv-d88revegvqtc73bdj380 (Render Infrastructure Node)

💡 What Makes It Different

Unlike traditional, rigid APIs or simple conversational chatbots, Hermes Agent:

Thinks in Workflows: It establishes an internal chain-of-thought lifecycle before executing anything.
Separates Reasoning from Action: Slicing the Planner from the Executor prevents cascading generation failures.
Is Highly Extensible: New tools and custom utility logic can be dropped into the system without breaking core routing.
Maintains Context Persistence: The custom memory module ensures state history is preserved between network calls.

🎛️ API Interaction Example

Request

POST /run?task=search AI agents HTTP/1.1
Host: hermes-agent-tanush.onrender.com

Response

{
  "task": "search AI agents",
  "plan": [
    "analyze request parameters", 
    "query tool registry for search utilities", 
    "summarize agent data structural output"
  ],
  "result": "final structured output successfully generated and written to persistent storage."
}

🧰 Tech Stack

Core Language: Python 3.10+
Web Framework: FastAPI (Asynchronous Server Gateway Interface)
Production Server: Uvicorn
Memory Layer: Volatile-to-Persistent JSON state manager
Architecture Pattern: Modular Agentic Workflow Design

🔮 Future Improvements & Roadmap

🤖 Real Foundation LLM Integration: Swapping out simulated logic for live OpenAI, Anthropic, or local open-source Ollama completion hooks.
🗄️ Vector Database Memory Upgrade: Transitioning flatfile storage over to a proper semantic vector indexing framework (FAISS / ChromaDB) for semantic chunk lookups.
🤝 Multi-Agent Orchestration: Upgrading the workflow to host distinct Planner, Executor, and Critic agents working collaboratively with separate system prompts.
⚡ Live Server-Sent Events (SSE): Integrating real-time execution streaming so client frontends can observe the agent's thought process step-by-step.

Google I/O 2026 and the Rise of the AI Ecosystem

Tanush — Sat, 23 May 2026 13:25:53 +0000

Google I/O 2026: The Year AI Became Truly Developer-First

Every year, Google I/O gives us a glimpse into where technology is heading. But this year felt different.

Google I/O 2026 wasn’t just about flashy demos or incremental updates — it felt like a major shift toward making AI genuinely usable for developers, creators, and everyday builders. From Gemini integrations to Firebase AI tooling and Flutter improvements, the announcements painted a clear picture: Google wants AI to become part of every workflow, not just a standalone feature.

After following the keynotes and diving into the sessions, one theme stood out to me:

The barrier between an idea and a working product is shrinking faster than ever.

And honestly, that’s both exciting and a little overwhelming.

The Biggest Takeaway: AI Is Becoming Infrastructure

The most impressive part of this year’s announcements wasn’t a single model or product release. It was how deeply AI is now integrated into Google’s ecosystem.

During the Google Keynote and the “What’s New in Google AI” session, it became obvious that Google is no longer treating AI as an experiment. AI is now infrastructure.

Instead of asking developers to “add AI,” Google is embedding intelligence directly into:

Android development
Search experiences
Firebase workflows
Cloud tooling
Flutter applications
Productivity tools

That changes how we think about software development entirely.

We’re moving from:

Writing every feature manually

To:

Orchestrating systems that can reason, generate, and adapt.

Firebase + AI Was the Most Practical Announcement

Out of everything announced, the Firebase updates were probably the most exciting for me as a developer.

Not because they were flashy.

Because they were immediately useful.

The new AI-powered Firebase workflows seem focused on solving real development bottlenecks:

Faster backend setup
Smarter debugging
Automated app flows
Better AI integrations without huge infrastructure complexity

For indie developers and small teams, this matters a lot.

One of the hardest parts of building modern applications is no longer just coding — it’s managing scale, integrations, authentication, analytics, AI APIs, deployment pipelines, and user experience all at once.

Firebase is evolving into something much bigger than a backend service.

It’s becoming an AI-assisted development platform.

And that’s a huge shift.

Flutter Quietly Had One of the Best Sessions

The “What’s New in Flutter” session didn’t generate the same hype as the AI announcements, but I think it deserves more attention.

Flutter continues to mature into one of the most efficient cross-platform frameworks available today. What stood out this year was Google’s focus on:

Performance improvements
Better tooling
Faster iteration cycles
Stronger AI-assisted workflows for UI development

The interesting part is how AI and Flutter now complement each other.

AI can accelerate:

UI generation
Component scaffolding
Documentation
Testing
State management suggestions

But Flutter still gives developers control over the final experience.

That balance matters.

A lot of AI-generated software today still feels generic. Flutter remains one of the best tools for developers who want productivity without sacrificing creativity.

AI Coding Assistants Are Entering a New Phase

Another thing I noticed across multiple sessions was the evolution of AI coding tools.

Last year, AI assistants mostly helped autocomplete code.

This year, the focus shifted toward:

Multi-step reasoning
Context-aware workflows
Architecture suggestions
End-to-end development assistance

That’s a massive leap.

We’re quickly approaching a world where developers spend less time writing boilerplate and more time:

Designing systems
Reviewing logic
Shaping product experiences
Making architectural decisions

Ironically, AI may make human creativity even more valuable.

Because when everyone can generate code quickly, the real differentiator becomes:

Product thinking
User empathy
Taste
Problem selection

The Most Underrated Shift: Developer Accessibility

One thing I think people are underestimating is how much easier entry into software development is becoming.

A few years ago, building an AI-powered application required:

ML expertise
Infrastructure knowledge
GPU access
Large engineering budgets

Now?
A solo developer can prototype surprisingly advanced applications using Google’s ecosystem.

That democratization is probably more important than any single feature announcement.

The next generation of builders won’t need permission, massive teams, or huge funding rounds to create impactful products.

That changes innovation itself.

My Biggest Question After I/O 2026

As exciting as everything looks, I still have one major question:

How do we prevent AI-assisted development from making software feel identical?

When tools generate interfaces, code structures, and workflows automatically, there’s a risk that creativity becomes standardized.

The challenge for developers moving forward won’t just be learning AI tools.

It’ll be learning how to use them without losing originality.

The best developers in the AI era may not be the people who automate everything.

They may be the people who know where human judgment still matters most.

Final Thoughts

Google I/O 2026 felt less like a product showcase and more like a preview of a new development era.

The biggest innovation wasn’t one model, framework, or API.

It was the growing idea that software creation itself is changing.

Developers are transitioning from:

Writing every system manually

To:

Collaborating with intelligent tools.

And while the technology is impressive, the real opportunity lies in what people choose to build with it.

That’s the part I’m most excited about.

Because the future of development won’t belong to AI alone.

It’ll belong to developers who learn how to work alongside it creatively.

Local AI is Here: Which Gemma 4 Model Should You Actually Use? 🚀

Tanush — Sat, 23 May 2026 13:09:08 +0000

🚀 The Local AI Shift: Choosing Your Gemma 4 Tooling Strategy

The landscape of Large Language Models (LLMs) is shifting. For a long time, the "smart" models lived exclusively in the cloud, behind expensive APIs and strict rate limits.

With the release of Gemma 4, Google has pushed the boundary of what "open weights" can actually do. From native multimodality to a massive 128K context window, Gemma 4 isn't just a research project—it's a developer's toolkit.

But as any developer knows, bigger isn't always better. The Gemma 4 family comes in three distinct flavors. If you're staring at Hugging Face wondering which one to download, this guide is for you.

🛠️ The Gemma 4 Lineup: A Breakdown

Model Variant	Best For	Architecture Focus	Key Benefit
Gemma 4 (2B & 4B)	Mobile, IoT, Browser AI	Extreme Edge Execution	Zero API Cost & Full Privacy
Gemma 4 (31B Dense)	Local Workstations, RAG	Balanced "Goldilocks" Dense	High Stability & Reasoning
Gemma 4 (26B MoE)	High-Throughput Engine	Mixture-of-Experts (MoE)	Speed & Complex Logic

1. The "Edge" Experts (2B and 4B)

Best for: Mobile apps, browser-based AI, IoT, and Raspberry Pi 5.
The Blueprint: These models are optimized for the extreme edge. We are talking about AI that runs locally on a Pixel phone or a tiny credit-card-sized computer without needing an internet connection.
The Use Case: Imagine a privacy-first personal assistant that lives entirely on a user's device, or a smart-home controller that processes voice and text locally to reduce latency.
Why choose this? Minimal RAM usage, zero API costs, and maximum data privacy.

2. The Versatile Workhorse (31B Dense)

Best for: Local workstations, server-grade local execution, and general-purpose apps.
The Blueprint: The 31B Dense model is the "Goldilocks" of the family. It bridges the gap between the lightweight edge models and the high-performance MoE versions.
The Use Case: Building a local coding assistant or a specialized RAG (Retrieval-Augmented Generation) pipeline where you need high reliability and stability across a wide variety of tasks.
Why choose this? It offers a powerful balance of reasoning capabilities and local deployability on consumer GPUs.

3. The Reasoning Specialist (26B MoE)

Best for: High-throughput applications, complex reasoning, and advanced logic.
The Blueprint: The Mixture-of-Experts (MoE) architecture is the secret sauce here. Instead of activating every parameter for every prompt, it only uses a fraction of its weights, making it incredibly efficient without sacrificing "intelligence."
The Use Case: Complex data analysis, automated software engineering tasks, or any application where you need "smarter" reasoning but can't afford the latency of a massive 100B+ parameter model.
Why choose this? High throughput (speed) and superior reasoning logic.

🌟 The "Game Changer" Features

Regardless of which size you choose, three features make Gemma 4 a powerhouse for developers:

🖼️ Native Multimodality
Gemma 4 doesn't just "read" text; it understands images and (in the smaller models) audio natively. This opens the door for apps that can "see" a UI screenshot and write the HTML/CSS to recreate it, or "hear" a meeting and summarize the key action items.

📚 The 128K Context Window
A 128K context window is a massive deal for developers. You can now feed an entire library of documentation, several large source code files, or a massive PDF into the prompt without the model "forgetting" the beginning.

🔓 Open Weights, Open Innovation
Because these are open weights, we aren't just "users" of an API; we are owners of the model. We can fine-tune Gemma 4 on our own proprietary data, quantize it to run on weaker hardware, and deploy it in air-gapped environments.

🚀 How to Get Started Right Now

You don't need a supercomputer to start experimenting. Choose your preferred integration path below:

🛠️ The "Zero Setup" Path
Use Google AI Studio to test the models via API immediately. Great for fast prototyping.

💻 The "Local Dev" Path
Download the weights from Hugging Face or Kaggle and run them using Ollama or vLLM directly in your terminal.

🌐 The "Free Tier" Path
Access the 31B model via OpenRouter's free tier to test the logic before committing to a local install.

🧠 Final Thoughts

The "Local AI moment" is about moving from AI as a Service to AI as an Ingredient. Whether you are building a tiny app for a Raspberry Pi or a massive reasoning engine for an enterprise, Gemma 4 provides the architectural flexibility to make it happen.

👇 Let's Connect!

Which model are you planning to build with? What's your current local AI stack look like? Let's discuss in the comments!

🚀 Building Smarter with Google Cloud

Tanush — Wed, 29 Apr 2026 04:39:27 +0000

🚀 From Curiosity to Creation: How Google Cloud NEXT Changed the Way I Think About Building

«“The future isn’t built by those who wait — it’s built by those who experiment.”»

🌩️ My First Step into Google Cloud (and Why It Felt Different)

Before diving into Google Cloud, I used to think cloud platforms were just about storage, servers, and scaling. But when I explored what Google showcased at Google Cloud NEXT, I realized something bigger:

👉 It’s not just infrastructure — it’s intelligence + innovation combined.

What stood out to me wasn’t just the tools, but the philosophy:

«Build faster. Think bigger. Let AI handle the heavy lifting.»

🧠 The Moment That Changed Everything: AI Meets Cloud

The most exciting part of Google Cloud NEXT was how deeply AI is integrated into everything.

We’re not just writing code anymore — we’re collaborating with AI.

Imagine:

Writing backend logic with AI assistance
Deploying apps without worrying about infrastructure
Analyzing huge datasets in seconds

This shift made me realize:

«The developer of today is becoming more of a creator + problem solver, not just a coder.»

⚙️ What I Explored (And Loved)

Here are a few things that genuinely impressed me:

🔹 1. Vertex AI — Your AI Playground

Instead of struggling to build ML models from scratch, Google Cloud gives you a complete ecosystem.

💡 What I tried:

Experimented with prompts
Explored how models can be tuned
Understood how apps can be powered by AI

👉 It felt like having a brain inside my application.

🔹 2. Serverless = Freedom

The idea that I can deploy apps without managing servers blew my mind.

No worrying about:

Scaling
Downtime
Infrastructure setup

Just focus on:

«✨ Building something meaningful»

🔹 3. Real-Time Data Feels Magical

With Google Cloud tools, data isn’t just stored — it’s alive.

You can:

Process streams
Analyze instantly
Make decisions in real-time

And that’s where innovation happens.

🔥 A Small Idea That Became Big

Inspired by what I learned, I thought:

👉 What if I build a smart student assistant using Google Cloud?

Something that:

Answers questions
Helps with notes
Suggests learning paths

Using:

AI models
Cloud functions
Real-time data

That’s when it clicked:

«Google Cloud doesn’t just give tools — it gives possibilities.»

🌍 Why This Matters for Developers Like Us

We’re entering a phase where:

Speed matters
Ideas matter more than resources
Anyone can build something impactful

Google Cloud is lowering the barrier.

You don’t need:

Huge teams
Expensive setups

You just need:

«💡 Curiosity + willingness to try»

🚀 My Biggest Takeaway

After exploring Google Cloud NEXT, one thought stayed with me:

«“Don’t just learn technology. Use it to create something that didn’t exist yesterday.”»

✨ Final Thoughts

Google Cloud NEXT isn’t just an event — it’s a glimpse into the future.

A future where:

AI is your teammate
Cloud is your foundation
And ideas are your only limit

And honestly?

👉 I’m just getting started.

If you're a student or beginner like me — don’t wait to feel ready. Start exploring. The cloud is more accessible than ever.