Five Days, Endless Possibilities: here is the five day summary and a capstone project

This is a summary of what I learned in five day intensive course with google

Day 1: Agents in Introduction 💡

Key Concepts in Defining an ADK Agent

Defining an agent using the Agent class in ADK is crucial for determining its behavior and capabilities. The key properties are:

Property	Description	Example Value (from the notebook)
name	A simple, unique identifier for the agent.	"helpful_assistant"
model	The specific LLM that acts as the agent's "brain" for reasoning.	Gemini(model="gemini-2.5-flash-lite")
description	A short summary of the agent's purpose.	"A simple agent that can answer general questions."
instruction	The guiding system prompt that defines the agent's goal and how it should behave, including when to use its tools.	"You are a helpful assistant. Use Google Search for current info or if unsure."
tools	A list of external functions or capabilities the agent can use to interact with the world (e.g., search, run code, access databases).	[google_search]

I had hands-on introduction to building AI Agents using Google's Agent Development Kit (ADK). The core difference between a standard Large Language Model (LLM) and an ADK Agent is the agent's ability to reason, take actions (use tools), and observe results to deliver a superior final answer.

🛠️ Step-by-Step Agent Construction

The notebook guides you through the following practical steps to build and run your first agent:

• Setup and Authentication:
  • Install the ADK (google-adk).
  • Configure the Gemini API Key as a Kaggle User Secret for authentication.
• Define the Agent:
  • Import necessary components (Agent, Gemini, InMemoryRunner, Google Search).
  • Instantiate the Agent with the key properties (name, model, instruction, tools) to create a helpful_assistant that can use Google Search.
• Run the Agent:
  • Create an InMemoryRunner to orchestrate the agent's execution.
  • Use the .run_debug() method to send a prompt, observe the agent reason, and take action (by calling the Google Search tool) to answer a question requiring current information.
• ADK Web Interface:
  • Demonstrate setting up the optional ADK Web UI for interactive chatting, testing, and debugging the agent's detailed trace of thoughts and actions.

💡 Agent Core Principle

The main takeaway is the difference between a static LLM response and an Agentic Workflow:
LLM: Prompt to Text
Agent: Prompt to Thought to Action (Tool Use) to$ Observation to Final Answer
The agent's ability to use tools (like Google Search for real-time data) based on its instructions is the foundation of agent-based AI.

---

Day 2: Moving from Single Agent to Multi-Agent Systems 🤝

Day two focuses on escalating from single agents to collaborative Multi-Agent Systems (MAS), which are essential for solving complex problems. The key takeaway is that specialized agents working as a team are more reliable, maintainable, and powerful than a single "monolithic" agent trying to do everything.

🔑 Core Concepts in Multi-Agent Systems

1. The Need for Specialization
   • The Problem: A single, "Do-It-All" agent becomes unreliable, hard to debug, and difficult to maintain because its instruction prompt becomes too long and complex.
   • The Solution: Build a team of specialists (Multi-Agent System), where each agent has one clear, simple job (e.g., Research Agent, Summarizer Agent).
2. The Three Core Workflow Patterns ADK provides specialized agent classes to enforce predictable execution order, moving beyond reliance on the LLM's instructions.

Pattern	ADK Class	Use Case	Key Mechanism
LLM-Coordinated	Agent (as Coordinator)	Simple, small workflows where the LLM can reliably call sub-agents (wrapped in AgentTool) in order.	The coordinator agent's instruction prompt dictates the sequence of tool calls.
Sequential (Assembly Line)	SequentialAgent	Tasks that must happen in a guaranteed, specific order where the output of one agent is the input for the next (e.g., Outline to Write to Edit).	Runs sub-agents in the exact order they are listed in the sub_agents list.
Parallel (Concurrent)	ParallelAgent	Tasks that are independent of each other and can run simultaneously to save time (e.g., researching three different topics).	Executes all sub-agents concurrently. The combined results are then often passed to an Aggregator Agent.

⚙️ Key Implementation Details

• Agent Tooling and Data Flow
  • Sub-Agent as a Tool: In the LLM-Coordinated pattern, a sub-agent is wrapped using AgentTool(sub_agent) so the coordinator LLM can call it like any other tool (e.g., Google Search).
  • Data Passing (output_key): The output of an agent can be stored in the session state using the output_key parameter. This allows subsequent agents to access that output by referencing the key in their instruction prompt (e.g., {blog_outline} automatically injects the outline text).
• Workflow Examples
  • LLM-Coordinated: A single ResearchCoordinator Agent is instructed to call ResearchAgent first, then SummarizerAgent second.
  • Sequential: A SequentialAgent is created with sub_agents=[outline_agent, writer_agent, editor_agent], forcing the creation of a full blog post draft through a fixed pipeline.
  • Nested Parallel: A SequentialAgent is used to orchestrate a high-level plan: SequentialAgent runs a ParallelAgent (for concurrent research) first, and then runs a single AggregatorAgent second, ensuring all parallel results are available before summarization.
• LLM-Coordinated Workflow (Dynamic Routing) In this pattern, a standard Agent (the Coordinator) is instructed to call its sub-agents, which are wrapped as AgentTools, in a specific order. The LLM's reasoning controls the flow.

1. Sequential Workflow (Fixed Pipeline)
   The SequentialAgent enforces a guaranteed, step-by-step execution, like an assembly line. The output of one agent is automatically available to the next via the shared session state (output_key and placeholder injection).

2. Nested Parallel Workflow (Fan-Out/Gather)
   This is a powerful structure that uses a ParallelAgent to run independent tasks simultaneously, then uses a SequentialAgent to ensure the results are gathered and synthesized by an AggregatorAgent.

🔧 Tools, Delegation, and Reliability

Day 2 of the Agents course also focused on extending agent capabilities through the use of Agent Tools, which are necessary to connect the LLM to the external world, real-time data, and custom business logic.
The core concept is: Tools transform a static LLM into a dynamic agent that can take action.

🤔 Why Agents Need Tools

Without tools, an agent is limited by its training data (which is frozen in time) and cannot perform actions like accessing current news, company databases, or executing calculations reliably. Tools solve this by providing the agent with connections to the outside world.

🔧 Building Custom Tools

The ADK allows you to turn any standard Python function into a callable tool, known as a Function Tool.

• Key Tool Best Practices:
  • Clear Docstrings: The LLM uses the docstring to understand the tool's purpose and when to call it.
  • Type Hints: Essential for ADK to automatically generate a proper schema (inputs and output types).
  • Structured Returns: Tools should return dictionaries with explicit "status" (e.g., "success" or "error") and the data or error message.
• Example: Function Tools The notebook given demonstrated building two Function Tools for a Currency Converter Agent:
  • get_fee_for_payment_method(method: str) -> dict: Retrieves a mock transaction fee.
  • get_exchange_rate(base: str, target: str) -> dict: Retrieves a mock currency rate.

💡 Advanced Reliability: Agent as a Tool

To solve the issue of LLMs making errors with complex math, the notebook introduces using a specialized agent as a tool an AgentTool.

1. The Specialist Agent (CalculationAgent)
   • Defined with the specific instruction to ONLY output Python code for a calculation.
   • Equipped with a BuiltInCodeExecutor() (a built-in tool) to run the generated code in a safe sandbox, guaranteeing arithmetic accuracy.
2. Delegation via AgentTool
   • The primary enhanced_currency_agent adds the specialist agent to its toolset: tools=[..., AgentTool(agent=calculation_agent)].
   • The primary agent's instructions are updated to strictly prohibit it from doing the math itself and require it to delegate the calculation to the calculation_agent tool.
3. Agent Tools vs. Sub-Agents:
   • Agent Tool (Delegation): Agent A calls Agent B as a tool, gets the result, and Agent A remains in control of the conversation. (Used for tasks like calculation).
   • Sub-Agent (Handoff): Agent A transfers control completely to Agent B, which takes over the conversation flow. (Used for handoffs like customer support tiers).

🧰 Complete Guide to ADK Tool Types

ADK tools are categorized into two main groups, offering flexible ways to connect agents to external systems:

1. Custom Tools (Tools You Build)
   • Function Tools: Convert simple Python functions (like get_exchange_rate) into callable tools.
   • Agent Tools: Use a specialist agent (like calculation_agent) as a tool inside a larger system.
   • Long Running Function Tools: For operations that take significant time (e.g., human-in-the-loop approvals).
   • OpenAPI Tools: Automatically generate tools from existing REST API specifications.
   • MCP Tools: Connect to services compatible with the Model Context Protocol.
2. Built-in Tools (Pre-built by ADK/Gemini)
   • Gemini Tools: Leverage the model's core capabilities, such as Google Search and BuiltInCodeExecutor.
   • Google Cloud Tools: Integrations for enterprise services like BigQuery and Spanner.
   • Third-party Tools: Wrappers for external tool ecosystems (e.g., Hugging Face, GitHub).

Tool Type	Code Reference	Function
Function Tool	get_exchange_rate	Fetches data (currency rates) using custom, internal business logic (Python function).
Function Tool	get_fee_for_payment_method	Fetches data (fee percentage) using custom logic.
Agent Tool	AgentTool(agent=calculation_agent)	Handles the action of generating and running complex calculations, ensuring 100% arithmetic reliability through code execution.

---

Day 3: Long-Running Operations & Memory Management 🫡

Here we covered advanced Agent Development Kit (ADK) patterns for connecting agents to external services and handling Long-Running Operations (LROs) that require pausing and resuming the workflow, often for human input.

🧰 Section 1: Model Context Protocol (MCP)

MCP is an open standard that enables agents to consume community-built, standardized tool integrations without needing custom API client code. It acts as a bridge between your agent (the MCP Client) and external services (the MCP Server).

• Key Takeaways:
  • Purpose: To access live, external data from APIs and services (like GitHub, Slack, databases) using a standardized interface.
  • Integration: You use the McpToolset to configure the connection parameters (e.g., using npx to run an MCP server).
  • Advantage: Agents get instant access to powerful, complex tools, such as image generation or querying Kaggle datasets, without writing any integration code.

🔄 Section 2: Long-Running Operations (LROs)

LROs are used when an agent action needs to pause, wait for external input (like human approval), and then resume to complete the task. This is critical for high-stakes or irreversible actions (e.g., financial transactions, bulk deletions).

Component	Role	Mechanism
Pausable Tool	The custom Python function (place_shipping_order) that requires human input.	Checks the tool_context: ToolContext parameter. If no decision exists, it calls tool_context.request_confirmation() to pause.
Resumable App	The persistence layer that saves the agent's state when paused.	The agent is wrapped in an App with ResumabilityConfig(is_resumable=True). This saves the entire session context.
Workflow Handler	Your orchestrating code that manages the pause/resume cycle.	Detects the special adk_request_confirmation event, waits for human input (simulated by auto_approve), and sends the decision back to the agent.
Resumption Key	The identifier that allows ADK to continue the paused workflow.	The workflow must pass the original invocation_id back to the runner when resuming, ensuring the agent loads the correct saved state.

• LRO Workflow Steps (Pause/Resume Cycle):
  1. Initial Call: The agent calls the pausable tool (place_shipping_order).
  2. Pause: The tool executes request_confirmation(), which signals ADK to pause the agent's execution. The tool returns a status: pending message.
  3. Event Creation: ADK generates the adk_request_confirmation event, containing the necessary invocation_id and approval_id.
  4. Detection: The external workflow code checks the events for the adk_request_confirmation signal.
  5. Decision & Resume: The workflow formats the human's decision (e.g., "confirmed: true") into a FunctionResponse and calls the runner again using the original invocation_id. This causes the agent to resume exactly where it left off, allowing the tool to finish its operation based on the decision.

🧠 Section 3: Memory Management - Sessions (Short-Term Memory)

"🚀 Memory Management - Part 1 - Sessions," is Day 3 of the Kaggle Agents course, focusing on implementing short-term memory in agentic applications using the Google Agent Development Kit (ADK).
The core theme is managing sessions to create stateful agents that remember past interactions, overcoming the inherent statelessness of raw Large Language Models (LLMs).

• 🔑 Key Concepts and Objectives

  • Sessions: A container for a continuous conversation, encapsulating Events (user messages, agent responses, tool calls) and State (is like a scratchpad). A session is private to a specific user and agent.
  • Analogy: Session - Notebook; Events - Entries; SessionService -Filing Cabinet; Runner - Assistant.
  • Stateful Agents: An agent that maintains conversation context across multiple turns, enabling meaningful, multi-turn dialogue (e.g., remembering a user's name).
  • Session Management Components (ADK):
    • SessionService: The storage layer for session data (Events and State).
    • Runner: The orchestration layer that manages the flow, automatically maintaining history, and handling Context Engineering (i.e., making sure the LLM sees the history).

• 🧑‍💻 Implementing Session Management

  1. Temporary Sessions (InMemorySessionService)
     • How it works: Session history is stored in RAM. The agent successfully remembers information (like the user's name) within a single run.
     • Limitation: The conversation history is not persistent; it's lost once the application (or notebook kernel) stops.
  2. Persistent Sessions (DatabaseSessionService)
     • To achieve real-world persistence, the solution is upgraded to DatabaseSessionService, using SQLite in the demo (sqlite:///my_agent_data.db).
     • Advantage: The session data survives application restarts. The demo proves this by restarting the kernel and having the agent correctly recall information from the previous run using the same session ID.
     • Session Isolation: The notebook verifies that sessions are isolated; a new session ID starts a fresh conversation, and the agent does not retain context from a different session.

• 🧠 Context Compaction for Efficiency

  • The Problem: Storing every user query and model response (Events) in full can lead to very large session histories, resulting in slower performance and higher LLM costs over long conversations.
  • The Solution: Context Compaction uses an LLM to automatically summarize (or compact) older parts of the conversation history into a smaller, equivalent summary message, reducing the total token count sent to the model for subsequent turns.
  • Implementation:
    • It's enabled on the App object via EventsCompactionConfig.
    • compaction_interval: Defines how many turns should pass before compaction is triggered (e.g., 3 turns).
    • overlap_size: Defines how many recent turns should be kept in full alongside the new summary for continuity (e.g., 1 turn).

• 📚 Summary of Learnings
  Day 3 was a successful guide from building a simple, temporary stateful agent to a robust, persistent one, culminating in an optimized agent that uses Context Compaction to manage the cost and latency of long conversations. The key is understanding and correctly implementing the Session and SessionService components provided by the Agent Development Kit

Tool Type	Code Reference	Function
In-Memory	InMemorySessionService()	Used for local development and testing. Data is not persistent and is lost when the application stops.
Database	DatabaseSessionService(connection_string=...)	Used for production environments where conversation history and state must persist across application restarts.
Vertex AI	VertexAiSessionService(...)	Used for high-scale production on Google Cloud Platform, leveraging managed services.

---

Day 4: Ingest and Long-Term Memory (LTM) 💾

Day 4 was on transferring conversation history from the temporary Session into the long-term MemoryService using the key method:

await memory_service.add_session_to_memory(session)

1. Ingestion Methods
   • Manual Ingestion: Done explicitly in the code after a session.
   • Automatic Ingestion (Production): Implemented using ADK's after_agent_callback function, which triggers and saves the session data immediately after every agent turn.
2. Retrieve and Use 🔎 Agents need specific Tools to access the MemoryService. Retrieval makes the long-term knowledge available as context for the current LLM call.

Tool Name	Pattern	Behavior	Use Case
load_memory	Reactive	Agent decides when to search memory based on the user prompt.	More token-efficient.
preload_memory	Proactive	Automatically searches memory before every agent turn.	Guarantees context availability.

🧠 Memory Consolidation (Scaling)

The main challenge with raw memory storage is that it quickly becomes verbose, storing every message verbatim (e.g., 50 raw messages).
Memory Consolidation is the solution:

• It uses an LLM to analyze raw session events.
• It extracts only important, concise facts (e.g., "User's favorite color: BlueGreen") while discarding conversational noise.
• This results in less storage, faster retrieval, and more accurate answers. Key Point: Managed services like VertexAiMemoryBankService handle consolidation and semantic search automatically behind the same API calls (add_session_to_memory and search_memory).

🔎 Agent Observability: Logs, Traces & Metrics

This notebook, part of the Kaggle 5-day Agents course, focuses on Agent Observability, which is crucial for debugging and evaluating AI agents that can fail in "mysterious" ways. Observability provides complete visibility into an agent's decision-making process, including LLM prompts, tool usage, and failure points.
The three foundational pillars of Agent Observability are:

• Logs: A record of a single event (what happened at a specific moment).
• Traces: A connection of logs into a sequence (why a result occurred by showing the full chain of steps).
• Metrics: Summary numbers (how well the agent is performing overall, e.g., error rates, averages).

The hands-on practice uses the ADK (Agent Development Kit) Web UI and LoggingPlugin to achieve observability.

🛠️ Debugging with ADK Web UI (Logs & Traces)

The primary method for interactive debugging is using the ADK Web UI with a high log level.

• Core Debugging Pattern:
  • Symptom: The agent returns an unexpected result (e.g., an incorrect count).
  • Logs/Traces: Use the ADK Web UI's Events tab and Trace view to follow the agent's execution path (logs) and timing (traces).
  • Root Cause: Inspect the detailed logs (especially function_call inputs and outputs) to pinpoint the failure (e.g., an incorrect data type being passed to a tool).
  • Fix: Correct the code based on the root cause found. > In the provided example, the bug was the root_agent passing the list of papers to the count_papers tool as a single str instead of a List[str], leading to an incorrect count.

🧑‍💻 Logging in Production (Plugins)

For automated systems and production environments where the Web UI is unavailable, observability data is captured using Plugins and Callbacks.

• Plugins: Custom code modules that run automatically at various stages of an agent's lifecycle (e.g., for logging, monitoring, security).
• Callbacks: Atomic Python functions inside a Plugin that act as "hooks" to interrupt the agent's flow at specific points (e.g., before_agent_callback, after_tool_callback, on_model_error_callback).
• ADK provides a built-in solution: the LoggingPlugin, which automatically captures all standard agent activity (messages, timing, LLM requests/responses, tool calls, complete execution traces). > Summarized Production Logging Code > The LoggingPlugin is registered once on the InMemoryRunner (or other Runners) and applies logging across all agents it manages. > The output confirms the LoggingPlugin logs all critical steps: USER MESSAGE RECEIVED, INVOCATION STARTING, LLM REQUEST/RESPONSE, TOOL STARTING/COMPLETED, and AGENT COMPLETED.

🧭 Agent Evaluation

This notebook focuses on Agent Evaluation, which complements observability by providing a proactive approach to measuring and maintaining the quality of AI agents. Since agents are non-deterministic and respond to unpredictable commands, standard "happy path" software testing is insufficient.
Agent evaluation systematically tests an agent's performance across scenarios and quality dimensions, assessing its entire decision-making process (trajectory), not just the final output.

• Core Concepts of Agent Evaluation Agent Evaluation is the systematic process of testing and measuring an AI agent's performance, allowing you to catch quality degradations before they impact users.
  • Agent Differences from Traditional Software:
    • Non-deterministic: The same input can yield slightly different outputs.
    • Unpredictable Commands: Users give ambiguous or novel inputs.
    • Behavioral Shifts: Small changes to the prompt or model can dramatically alter behavior.
  • Key Evaluation Scores

Metric	Focus	Description
Response Match Score	Final Response	Measures the text similarity between the agent's actual final response and the expected response (1.0 = perfect match).
Tool Trajectory Score	Decision Path	Measures if the agent used the correct sequence of tools with the correct parameters (1.0 = perfect tool usage).

• 🛠️ Interactive Evaluation with ADK Web UI The ADK Web UI facilitates the creation and execution of initial test cases by allowing you to save live chat sessions as evaluation data.

• 📝 Evaluation File Structure
  To scale evaluation beyond the single-session chat, ADK uses structured files to define tests:

  • *.test.json: Defines the expected behavior for a test case (the "ground truth"). This includes the expected final response and the expected tool call trajectory.
  • *.evalset.json: A file that groups multiple test cases (from one or more *.test.json files) into a logical set for batch execution.
  • test_config.json: (Implied/part of setup) Defines the metrics and models to be used for the evaluation run.

• 📈 Systematic Evaluation for Regression Testing
  While the Web UI is good for interactive creation, Systematic Evaluation is needed for regression testing (ensuring new changes haven't broken old functionality) and batch testing in a CI/CD pipeline.
  ADK supports systematic evaluation using the adk eval CLI command (and also integrates with pytest).

• 📦 Overall Evaluation Process

  1. Create Evaluation Configuration: Define the metrics and models.
  2. Create Test Set and Ground Truth: Define inputs and expected outputs/trajectories (using *.test.json and *.evalset.json).
  3. Run Evaluation: Execute the tests using the !adk eval command.
  4. Analyze Report: Review the results to detect regression (a decrease in performance over time). The systematic approach allows for proactive quality checks, moving beyond single, interactive chats to scalable, reproducible performance measurement.

---

Day 5: Agent2Agent Communication & Deployment 🚀

🤝 Agent2Agent (A2A) Communication with ADK: Insightful Summary

Day 5 was a practical guide to building multi-agent systems using the Agent2Agent (A2A) Protocol within the Agent Development Kit (ADK). The core objective is to demonstrate how specialized agents, potentially running on different systems, languages, or organizations, can communicate and collaborate by treating each other as remote services or tools.

Factor	Use A2A	Use Local Sub-Agents
Agent Location	External service, different codebase	Same codebase, internal
Ownership	Different team/organization	Your team
Network	Agents on different machines (with network latency)	Same process/machine (low latency)
Language/Framework	Cross-language/framework needed	Same language
Contract	Formal API contract required (Agent Card)	Internal interface

The A2A Protocol is the standard for network-based, cross-boundary agent communication, relying on a machine-readable Agent Card to formalize the capabilities (skills/tools) of the exposed agent.

🏗️ Architecture Demonstrated: Product Catalog Integration

The tutorial simulates an e-commerce integration where a Customer Support Agent (Consumer) relies on a Product Catalog Agent (Vendor) via A2A communication.

• Components:
  • Product Catalog Agent (Vendor/Server):
    • An LlmAgent specialized in looking up product data using a local Python tool (get_product_info).
    • Exposed via A2A using .to_a2a(), which wraps the agent in an A2A-compatible FastAPI/Starlette server and auto-generates the necessary Agent Card at the standard path: http://localhost:8001/.well-known/agent-card.json.
  • Customer Support Agent (Consumer/Client):
    • An LlmAgent with instructions to help customers with product inquiries.
    • Consumes the remote agent using RemoteA2aAgent. This acts as a client-side proxy, using the remote agent's URL to retrieve its Agent Card and translate internal sub-agent calls into external A2A protocol requests (HTTP POST to /tasks).
    • The RemoteA2aAgent is added to the consumer agent as a sub_agent.
• ⚙️ Necessary Code Support The core of the A2A communication is achieved through three main ADK classes and functions:
  1. Defining and Exposing the Remote Agent (to_a2a)
  2. Consuming the Remote Agent (RemoteA2aAgent)
  3. Testing Communication (Runner) The successful execution demonstrates that the Customer Support Agent can transparently access the remote service, making the A2A protocol an essential tool for cross-boundary agent collaboration.

🚀 Deploy ADK Agent to Vertex AI Agent Engine: Summary

Here the course covered the critical final step in the agent lifecycle: deploying a production-ready agent built with the Agent Development Kit (ADK) to a managed cloud environment, specifically Vertex AI Agent Engine.
The goal is to take an agent out of the development notebook and make it publicly available and scalable.

🎯 Key Deployment Steps

1. Agent Preparation (Packaging) A dedicated sample_agent directory is created containing: | File | Purpose | Key Settings | | :--- | :--- | :--- | | agent.py | Agent logic and tools | Defines the weather_assistant with a get_weather tool and uses the gemini-2.5-flash-lite model. | | requirements.txt | Python dependencies | Specifies google-adk and opentelemetry-instrumentation-google-genai. | | .env | Environment configuration | Sets GOOGLE_GENAI_USE_VERTEXAI=1 to use the Vertex AI backend for ADK. | | .agent_engine_config.json | Deployment/Resource configuration | Sets resource limits and auto-scaling: min_instances: 0 (for cost savings) and max_instances: 1. |

2. Deployment Command
   The deployment is executed using the ADK CLI:
   

   !adk deploy agent_engine --project=$PROJECT_ID --region=$deployed_region sample_agent --agent_engine_config_file=sample_agent/.agent_engine_config.json
   

* adk deploy agent_engine: Targets the Vertex AI Agent Engine platform.



--project / --region: Specifies the Google Cloud project and geographical region for deployment.

🤖 Testing the Deployed Agent

The output stream confirms the successful execution flow on the managed service:

• Function Call: The agent decides to call the get_weather tool.
• Function Response: The tool executes and returns the mock weather data.
• Final Response: The agent generates the final natural language answer based on the tool result.

🧠 Long-Term Memory with Vertex AI Memory Bank

Feature	Session Memory	Memory Bank
Duration	Single conversation	All conversations (permanent)
Purpose	Immediate context recall	Storing user preferences, facts

• To enable Memory Bank, developers must:
  • Add memory tools (e.g., PreloadMemoryTool) to the ADK agent code.
  • Add a callback to save conversations to the Memory Bank.
  • Redeploy the agent with the updated code.

Cleanup and Best Practices

• Cost Management: Use min_instances: 0 in configuration and clean up test resources promptly.
• Monitoring: Monitor agent performance via the Vertex AI Console.
• Debugging: Enable tracing (enable_tracing=True) for complex deployments. This course culminates in providing the full lifecycle knowledge: Build (ADK) - Test (Tools/Memory) - Deploy (Agent Engine).

---

Capstone Project: Mobile-Money Intelligence 🥳

🚀 Building the Future of Mobile-Money Intelligence with Google ADK

How I Used Agentic AI to Unlock Smart Lending, Real-Time Insights & Secure Financial Analysis

Across Africa especially in Kenya mobile money is the heartbeat of the economy. Platforms like M-Pesa handle millions of transactions daily, becoming the new source of truth for personal finance, SME activity, and cash-flow behavior.
Yet most financial institutions cannot directly translate this data into insights. SMEs don’t have analysts. Micro-lenders lack reliable borrower signals. And users themselves rarely understand their own financial patterns.
My capstone project explores a solution:
👉 A remote AI agent system built using Google’s Agent Development Kit (ADK) that allows mobile-money providers to safely expose financial insights to banks, lenders, and SMEs all while preserving security, privacy, and user authorization.

🌍 The Vision

To enable a future where:

• Borrowers can share verified financial patterns directly from their mobile-money wallet.
• SMEs can access automated financial insights just like large corporations with full analytics teams.
• Financial institutions can make faster, smarter, data-driven lending decisions.
• Mobile-money providers like M-Pesa can expose their data through a secure, resumable, AI-driven agent API.

This project demonstrates exactly how that can be built using ADK’s agentic architecture.

---

🧠 What I Built

Using the concepts from the Google ADK intensive course, I created a multi-agent financial analysis system capable of:

• ✅ 1. Collecting mobile money statements: The system connects to a mock provider API (simulating M-Pesa-like data).
• ✅ 2. Analyzing spending, cash flow & loan-worthiness: Using specialized reasoning agents that handle:
  • income detection
  • expense clustering
  • cash-flow volatility
  • loan affordability
  • repayment patterns
• ✅ 3. Running securely with Pausable Tools: A remote agent cannot access user data until the user explicitly authorizes the request. This mirrors real-world compliance and privacy standards.
• ✅ 4. Supporting third-party institutions: A bank or lender can call the remote analyzer agent using A2A protocol just like consuming a normal API—except it’s powered by intelligent, chain-of-thought reasoning.
• ✅ 5. Providing SME insights: Just as large companies hire analysts, SMEs get access to:
  • weekly transaction summaries
  • inventory cash-flow patterns
  • seasonality detection
  • profit trend analysis
• ✅ 6. Producing lender-ready reports: The final output is a structured insight report used for underwriting or advisory.

---

🔧 How It Works (Agentic Architecture)

Your system is not a single monolithic agent. It uses ADK's full ecosystem:

• 🟦 Specialized Agents
  • Data Ingestion Agent — gathers and cleans raw mobile money transactions
  • Cashflow Agent — computes income/expense streams
  • Risk Agent — identifies patterns relevant to loan decisions
  • SME Insights Agent — summarizes business performance
  • Reporting Agent — generates final lender-grade output
• 🟩 Tools & Functions Custom tools allow the agent to:
  • compute KPIs
  • run safe calculations
  • fetch statements
  • categorize transactions
  • score risk
• 🟧 Pausable Tools for Secure Access Modeled after real-world compliance:
  1. agent asks: “User X requests financial analysis. Proceed?”
  2. session pauses
  3. user confirms
  4. execution resumes This is ideal for regulated data access (banking, telecoms, health, etc.).
• 🟨 Long-Term & Short-Term Memory
  • session memory for ongoing tasks
  • long-term memory for recognized SMEs, recurring customers, or historical loan behaviour
• 🟪 Observability & Evaluation Using ADK logging and evaluation tools, I ensured:
  • correct tool usage
  • predictable workflows
  • minimized hallucination
  • consistent analysis outputs
• 🟫 A2A: Multi-organization Integration The mobile provider and financial institution communicate through Agent-to-Agent (A2A) Protocol. Banks consume the Analyzer Agent just like a traditional API — but the intelligence remains inside the mobile-money provider’s infrastructure.

---

🏦 Why This Matters

• ✔ For Mobile-Money Providers M-Pesa-like platforms can monetize data intelligence safely without exposing raw transactions.
• ✔ For Banks & Lenders They gain deeper borrower insights:
  • cashflow stability
  • spending risk indicators
  • repayment predictions
• ✔ For SMEs They receive analytics that were previously only accessible to enterprises with full finance teams.
• ✔ For Users They stay in control of their financial data with explicit authorization.

---

🚀 The Impact

This project demonstrates how AI Agents can reshape finance in emerging markets by:

• enabling smarter lending
• promoting financial inclusion
• supporting SMEs with data-driven intelligence
• strengthening security and user control
• turning mobile-money data into a national economic advantage

---

📝 Final Thoughts

This capstone project is not just an academic demonstration — it’s a blueprint for the future of financial intelligence in mobile-money ecosystems.

By combining:

• agentic workflows
• multi-agent specialization
• secure authorization
• long-running operations
• A2A communication
• memory & evaluation
• cloud deployment

…we can build the next era of distributed financial intelligence that works for everyone.

Comments

[Engineer Wanga]

feel free to comment