Every agent that uses an MCP server needs the server’s URL. That seems harmless until the server moves to another region, gets redeployed under a new name or gets a separate staging copy. Then you have to update and redeploy every agent that has the URL hardcoded, and often nobody finds out until something breaks. With a few agents and a dozen servers, that one pasted URL becomes a real maintenance burden.
If you’re building agents with the Agent Developer Kit (ADK), you’ve probably realized that the standard request-response loop isn’t enough. Real-world agents need to enforce safety policies, log detailed metrics, and maintain state across turns.
To solve these challenges, ADK provides Callbacks. These are your hooks into the agent’s brain, allowing you to observe, intercept, and even rewrite execution flows on the fly. But with great power comes great responsibility—and a few ways to shoot yourself in the foot.
When we think of AI agents, we almost instinctively picture a chatbot: a user types a question, and the agent replies immediately.
This request/response model is great for direct human interaction, but it doesn’t fit every use case.
Real-world enterprise systems are often distinct, disparate, and disconnected.
They communicate through events—messages sent between systems to trigger actions asynchronously.
If you want your AI agent to automate complex orchestrations (like processing insurance claims, analyzing logs as they arrive, or summarizing documents uploaded to a bucket), you need to break out of the synchronous “chat” loop.
In this post, we’ll explore how to plug an AI agent into an event-driven architecture.
We will move beyond the standard API call and look at how to trigger a Python-based agent asynchronously using Google Cloud Pub/Sub and Eventarc.
This approach allows you to integrate AI into established interfaces without modifying them, effectively turning your agent into a silent, scalable background worker.
Agent Development Kit or ADK from Google is one of popular frameworks for developing AI applications. It provides a rich set of instruments for developers saving the development time and enabling the use of the industry’s best practices. One of such instruments is session management. It is used to maintain a state of the user’s session during interaction with agents. ADK provides several implementations of the session management tool to be used for development, for use with relative databases and for maintaining state using Vertex AI - a Google Cloud platform for AI applications and ML models. You can find a lot of information about session management with ADK. You can read documentation or to learn about managing state and memory. And there is more.
Hey there, fellow AI application builders. Ever feel like your AI assistants are a bit like magic? You whisper a command, and poof – things happen. From booking flights to drafting emails, these intelligent agents are becoming an indispensable part of our lives. And behind a lot of this magic, especially when it comes to connecting AI models to the real world, is something called the Model Context Protocol, or MCP.
Have you ever found yourself grappling with observability instrumentation, even with tools like OpenTelemetry? This challenge becomes even more pronounced when developing Agentic applications, where understanding internal workflows is paramount. There are many frameworks that help developers to create an Agentic application. I’d like to review what observability data is generated when developers use the Agent Development Kit (ADK) from Google. ADK framework comes with logging and tracing instrumentation out-of-the-box.
