The whole system assembles inside your Snowflake account. Watch the pieces land:

One SQL call creates the agent, its configuration, and every tool it needs:

USE WAREHOUSE FALKORDB_WH;

CALL <app_instance_name>.graph.create_agent(
  'FALKORDB_GRAPH_AGENT',
  'SOURCE_DB.SOURCE_SCHEMA',   -- where your data lives
  'WORKING_DB.WORKING_SCHEMA'  -- where the agent may write
);

Then a few grants make it usable: one so your role can talk to agents, and two so the app can call Cortex models for Cypher generation:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE <consumer_role>;

-- lets text_to_cypher resolve SNOWFLAKE.CORTEX.COMPLETE
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO APPLICATION <app_instance_name>;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO APPLICATION <app_instance_name>;

A chatbot answers from what it already knows. An agent decides what to find out. The difference is tools, and create_agent provisions a whole schema of them, agent_tools, as plain Snowflake functions and procedures the Cortex Agent calls like any custom tool:

The tools split into three natural groups:

• Discovery: list_graphs, inspect_graph, graph_stats. Before writing a single line of Cypher, the agent looks at what actually exists: labels, relationship types, property keys, node and edge counts.
• Generation & execution: text_to_cypher turns a question into a query; run_cypher executes it and returns both the query and the result.
• Loading: load_csv plus load_csv_guidance move bound Snowflake tables into the graph (more on this in section 05).

A subtle but important design choice: get_context gives the agent its operating guidance as data: which tool to reach for, when to stay read-only, when to ask before mutating. The behavioral contract lives in a config table the app owns, not buried in a prompt you can’t inspect.

Here’s what actually happens between typing a question in Snowflake Intelligence and getting an answer back:

The interesting step is text_to_cypher. It doesn’t guess at your schema: it reads it. Before calling the model, the procedure pulls the live graph’s labels, relationship types, property keys, and stats, and hands them to SNOWFLAKE.CORTEX.COMPLETE as context. Generated Cypher matches the graph that exists today, not the one an LLM imagines.

The default model is claude-4-sonnet, running through Cortex inside Snowflake. Want a different one for a single generation? Pass it as the optional fourth argument:

CALL <app_instance_name>.agent_tools.text_to_cypher(
  'FALKORDB_GRAPH_AGENT',
  'airroutes',
  'Find the top 10 airports by outgoing routes',
  'claude-sonnet-4-5'   -- change to any Snowflake Cortex model
);

No black-box answers

Every response that involves Cypher shows the Cypher. text_to_cypher returns the generated query; run_cypher returns the executed query alongside its result. If an answer looks off, you don’t debate the agent: you read three lines of Cypher, spot the wrong relationship type, and rephrase. That single property is what separates an analytics tool you trust from a demo you screenshot.

Some prompts to start with, verbatim from the integration guide:

› What graphs are available?
› Inspect my graph schema and suggest useful Cypher queries.
› Find the top connected nodes in my graph.
› Generate a Cypher query for this question and run it.
› How do I load my bound Snowflake table into FalkorDB?

The agent helps you load data too, but deliberately doesn’t hold all the keys. Binding a table to the app is a human decision made through Snowflake’s reference flow; the agent works only with what an admin has already bound:

The division of labor is explicit:

• You (or your admin) bind consumer_data_table to the app. The agent cannot create this binding, by design.
• The agent generates the LOAD CSV FROM 'file://consumer_data.csv' AS row ... mapping Cypher, asks which graph to load into if you didn’t say, and waits for your confirmation before calling its load tool.
• The guidance tool nudges toward production habits: MERGE for retry-safe loads, and an index on the matched property before large loads: CREATE INDEX ON :Airport(id).

Cleanup is one call too

-- print optional caller grants for the configured schemas
CALL <app_instance_name>.graph.get_agent_caller_grants('FALKORDB_GRAPH_AGENT');

-- remove the agent and its app-owned artifacts
CALL <app_instance_name>.graph.drop_agent('FALKORDB_GRAPH_AGENT');