Day-6 | AI Agents Zero to Hero | MCP & Memory Bank (Agent Memory)
Publicado no IA Dots ·
Agentes de IAAI Signaldot-ai_agentsdot-artificial_intelligenceidioma-enInglêsyt-QWcmbRFi4sc
Vídeo em Inglês, publicado pelo canal Abhishek.Veeramalla.
About this content: The summary, key points and topics below are generated automatically from the video transcript. They reflect the content, opinions, claims and predictions presented in the video and do not represent a position, validation or fact-check by IA Dots.
Video summary
This video explains how to add two crucial missing capabilities, Model Context Protocol (MCP) and memory bank, to a production-deployed AI agent using the Gemini Enterprise Agent platform and Google Cloud.
Key points
- The video demonstrates how to implement MCP to allow an agent in a managed agent runtime to securely connect and inspect a remote GKE Kubernetes cluster.
- An MCP server is deployed within the GKE cluster using a load balancer service to safely expose Kubernetes troubleshooting tools.
- The memory bank feature from the Gemini Enterprise Agent platform is enabled to allow the agent to remember past incidents across different sessions.
- The narrator tests the agent's memory bank by introducing a faulty Nginx deployment and verifying that the agent recalls previous troubleshooting reports instead of repeating the full investigation.
- A final evaluation scenario is added and executed using the agent CLI to ensure regression testing for the memory bank feature.
Topics
AI AgentModel Context ProtocolMemory BankGoogle Kubernetes EngineAgent RuntimeGemini Enterprise Agent PlatformAgent CLI
Video transcript
Transcript from available captions; it may contain errors.
Hello everyone. My name's Abhishek and welcome back to my channel. So this is day six of building an AI agent from zero to hero. In the previous episode, that is day five, we learned how to deploy our agent to production. We learned it through three different deployment targets. So we deployed our agent to production using Agent Runtime, Cloud Run, and Google Kubernetes Engine. In today's video, let's address the two important missing capabilities of this agent. Yes. Our agent is running in production, but it is missing two very important capabilities. One, MCP, and two, memory bank. Let me explain these in very simple words for you. We will start with MCP. So why do we need MCP here? If you remember, when we initially built this agent, we built it using ADK and Agent CLI. The agent was running locally, and our Kubernetes cluster was also set up locally. So we were using a local Kubernetes cluster, kind cluster. So the investigation that agent was performing were running against this local Kubernetes cluster, which is good. But now, we deployed the agent to production. At the same time, we moved our local Kubernetes cluster to a managed Kubernetes cluster on Google Cloud. So how the agent can talk to the managed Kubernetes cluster on the Google Cloud platform? So you need a secure connection here. This is where MCP can help. Then the other thing, memory bank. What exactly is this? So basically our agent can remember the conversations within a session. We deployed our agent to Agent Runtime. Agent Runtime comes with the default session management. So within a session, agent can remember the conversations. But we want our agent to also remember the conversations across the sessions. Just imagine, you're using this agent in production. Few days ago, one of the services, let's say the payment service, ran into crash loop back off. Agent performed the investigation. Agent figured out the issue. It shared as a very detailed investigation report. And few days later, let's say 7 days later, the payment service ran into similar issue. Now, do you want the agent to perform the investigation right from zero? Or do you want the agent to go back, look into the memory, and see if there is any similar issue, and start from there? Of course, we want the later one. So, this is exactly where memory bank can help. Memory bank is a feature that is part of Gemini Enterprise Agent platform. I'll show you how to make use of it. Perfect. So, this is going to be a very insightful video. And before we get started, if you also want to implement these videos practically, like you also want to understand the agent life cycle practically, you can use the link in the description or in the pin comment. Create an account with Google Cloud platform. For the very first sign up, you get up to 300 US dollars in free credits. Using which, you can use the Gemini Enterprise Agent platform. And also, I would like to thank Google for sponsoring this entire series. Let's get started. So, how are we going to implement MCP and memory bank? We will follow five steps in this video. Let me quickly walk you through the steps before we start with the implementation. So, we will start with step one, switching our deployment target to agent runtime. Why? Because agent runtime gives us a fully managed environment with built-in session management, observability, and native support for memory bank. And we don't have to manage the agent's hosting infrastructure. Saying that, you can implement these capabilities with other two deployment targets as well, that is Cloud Run and GKE. And once we are done with this, we will head to step two, setting up MCP. This is where we have an interesting architecture problem to solve. As I told you, when we initially set up this agent, agent was running on the laptop and the Kubernetes cluster was also running on the laptop. So, we were using a kind Kubernetes cluster. Now, we move the agent to agent runtime and instead of using a local Kubernetes cluster, we are using a managed Kubernetes cluster on the Google Cloud Platform. And of course, our agent that is deployed to agent runtime has no cube config file. To solve this cleanly, we are going to deploy an MCP server that is right inside our managed Kubernetes cluster or the GKE cluster. And that MCP server will use the in-cluster Kubernetes permissions to inspect the pods, logs, events, and nodes and also expose those five troubleshooting tools safely over a GKE load balancer. And then finally, our agent in the agent runtime will connect to it remotely as an MCP client. So, this is how MCP can help. And of course, once we implement MCP, we have to verify the live connection and that is our step three. So, we will make sure our agent in the agent runtime can handshake with the MCP server in GKE, discover the five Kubernetes tools, and pull live node and pod statuses from the cluster without needing any local credentials. So, this will complete the part one, MCP part. In step four, we will go ahead and enable memory bank in Gemini Enterprise Agent Platform. And this is definitely my favorite part because we are going to give our agent a brain that remembers. And this is going to help us a lot in the production. Basically, every time the agent finishes an investigation, let's say an incident like OOM killed or bad configuration, it will automatically extract the root cause, which our agent has been doing, but along with that, it will save this into the memory bank. And even better thing, whenever there is a new alert, let's say a new alert came in, agent will automatically check its memory bank first to see if we have seen this exact issue before. And we will be able to see those stored memories right inside the Google Cloud console. Of course, once we implement this, I'm going to show you through the Google Cloud console. And finally, step five, we will add a new evaluation, an evaluation to check and verify all of this is working. So, these are the five steps that we're going to follow today to set up MCP as well as the memory bank. So, for step one, I'll use this prompt. Switch the agent's deployment target to agent runtime and update the project configuration so it's ready to run on the agent platform. If you remember from the last episode, our agent is already running on the agent runtime. We can see that through the Google Cloud console. So, I'm using Google Cloud console within the agent platform. Head to the agent section and in the deployments, K8s investigator agent is running. Of course, I can start using it. I can start using it through the playground. I can use the different sessions of it, but let's wait for the deployment target to be switched to the agent runtime. As expected, the coding agent is making use of the agent CLI. It's looking at the skills that are configured to make this change. Looks good. So, the agent's deployment target is switched to agent runtime. And as we saw in the last episode as well, it used the agent CLI scaffold command to make this change. Further, it also made some changes to the infrastructure and the dependencies, which is also good. Now, for step two, I'll clear the screen and I'll use this prompt. Set up an MCP server in our GKE cluster, which is our managed production cluster, and configure the agent to use it. So that the agent running in the agent runtime can remotely inspect and troubleshoot our Kubernetes cluster. Now, trust me, if we have to do this manually, this would take a lot of time because we are making use of the agent CLI and our coding agent, this becomes relatively much easier now. I think as a first step, it will try to connect to the GKE cluster and probably run MCP server on it. If you remember, we created a Kubernetes cluster in the last episode. So, I'll just search for GKE to quickly show you. Kubernetes engine. I'll take this in a new tab. Clusters and this is a cluster that we created. K8s agent cluster. A very simple cluster with single node because we are not going to run a lot of workloads on top of it. If required, we can scale the Kubernetes cluster that wouldn't take a lot of time. Anyways, going back to see the progress. So, it is asking which MCP server implementation should be deployed to the GKE cluster. It figured out the cluster name. K8s agent cluster. The first approach, build and deploy a Python fast MCP server in this repo exposing our Kubernetes inspection and forensic tools. The list of the tools over streamable HTTP or the other one, deploy an off-the-shelf Kubernetes MCP server image in GKE and keep only log forensics in the ADK agent. Now, I think let's go with the first one which looks good. Then the follow-up question, how should the MCP server in GKE be exposed and authenticated for the agent runtime agent? This is very important. And few minutes back, I explained to you during the theory part as well, we will make use of the GKE load balancer service and that is the recommended option here. So, the recommended option, expose via GKE load balancer service for streamable HTTP. The other options include expose via GKE load balancer service with shared bearer token for authentication or expose via internal load balancer with private service connect network attachment for the agent runtime. We will go with the first option. Looks like it started reading the files and I think it started creating this file MCP server.py. Let's see. I'll go to the Visual Studio Code and you know quickly search for this file. MCP server.py. Yeah, there you go. So this is a newly created file and it started the implementation. And it also started exposing these tools. Get pod events, the five tools that we have, get deployment history. So we are going good. And in just few minutes, it created the complete MCP server.py. It also created the YAML manifest. And in fact it added the unit test cases so that it can test the created MCP tool. Now it started applying the MCP server.yaml to the GKE cluster. You know why? So that it can deploy the MCP server. Let's in fact go ahead and see the Kubernetes manifest file for this MCP server. So we will go back to the VS Code and just search for MCP server. We should find the relevant YAML file. There you go. And let's see what's in this. So first it's creating a namespace called K8s Investigator. Then it's creating a service account for the MCP server, which is good. Cluster role, cluster role binding. And then the deployment for the K8s MCP server. We can see it is associated with the same service account that it created above. It pushed the image to the registry. Now when this pod runs, it pulls this image. Good, it set the required image pull policy and also command to start. The resource and request on the pod, liveness probe and readiness probe configured. And here you can see it created a service. And as per the requirement, the MCP server service is configured as type load balancer. So this will be exposed. Basically the MCP server will be exposed as a GKE load balancer service type. Okay. Now it is running some tests. So I think the MCP server deployment is complete. Let's see. We will go to the Google Cloud console. Let me go to the workloads. Yeah, along with the agent. So, this is our agent K8s Investigator, which we deployed in the previous lesson. And this is the one, K8s MCP server. It's in the namespace K8s Investigator, and this is a managed pod exposing service K8s MCP server service, load balancer, and this is the endpoint. Perfect. So, we are done with MCP server setup. The service is also exposed, but still let's wait for the test to be passed. Looks like the test also passed. Verification and smoke test results, everything looks green. So, now what is the next step? The next step is to redeploy the agent and make sure agent can connect to this Kubernetes cluster using this MCP configuration. Because we made some code changes to the agent, we have to redeploy the agent. And that is exactly what it says here. Next step, deploy the updated agent to agent runtime. Would you like me to proceed with deploying the updated agent to the agent runtime using the agent CLI deploy? In fact, I was able to provide the same prompt. My prompt three was to redeploy the agent. So, instead of providing the prompt, I'll just say proceed. For beginners, I just want to repeat what we're exactly doing here. As part of MCP configuration, there are two steps. One is the client part, and the other is the server part. On the Kubernetes cluster, we deployed an MCP server. Now, when it comes to our agent, our agent should have a client that can talk to the MCP server. That is exactly what we're doing now. We updated the agent code. Now, we are redeploying the agent so that agent can communicate with the Kubernetes cluster. I hope that's clear. And going back, our coding agent is making use of the agent CLI deploy command. It's trying to prepare the command. Okay, I think it actually got the command as well. Agent CLI deploy, the deployment target followed by the project and the MCP server URL. This time it is also providing the MCP server URL. So, the deployment is going on. Once this is complete, we can run a simple test, but my guess is that the coding agent will anyways run a sample test to verify the connection. Let's see the log. In case if it doesn't run a sample test, probably deploying the pod or fetching the cluster information, we will go ahead and try one from our side. Okay, as expected, it deployed the agent. It also provided some live verification summary. That means it did perform the verification, but still let's try to do it from our end as well. How? We'll go back to the K8s investigator. Let's go to the playground. Okay, in one of our sessions, so I'll go with the default session. I'll just ask get the Kubernetes cluster node information. So, if the MCP configuration is perfect, what it should ideally do, now this agent, which is in the agent runtime, should talk to the Kubernetes cluster using the get node tools. You know, we use this one of these tools as part of the agent. So, it should make use of these tools and over the MCP, it has to fetch the node information. Yeah. So, it is using get node info. It's complete. Event ID, invocation ID. Kubernetes cluster node inspection. It says the total number of nodes are one. Ready node is one out of one. And this is the name of the node. Let's verify if it is correct. So, I'll go back and see the node name here. On the cluster, open the cluster configuration, look at the nodes. So, it ends with BM N2. I think it's the same one here. Yeah. So, the BM N2. Now, this confirms MCP configuration is successful. So, the part one is complete. Now, let's go to part two, enabling and configuring the memory bank. So this is a memory bank feature. Let me show you before enabling and configuring. There is no information here. Retrieved memory count is zero, generated memory is zero, memory LRO latency, and memory simulation. Basically, there is no data available here. So let's go back to the coding agent and try to implement this. I'll clear the screen and provide the prompt. Set up the agent platform memory bank, the one that we saw here, for the agent, so it automatically saves findings from each Kubernetes investigation and remembers the past incidents when troubleshooting the new issues. Let me show you the challenge that I was talking about, so that once we implement it, you can clearly see the difference. I'm connected to the Kubernetes cluster. Let me deploy a faulty pod. kubectl create deployment nginx {hyphen} {hyphen} image that doesn't exist. So obviously, when we try to get the pods, you will notice that the pod will go into image pull back off status because there is no image that exists or error image pull. Let's ask the agent here. So I'll take the first session and in the first session, I'll just ask it what is the issue with the nginx pod. I'll just provide the name of the pod. In the default namespace. Now because we configured MCP, so for the very first time, what is the expected approach? Now the agent should make use of this tool called get pod logs or get pod info and from there, it should identify the issue and provide us with the investigation report. That is the expected thing. Yeah, as expected, it is making use of the tools get deployment history, get pod logs, get pod events. And good, in probably less than a minute, we have the response back. Incident is image pull back of all good. Now, I'll take a new session. And here I would ask, "Do you remember issue with the specific pod?" I mean, the same pod. "Do you remember the issue with the nginx pod in the default namespace?" Let's see what happens. You can see, again it started performing the same steps. Even though in just the previous session, it got the required information, agent does not remember. This is a problem. There is no memory bank that is configured. Or agent does not remember anything from the previous instance. I hope this is clear. So, the memory bank configuration is done. The agent platform memory bank has been configured and wired into the Kubernetes investigator. So, the agent automatically saves findings from each Kubernetes investigation and recalls the past incidents across the sessions. In fact, it did a lot of changes. Many of these changes are related to the uh the code changes, agent-related code changes. For example, updating the memory config or creating the memory bank configuration along with context spec. In fact, it also added the tests, and the tests are also passing. But, we would need to redeploy the agent for this. Right? Because these are code changes. So, let's ask Antigravity, in your case if you're using a different coding agent, let's ask it to deploy these changes. So, it says, "Would you like to apply the memory bank to your agent instance that is already running and deploy the updated agent?" Yes. So, I'll just say, "Go ahead." So, it started the deployment. I've started deploying the updated K8s investigator agent. And it is using the agent CLI deploy command. So, probably in less than a minute or so, we should have the new agent deployed. And then we can go ahead and verify the memory bank configuration. Great. So, the deployment is also complete. Deployment and memory bank summary. So, we will repeat the same exercise. I'll go back to the Gemini Enterprise Agent platform. Deployments. I'll go to the agent and pick up a new session. So, this is the first session. Let's ask what is the issue with pod in default namespace. Again, for the first time, it is expected, you know, after our memory bank configuration. This is for the first time. So, it is expected it is fetching the deployment history. It is making use of the tools. And we know in just 30 seconds it would identify the issue and provide us with the detailed investigation report. We already know this. But, what we want to look at right now is once this investigation is done, would it save some information to the memory bank? Okay, the investigation is complete. It clearly explains issue is with respect to the image, image that doesn't exist. But, now if we go to the memory bank, so I'll open the memory bank in the new tab. We should see some memory stored. Amazing. We can see that here. From nil data, I can see some data related to the memory bank. And if I go to the agent and if I just go to the memories tab, I should see the investigation details stored. This is the one. So, it stored all the information. Let's do one final check. So, we'll go back to the agent one more time and I'll take a new session and I'll just ask, do you remember issue with the pod followed by the name of the pod in default namespace. Let's see, instead of performing the troubleshooting, will it fetch the information from the memory? And there you go. You can see here from step one, which is the prompt that we provided, directly in step two, without using the MCP tools, it was able to fetch the information. How? Of course, from the memory bank. So, this proves we implemented an agent that remembers the information or that remembers a conversation across different sessions using the memory bank on Gemini Enterprise Agent platform. Just a quick review. So, once we implemented memory bank, because the Nginx pod issue is something that agent already knows, it has that information stored in the memory, it responded back to us directly with the incident report. Whereas previously, it took multiple steps to respond and tell us what exactly is the issue. Great. Before we conclude the implementation, although this is not mandatory, let's ask our coding agent to make use of the agent CLI and implement an evaluation or a test scenario for the memory bank. Because this is a very critical feature for the agent, let's say in the future you enhance the agent or maybe you make a significant change to the agent, having a test scenario for this will be a good regression. So, I'll just say, create and run an evaluation to test that the agent actually uses its memory bank to recall past Kubernetes instance when troubleshooting a related recurring issue. We have a bunch of test scenarios already for this agent. This will be added as a new test scenario. And if you watched our previous evaluation video, you know how this works. Agent CLI, configure the skill with this coding agent, which is the eval skill. Using that eval skill, a new test scenario will be created. Nice. So, the evaluation is added and we can see a single scenario memory bank recall evaluation has completed and achieved perfect scores across the all the metrics. Of course, this is expected because we manually verified it. We implemented memory bank and we also verified it. This evaluation of the test scenario is only to make sure in future if you make any changes to the agent this will be part of the regression. Yeah so as per the grading as well, it's code five out of five for custom response quality for memory recall accuracy and also agent turn count. This is the agent output from the evaluation trace, which also looks good. So, this concludes our step five as well, evaluation for memory bank. Nice. I hope you found this video insightful. We learned how to set up MCP and also memory bank using simple natural language prompts. Once again if you also want to implement these videos practically you can use the link in the description and also in the pin comment. You can create an account with Google Cloud. For the very first sign up, you get up to $300 in free credits, using which you can use the Gemini Enterprise Agent platform. Thank you so much for watching today's video. In case you have any questions, do let me know in the comment section. I'm more than happy to help. See you all in the next video.
Assistir ao vídeo original no YouTube
Assuntos: Agentes de IA. Publicado no YouTube em 2026-10-20.
Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.
About Agent Platform Memory Bank
Memory Bank is a Gemini Enterprise Agent Platform service from Google Cloud that stores and retrieves information from conversations so agents can personalize interactions. According to Google Cloud documentation, it keeps long-term user preferences and facts, while the separate Sessions service stores the state of individual conversations between users and agents. Memory Bank uses generative AI models to generate memories from those interactions.
The documentation lists functions to generate memories, ingest events, use memory profiles, fetch generated and uploaded memories, inspect memory revisions and control access with IAM Conditions. Memory Bank supports VPC Service Controls, customer-managed encryption keys (CMEK), data residency at rest and HIPAA. The video description says this sixth episode of the series uses Gemini Enterprise Agent Platform and agents-cli to set up Memory Bank.
Fact sheet
- Service: Agent Platform Memory Bank
- Platform: Gemini Enterprise Agent Platform (Google Cloud)
- Purpose: Long-term memory of user preferences and facts for agents
- Related service: Agent Platform Sessions (conversation state)
- Security features: VPC Service Controls, CMEK, data residency at rest, HIPAA
- Documentation: Google Cloud – Scale your agents (Gemini Enterprise Agent Platform documentation)
Read also
- Can Google Gemini 4 Argon Do Your Job? AI Agents Explained
- AI Agents Finally Share One Memory (Claude Mem Explained)
- Agentic AI Course 2026 | Agentic AI Full Course for Beginners | LangChain, LangGraph & AutoGPT
Sources and references: Google Cloud – Scale your agents (Gemini Enterprise Agent Platform documentation) · YouTube description of the video by the Abhishek.Veeramalla channel.