One Agent and Three Data Layers

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:

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

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:

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

Console interaction (toolbox output):

# 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

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.

Building Agent With BigQuery

Building Agent With Databricks

Building Agent With Snowflake

One Agent and Three Data Layers

Watch Video