What Are We building

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.

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."

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:

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.

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.

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.

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:

# 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.

Building Agent With BigQuery

Building Agent With Databricks

Building Agent With Snowflake

What Are We building

Task 1 — What is an agent?

Task 2 — The empty tools block

Task 3 — Go get the data

Summary

Links and references

Watch Video

​Task 1 — What is an agent?

​Task 2 — The empty tools block

​Task 3 — Go get the data

​Summary

​Links and references

Watch Video

Task 1 — What is an agent?

Task 2 — The empty tools block

Task 3 — Go get the data

Summary

Links and references