Building a Simple Churn Agent

It’s Tuesday morning and Claire’s email is short and to the point: “Don’t over-engineer it.” She wants a quick proof-of-concept that the idea works on two dummy customers — one healthy, one at risk — and she explicitly asked not to hook this up to any real data yet. She wants to see it by Thursday. That request is a great example of delivering just enough to validate an idea. In this lesson we skip building a full data pipeline and focus on task one: build an agent that can reason about two fake accounts and explain why one is at risk.

A presentation slide titled "Task One — Build the Agent" showing an email-style note from "Claire · Customer Success" asking not to hook the system to real data and to test on two dummy customer accounts. To the right are icons for a blocked "Data Pipeline" and two dashed boxes labeled "Two Fake Accounts."

Overview

Create a tiny in-memory dataset (two accounts) to simulate a warehouse.
Expose a simple lookup function as a tool the agent can call.
Instantiate an LlmAgent with that tool and an instruction telling it how to reason about churn.
Drive the agent with a Runner and inspect the agent’s answer and the tool call it made.

Why this works

Tools in ADK are plain Python functions. The model inspects their names, signatures, and docstrings to decide when to call them.
Keep docstrings clear: they are the tool’s advertisement to the model.

Customer test dataset For the PoC we create two customers in a Python dictionary:

CUSTOMERS = {
    "C001": {"name": "Acme Corp", "logins_30d": 22, "tickets": 1},
    "C002": {"name": "Blipco",   "logins_30d":  1, "tickets": 6},
}

C001 (Acme Corp): healthy, 22 logins in 30 days and 1 support ticket.
C002 (Blipco): low activity, 1 login and 6 support tickets — likely churn risk.

Tool: a simple lookup function Tools are just Python functions. ADK uses the function name, type hints, and its docstring as the tool description the model can see. Make docstrings explicit so the model knows when to use a tool.

A clear docstring and correct type hints are critical. The model uses them to decide whether a tool is relevant and when to call it.

Example tool:

def get_customer(customer_id: str) -> dict:
    """Look up a customer's recent activity by ID."""
    return CUSTOMERS.get(customer_id)

Assembling the LLM agent An LlmAgent needs a name, a model wrapper, an instruction, and a list of tools. The model wrapper is the only line tied to a specific model implementation — swap it to change the underlying model.

import os
from google_adk import LlmAgent, LiteLlm, Runner  # example imports; adapt to your ADK package

# Example: set your KODEKEY gateway credentials in environment variables
os.environ["KODEKEY_BASE_URL"] = "https://your-kodekey-base.example"
os.environ["KODEKEY_API_KEY"] = "..."  # replace with your key

churn_agent = LlmAgent(
    name="churn_agent",
    model=LiteLlm(
        "your-model-identifier",  # replace with the model identifier your gateway expects
        api_base=os.environ["KODEKEY_BASE_URL"],
        api_key=os.environ["KODEKEY_API_KEY"],
    ),
    instruction="""
You help the customer success team spot churn risk.
Use get_customer to look up accounts by ID.
Few logins or many support tickets indicate higher risk.
Return a risk level (LOW / MEDIUM / HIGH), the evidence, and one retention action.
""",
    tools=[get_customer],  # pass the function itself, not its name
)

Quick reference: LlmAgent key arguments

Argument	Purpose	Example
`name`	Human-friendly agent identifier	`"churn_agent"`
`model`	Model wrapper used by ADK	`LiteLlm("your-model-identifier", api_base=..., api_key=...)`
`instruction`	High-level behavior spec the agent should follow	Multi-line string as shown above
`tools`	List of Python functions the model can call	`[get_customer]`

Run the agent and ask Claire’s question Use a Runner to drive a single-shot conversation:

# Runner drives the conversation with the LlmAgent
runner = Runner(agent=churn_agent)

response = runner.run("Is customer C002 at risk?")
print(response)  # human-readable agent output

Expected concise agent output (example):

Agent: Risk level: HIGH
 - Evidence: 1 login in the last 30 days
 - Evidence: 6 support tickets
 Recommendation: Reach out proactively to understand their issues and offer a dedicated support review.

What happened under the hood You never explicitly called get_customer in your code. The model inspected available tools (their names, type hints, and docstrings), determined that get_customer was relevant, and issued the call itself to retrieve evidence. Internal tool call the agent performed:

# Internal tool call performed by the agent
get_customer("C002")
# returns:
{"name": "Blipco", "logins_30d": 1, "tickets": 6}

Step-by-step scaffold (install and complete example) Follow these steps locally in a safe (non-production) environment. Install:

# pip install google-adk

Full minimal example:

import os
from google_adk import LlmAgent, LiteLlm, Runner

os.environ["KODEKEY_BASE_URL"] = "https://your-kodekey-base.example"
os.environ["KODEKEY_API_KEY"] = "..."

CUSTOMERS = {
    "C001": {"name": "Acme Corp", "logins_30d": 22, "tickets": 1},
    "C002": {"name": "Blipco",   "logins_30d":  1, "tickets": 6},
}

def get_customer(customer_id: str) -> dict:
    """Look up a customer's recent activity by ID."""
    return CUSTOMERS.get(customer_id)

churn_agent = LlmAgent(
    name="churn_agent",
    model=LiteLlm(
        "your-model-identifier",  # replace with the model identifier your gateway expects
        api_base=os.environ["KODEKEY_BASE_URL"],
        api_key=os.environ["KODEKEY_API_KEY"],
    ),
    instruction="""
You help the customer success team spot churn risk.
Use get_customer to look up accounts by ID.
Few logins or many support tickets indicate higher risk.
Return a risk level (LOW / MEDIUM / HIGH), the evidence, and one retention action.
""",
    tools=[get_customer],
)

runner = Runner(agent=churn_agent)
print(runner.run("Is customer C002 at risk?"))

Best practices and next steps

Start small: use fake data to validate reasoning before requesting access to production systems.
Make tool docstrings explicit and include types — the model relies on them.
Iterate on the agent’s instruction to refine output format (for example, require JSON output for programmatic parsing).
Add more tools (e.g., activity history, billing, NPS) to improve evidence quality.

Do not point this prototype at production data. Use isolated test data and credentials while validating behavior. Only request real data access after you’ve shown the team the PoC results.

Links and references

ADK / Agent SDK docs (replace with your ADK provider docs)
Python packaging and pip
For more design patterns on tool-oriented agents see: Tool-Using LLMs

Now you have a minimal but complete proof-of-concept: an agent that identifies Blipco as high risk, cites supporting evidence it fetched via a tool call, and recommends an action — all against two hand-written dummy accounts.

Building Agent With BigQuery

Building Agent With Databricks

Building Agent With Snowflake

Building a Simple Churn Agent

Watch Video

Practice Lab