lt all started with a simple conversational AI agent
When I first decided to build a conversational agent, I wasn’t trying to invent a new architecture. I just wanted something that worked. When I wasn’t aware what is the current trend to build agents, for days, I went for learning lang graph, and after a few days, I heard about Google Agent development Kit being released. In this blog, I will talk about how to quickly start with your agent building and prototyping with Google ADK. Later, in this blog series, I will talk about how to evolve the architecture for production-grade agents and quickly scale it up for business needs. I will be referencing Google ADK constructs as my core agent-building framework.
What is the Agent Development Kit from Google
This is what I got from the Google ADK Github
Step 1. My First Agent in Google ADK
The idea was simple, I don’t have to innovate an LLM and will be simply forwarding all my queries to the state of the art LLM being released day-by-day from different LLM providers like OpenAI, Google, Facebook, Anthropic and many more to count, In terms of use cases, there will always be specialized ones. I will route all different prompts to a model where it works best. Here is how it simply looked like:
Looks very simple. right? The main agent would be doing what it has been asked to do. Redirecting all the infromation to LLM models.
Step 2. Using a Tool Call in Google ADK
There would be an agent that will be using another function (as tool-calls in Google python SDK) to pull the prompts and then using that as a system prompt. example of main interface here:
This is how the tool is defined, just another function using if-then-else to get the desired prompts.
And it worked perfectly fine. It is not a perfect example of how a product should be built. It was a happy moment that something was working that was as simple as if-then-else condition.
3. Thinking Big. Why a prompt needed to be changed frequently?
Most of the foundational models are trained on the entire internet. Unless you are not telling it exactly what to do, It would be a nice and “tyring to be helpful” assistent thing. I kind of totally agreed on this one from Jeremy Utley. AI would not give you answers and keep playing around like a nice friend until it is role-playing and super specific prompt.
It is important to make sure whatever prompts are stored as part of the Application, later it is sure to be updated as soon as we are done with the experiments and we are sure that there are some other prompts performing better at getting good results. Hence, our prompts are the brand voices when we use them for our marketing, or in the engineering context, those are the real parameters that make the system behave the way it does.
Prompts are not just Strings, they are behavioral contract in Generative AI Land
4. File-Based Prompt Configuration (Still Monolithic, But Smarter)
Before jumping into databases, registries, or remote config services, I asked: What’s the simplest possible improvement? The answer was:
Move prompts out of code, but keep everything else intact. No distributed system. No dynamic runtime injection. No prompt registry (yet). Just files.
At this point, I had solved one problem, taking the prompts out of core agent logic and making it injectable. I could still version it with git commit messages. The purpose is solved. I was thinking about a completely separate layer so that I can deploy them as a separate entity.
That’s it. I have no
- Runtime prompt composition
- File-based configuration
- Zero architectural complexity increase
And have the following design so far:
The Working Monolith wasn’t the final architecture — it was the necessary first step. By keeping everything in one place, I understood what truly powers a conversational agent: prompts as behavioral parameters, routing as composition, and the system prompt as the bridge between business intent and machine reasoning. Moving from hardcoded strings to file-based prompts shifted them from implementation details to configurable assets.
What next? – MCP Server as prompt Gateway!
This phase wasn’t about scalability; it was about clarity and control. Once that understanding solidified, a new question emerged: how can prompts evolve independently of the application? That curiosity sets the stage for Part II. In part II of this blog, I am going to discuss an MCP server-based architecture that helped me move my prompting to another layer. Thanks for tuning!
Got to Part II https://blog.nashtechglobal.com/where-does-my-prompt-live-part-ii-breaking-out-of-the-monolith/