# Agentic AI in Action — Part 29 — Cortex Agent Lineage Walkthrough, Built on Two Agents > Source: > Published: 2026-09-22 04:49:00+00:00 Every team running agents in production eventually hits the same question. Someone wants to rename a column, drop a table, or reshape a schema, and the room needs to know what depends on it downstream. Dashboards get checked. Pipelines get checked. Now, agents can be checked the same way, thanks to data lineage for Cortex Agents, which Snowflake added on September 2, 2026, tracing the path from a table through a semantic view to the agent that consumes it. Rather than standing up a separate tracking system just for agents, Cortex Agents now show up in the same lineage graph that already tracks tables, views, and streams, so there is nothing new to learn if a team is already using lineage elsewhere. A semantic view that a Cortex Analyst tool references appears upstream of the agent, and since that semantic view is itself downstream of the tables it was built on, you get one continuous path from a raw table all the way to the agent consuming it, all inside infrastructure that already existed. This post is a hands on walkthrough of that feature, built around a multi agent scenario rather than a single isolated one, two agents sitting on the same source table instead of just one. A single agent only shows a straight line. Two agents branching off a shared table is what actually makes the governance story visible, since you can watch one table fan out into two separate consumers in the graph rather than just being told it can happen, which is closer to how most accounts actually look once agents move past a first pilot. A Snowflake account with Cortex Agents enabled, a role with CREATE AGENT and CREATE SEMANTIC VIEW privileges, and Enterprise Edition or higher since lineage requires it. The companion SQL file for this post runs top to bottom, so you can follow along here and just execute alongside it. It helps to build this demo somewhere self contained, both so it does not clutter an existing database and so the lineage graph you look at later stays free of unrelated objects. Everything from here on lives inside this schema, which also means the whole exercise can be undone with a single DROP DATABASE once you are done experimenting. This is the table everything else in the post traces back to. Think of it as standing in for whatever fact table your own agents are actually built on, a sales table, a claims table, a ticketing table. The structure barely matters here. What matters is that two different consumers are about to be built on top of it. A handful of rows is all this needs. The point of the walkthrough is the shape of the lineage graph, not the size of the dataset. The table is now the root of two lineage paths that get built out in the steps below, one for a revenue focused agent and one for an operations focused agent. The first consumer is shaped around revenue and product questions, the kind a sales leader or account manager would actually ask. With the semantic view in place, this step wires it up as a Cortex Analyst tool inside an agent a business user could actually talk to. The first complete path now exists end to end, sales through sales_semantic_view through sales_agent. The next two steps build a second agent (that has nothing to do with the first one, except for sharing the same underlying table). This second consumer looks at the exact same rows through a different lens entirely, quantities and fulfilment by region rather than revenue. At this point two agents exist that were likely built by two different teams for two different purposes, and neither one needs to know the other exists. That is exactly the situation lineage is meant to make visible. Now for the payoff. With both agents in place, the whole path, table into semantic view into agent, is queryable in one query through the documented GET_LINEAGE table function. The four arguments provided to the function are:**object_name:** *‘sales’*, is the object to start from.**direction:** *‘DOWNSTREAM’*, trace forward to what depends on it. **object_domain:** *TABLE***max_distance:** *3*. This defines how many hops to walk. Setting it to 3 is enough to walk past the semantic view hop and reach the agent itself. Distance 1 would stop at the two semantic views. Bumping it to 3 reaches one hop further, to the agents at distance 2. Here is what that actually returns. Four rows are returned, and they tell the whole story on their own. At *distance 1* (see DISTANCE Column), the sales table branches into both sales_semantic_view and regional_ops_semantic_view, confirming the fan out at the semantic view layer. At *distance 2*, each of those semantic views resolves to its own agent, with TARGET_OBJECT_DOMAIN showing as CORTEX_AGENT, sales_semantic_view leading to sales_agent and regional_ops_semantic_view leading to regional_ops_agent. That CORTEX_AGENT value is fully queryable through GET_LINEAGE, and as the next section shows, the same relationship is just as visible in the Snowsight graph. The query above already tells you everything you need, but the graph view is worth pulling up as well, especially if you are walking a colleague through this rather than reading SQL output on your own. Open Catalog, then Explorer, and select the sales table inside cortex_lineage_demo.lineage_demo. Select the Lineage tab. Look at the lineage tab on the right. The graph mirrors the query results exactly. The sales table sits on the left with its columns listed underneath, and two edges lead out to sales_semantic_view and regional_ops_semantic_view on the right. Expanding either semantic view node one level further surfaces its agent, sales_agent on one branch and regional_ops_agent on the other, which is the same relationship the SQL output already showed, just easier to point at in a screen share. Note that Snowflake only captures this relationship at the moment an agent is created or a new version is committed, so an agent whose most recent version predates this release won’t show up in lineage until it gets recommitted. The demo above is deliberately small, but the situations it stands in for show up constantly once agents move past a handful of pilots. **Schema changes before they ship.** A data engineer proposes dropping a column or splitting a table. Instead of pinging every team that might have an agent nearby, they open the table’s lineage graph and see, in seconds, that two semantic views and two agents sit downstream, which gives them a concrete list of owners to loop in before the change goes out. **Incident response.** An agent starts returning wrong numbers. Rather than guessing which semantic view and which upstream table it depends on, whoever is on call opens the agent’s own lineage entry and reads the path backward, straight to the table that likely changed. **Onboarding new team members.** A new hire inherits a dozen agents built over the past year by people who have since moved teams. The lineage graph gives them a map of what depends on what without having to read every tool_resources block by hand. **Access and governance reviews.** A security or platform team auditing what an agent can reach no longer has to trust documentation that may be stale. The graph reflects what the agent’s specification actually declares, which is a more reliable source of truth for an audit than a wiki page. **Consolidating semantic views.** Once lineage makes it obvious that two semantic views serve two different agents off the same table, as in this walkthrough, it also becomes easier to spot when three or four semantic views are really doing the same job and could be merged. This is really governance catching up to how teams are actually building agents. Once an account has a handful of agents each pointing at different semantic views built on shared tables, tracing blast radius by hand stops being realistic. What this walkthrough demonstrates, one table branching into two agents inside a single graph, is the difference between guessing what might break and knowing exactly what will. The notebook for this blog can be accessed [here.](https://github.com/Krishsriniv/cortex_ai_agent_lineage) *I share hands-on, implementation-focused perspectives on Generative & Agentic AI, LLMs, Snowflake and Cortex AI, translating advanced capabilities into practical, real-world analytics use cases. Do follow me on* *LinkedIn* *and* *Medium* *for more such insights.* [Agentic AI in Action — Part 29 — Cortex Agent Lineage Walkthrough, Built on Two Agents](https://pub.towardsai.net/agentic-ai-in-action-part-29-cortex-agent-lineage-walkthrough-built-on-two-agents-2a56ff6a88bb) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.