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

# One Agent and Three Data Layers

> Demonstrates using one LLM agent with prebuilt connectors to query Snowflake, BigQuery, and Databricks to combine billing, usage, and support data for customer prioritization

All right — it's Thursday afternoon and the database credentials have already been loaded from our `.env` file. The agent is configured with a read-only role and the remaining step is wiring the Python LLM agent to query Snowflake and return billing information for customers.

Keep secrets out of source control. Use a secrets manager or a CI/CD variable store for production credentials instead of committing `.env` files.

Below is the relevant portion of the `.env` used to connect to Snowflake:

```bash theme={null}
# who you are
SNOWFLAKE_ACCOUNT=xy12345.eu-west-1
SNOWFLAKE_USER=agent_svc
SNOWFLAKE_PASSWORD=•••••••
# where the data lives
SNOWFLAKE_DATABASE=analytics
SNOWFLAKE_SCHEMA=billing
SNOWFLAKE_WAREHOUSE=compute_wh
# what you're allowed to do
SNOWFLAKE_ROLE=analyst_read_only
```

For quick reference, here’s a short table describing each environment variable:

| Variable | Purpose |
| -: | - |
| `SNOWFLAKE_ACCOUNT` | Snowflake account identifier and region |
| `SNOWFLAKE_USER` | Service user the agent will connect as |
| `SNOWFLAKE_PASSWORD` | User password or secret (use a secret manager in prod) |
| `SNOWFLAKE_DATABASE` | Database that contains billing tables |
| `SNOWFLAKE_SCHEMA` | Schema containing `billing_accounts` and related tables |
| `SNOWFLAKE_WAREHOUSE` | Warehouse used to run queries |
| `SNOWFLAKE_ROLE` | Read-only role to prevent accidental writes |

Integration uses the same MCP toolset, the same stdio connection pattern, and the same subprocess runner as other connectors. The only differences are:

* which prebuilt tool we select (Snowflake in this case), and
* the instruction we provide to the agent.

Example Python configuration that uses the Snowflake prebuilt toolbox and exposes an SQL execution tool to the agent:

```python theme={null}
from mcp import MCPToolset, StdioConnectionParams, LlmAgent

toolset = MCPToolset(
    connection_params=StdioConnectionParams(
        command="./toolbox",
        args=["--prebuilt", "snowflake"],
    ),
    # Optionally filter tools exposed to the agent; uncomment to restrict:
    # tool_filter=["execute_sql"],
)

agent = LlmAgent(
    instruction="Read the billing columns."
)
```

Because the environment passthrough already carries the seven Snowflake variables once the `.env` loader populates them, the toolbox can connect to Snowflake immediately when it starts. The Snowflake prebuilt publishes available tools (for example, an `execute_sql` tool and possibly others), so in many cases you don't need to restrict the toolset unless you want to limit agent capabilities.

Now run the agent. When the toolbox boots it connects to Snowflake and waits for the agent to ask a question. Suppose we ask:

> "What's the billing picture for cust-0003115?"

The agent composes SQL against the `billing_accounts` table and asks the `execute_sql` tool to run it. The toolbox runs the query using the read-only role and returns the result.

SQL the agent generated:

```sql theme={null}
SELECT *
FROM billing_accounts
WHERE customer_id = 'cust-0003115';
-- executed as role analyst_read_only
```

Console interaction (toolbox output):

```text theme={null}
# toolbox connected to Snowflake
> What's the billing picture for cust-0003115?

SELECT *
FROM billing_accounts
WHERE customer_id = 'cust-0003115';
-- executed as role analyst_read_only

1 row returned

plan_tier:        business
monthly_revenue:  $4,000
contract_type:    annual
contract_end_date: 2026-11-23
```

(Above, `contract_end_date` is returned as an ISO-like date; depending on your table schema you may see a date or timestamp. The example shows a contract ending \~34 days from today.)

Now assemble the three data layers together to get a complete picture for the account:

* From BigQuery: actual usage metrics — e.g., usage has dropped about 27 percentage points.
* From Databricks: customer support and sentiment — e.g., 5 recent tickets: 3 billing-related, 4 marked as angry, 2 still open.
* From Snowflake: billing and contract attributes — e.g., \$4,000 monthly, renewing in \~34 days, plan tier: business.

Individually, each system contains a piece of the truth. Together, the agent can fetch and join those pieces to produce a single, actionable view: this account is declining in usage, showing angry sentiment in support, has unresolved tickets, and represents \$48,000 ARR with an upcoming renewal in five weeks. Before connecting the layers, no single team at Bluepine had all four facts in one place even though each was recorded in different systems.

Revisiting the original problem from Monday morning: Claire had 12 renewals this quarter but no clear way to prioritize which ones needed immediate attention. A practical prioritization strategy:

* Use `contract_end_date` to identify imminent renewals.
* Use usage decline and sentiment to rank accounts by risk.
* Use monthly or annual revenue to prioritize outreach efforts based on ARR impact.

How the architecture behaves in practice

* One LLM agent, a single instruction, and one runner stay constant.
* All variability comes from the prebuilt tool connectors and the systems they access (BigQuery, Databricks, Snowflake).
* This pattern lets analysts build the agent once and reuse it across multiple data systems with minimal changes.

In production, never embed credentials in repo files or container images. Use IAM roles, secrets managers (e.g., HashiCorp Vault, AWS Secrets Manager), or your CI/CD secret store to inject credentials at runtime.

Links and references

* [Snowflake Documentation](https://docs.snowflake.com/)
* [BigQuery](https://cloud.google.com/bigquery)
* [Databricks](https://www.databricks.com/)
* [MCP For Beginners](https://learn.kodekloud.com/user/courses/mcp-for-beginners)

Summary

* The MCP toolset and prebuilt connectors let an agent access multiple data systems via a stable protocol.
* Keep the agent simple: one agent + one instruction is often enough; expand capabilities by swapping or adding prebuilt tools.
* Use proper credential management and a read-only role for safe, auditable querying in production.

> **[Watch Video](https://learn.kodekloud.com/user/courses/ai-agents-for-data-analytics/module/432d3dee-4625-4352-92e7-0e247db776ea/lesson/4bebf2a4-8ac3-4cec-88ff-918732dbd565)**


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