> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Are We building

> Designing an agent that uses a reasoning model, plain instructions, and discoverable tools to fetch and join customer data across BigQuery Databricks and Snowflake to assess churn risk

Okay — it's still Monday morning, Claire's email is open in the next tab, and three tasks stand between you and a reply. Let's walk through them and design an agent that can fetch the facts Claire needs.

![A diagram titled "Three Tasks" showing a user icon on the left and an envelope labeled "A Reply" on the right. Between them are three connected task boxes (each with curly-brace symbols) inside a rounded container, linked by arrows.](https://mintcdn.com/kodekloud-c4ac6d9a/YiW0Xl5gQ25uff6L/images/AI-Agents-For-Data-Analytics/Building-Agent-With-BigQuery/What-Are-We-building/three-tasks-user-reply-flow.jpg?fit=max\&auto=format\&n=YiW0Xl5gQ25uff6L\&q=85\&s=76c56c605e4a58e8c6b0748b4fb4ac28)

## Task 1 — What is an agent?

An agent is not a single monolithic program. Conceptually it’s the composition of three simple, cooperating blocks:

* A reasoning model that reads and composes answers.
* Plain‑English instructions that tell the model what to do.
* Tools the model can call to retrieve facts or run queries.

For the reasoning model in this example we’ll use Claude by Anthropic — the model does the reading, pattern recognition, and answer composition; you provide it as plain text.

The instruction block is likewise simple and human-readable. For instance:

* Help a customer success team spot churn risk.
* Few logins or many support tickets → high risk.
* Provide a risk level and suggest one retention action.

That is all the instruction the agent needs. The model and instruction tell the agent how to behave; they don’t contain facts about specific customers. Every fact the agent will ever use must arrive via the tools.

To make this concrete, here’s a compact view of the three components:

| Component | Purpose | Example |
| - | - | - |
| Model | Reasoning and composition | Claude by Anthropic — `text` I/O |
| Instructions | Goals and heuristics in plain English | “Label churn risk and suggest an action” |
| Tools | Callable functions that return facts | Warehouse queries, feature lookups |

## Task 2 — The empty tools block

When the agent has model + instruction but no tools, it can’t fetch facts about a specific customer — the tools block is empty.

![A dark-themed flow diagram titled "Task Two – The Empty Block" showing a user icon on the left, an agent box (robot icon) connected to a server icon and a dashed empty JSON block, and an envelope reply icon on the right. It illustrates message flow from "You" through "The Agent" to "A Reply."](https://mintcdn.com/kodekloud-c4ac6d9a/YiW0Xl5gQ25uff6L/images/AI-Agents-For-Data-Analytics/Building-Agent-With-BigQuery/What-Are-We-building/empty-block-agent-reply-flow.jpg?fit=max\&auto=format\&n=YiW0Xl5gQ25uff6L\&q=85\&s=03404a00b82ebcb198f43342165188b6)

A tool is simply a callable function the model can invoke to retrieve facts. A common but fragile pattern is to hand-write one function per question or per warehouse. For example:

```python theme={null}
def get_customer(customer_id):
    return query(
        "SELECT … FROM customers WHERE id = ?",
        (customer_id,)
    )

def who_to_call_urgently():
    return query(
        "SELECT … FROM customers ORDER BY risk DESC"
    )
```

This works, but it doesn’t scale. One-off functions proliferate as new questions and new warehouses appear.

![A diagram titled "A Tool Is a Function" showing three icons: a brain labeled "The Model" on the left, a wrench labeled "A Function" in the center, and a person labeled "You" on the right. Arrows connect the model and user to the central function, indicating interaction through the tool.](https://mintlify.s3.us-west-1.amazonaws.com/kodekloud-c4ac6d9a/images/AI-Agents-For-Data-Analytics/Building-Agent-With-BigQuery/model-function-user-diagram.jpg)

The better approach is to publish tools from a server using a common discovery protocol so any agent that speaks the protocol can discover and call them. With this pattern:

* Tools are defined and documented once on the server.
* Agents pick up available tools dynamically.
* You avoid maintaining one function per question per warehouse.

Publish tools (function definitions + endpoints) from a lightweight server so agents can discover and call them dynamically. This reduces maintenance and enables multiple agents to reuse the same, well-documented functions.

This open pattern is often implemented with a discovery protocol (for example, an MCP-like interface) where the server publishes tool metadata (names, signatures, docs, endpoints) and agents call the selected tool at runtime.

![A dark infographic titled "A Function We Didn't Write" showing a central "Agent" icon linked to three blocks labeled "Model," "Instruction," and "Tools." An "MCP Server" (Model Context Protocol) icon appears to the right, connected to the system.](https://mintcdn.com/kodekloud-c4ac6d9a/YiW0Xl5gQ25uff6L/images/AI-Agents-For-Data-Analytics/Building-Agent-With-BigQuery/What-Are-We-building/function-we-didnt-write-agent-mcp.jpg?fit=max\&auto=format\&n=YiW0Xl5gQ25uff6L\&q=85\&s=c3bb46bfcb265016da0ff99308886488)

Avoid the combinatorial explosion of one-off functions. If you find yourself writing a new function for every slight variant of a query or for each warehouse, move to a discoverable tool architecture.

## Task 3 — Go get the data

Now the surprise: Claire’s question about logins, tickets, and billing cannot be answered from a single warehouse. In larger organizations customer data is split across systems:

* Product analytics (logins, feature usage, account age) often lives in BigQuery.
* Support tickets (text history, sentiment, urgency) may live in Databricks.
* Billing and contracts (monthly payment, contract type, contract\_end\_date) might live in Snowflake.

![A presentation slide titled "Task Three — The Data" showing BigQuery and Databricks icons, a dashed dollar-sign box, and three bullet points about monthly payment, contract, and contract expiry. The slide has a dark teal background and a small "© Copyright KodeKloud" note at the bottom.](https://mintcdn.com/kodekloud-c4ac6d9a/YiW0Xl5gQ25uff6L/images/AI-Agents-For-Data-Analytics/Building-Agent-With-BigQuery/What-Are-We-building/task-three-data-bigquery-databricks-payments.jpg?fit=max\&auto=format\&n=YiW0Xl5gQ25uff6L\&q=85\&s=1df95d85fb6616820fce34f5301f9159)

A useful quick mapping:

| Warehouse | Typical data | Use for |
| -: | - | - |
| BigQuery | Logins, feature usage, account age | Behavioral signals |
| Databricks | Ticket text, sentiment, time-to-close | Customer feedback & urgency |
| Snowflake | Billing, contract metadata, renewals | Commercial facts (renewals, payments) |

For example, Claire’s “12 renewals this quarter” is simply a count of contracts with a particular `contract_end_date`:

`contract_end_date -> those 12`

The three warehouses contribute different layers of the same customer story. Crucially, they share the same customer ID key (e.g., `cus-0003115`) so you can join them into a single profile and compute features like churn risk.

Rather than writing bespoke functions per question and per warehouse, publish a set of discoverable tools (or a lightweight adapter layer) so the agent can call meaningful, well-documented functions. Example server-published tools might look like:

```python theme={null}
# Example: tools published by an MCP server (these are provided, not hand-written per question)
def churn_score_databricks(customer_id):
    return query(
        "SELECT churn_score FROM features WHERE id = ?",
        (customer_id,)
    )

def churn_score_snowflake(customer_id):
    return query(
        "SELECT churn_score FROM features WHERE id = ?",
        (customer_id,)
    )

def get_support_tickets_databricks(customer_id, days=90):
    return query(
        "SELECT * FROM tickets WHERE customer_id = ? AND created_at >= DATE_SUB(CURRENT_DATE(), INTERVAL ? DAY)",
        (customer_id, days)
    )
```

Because the tools are published and discoverable:

* The agent chooses which tool(s) to call based on the question.
* You avoid duplicating queries across agents and use cases.
* The agent combines model reasoning, instructions, and returned facts to produce a concise, factual reply to Claire.

## Summary

* An agent = model + instructions + tools.
* Tools should be discoverable and server-published to avoid one-off function proliferation.
* Real data is often scattered (BigQuery, Databricks, Snowflake); join by customer ID to assemble a profile.
* With discoverable tools, the agent fetches, stitches, and reasons over the facts to label churn risk and recommend actions.

## Links and references

* [Claude by Anthropic](https://www.anthropic.com/claude)
* [BigQuery documentation](https://cloud.google.com/bigquery)
* [Databricks](https://databricks.com/)
* [Snowflake](https://www.snowflake.com/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/ai-agents-for-data-analytics/module/4e6bc78e-00a8-405d-97ce-830c7892b1b1/lesson/1f147659-686c-402a-8df0-55ec1efc45c4)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.