Migrating Enterprise AI to the Cloud: Ontology-Driven Agents Show the Way

Why Ontologies Matter in Cloud Migration

When you move enterprise data and AI workloads to the cloud, you're not just lifting tables and SQL queries. You're also moving the hidden meaning that lives in your data—the domain knowledge that isn't in any schema. That meaning often sits in formal ontologies, taxonomies, and controlled vocabularies that your organization has maintained for years. In healthcare, that's SNOMED CT or Gene Ontology. In supply chain, it's GS1. In finance, it's FIBO. These resources encode class hierarchies, typed relationships, constraints, and canonical identifiers. Yet most AI systems in the cloud still run on relational abstractions—tables, columns, keys, joins—and can't natively access the knowledge layer that defines concept inheritance, transitive relations, or equivalence mappings.

That gap between how we model the real world and how AI retrieves and reasons about business data becomes painfully obvious when an analyst asks, “Show total spend on all electronic components.” Electronic components sit at the top of a taxonomy that includes capacitors, resistors, integrated circuits, and dozens of subcategories. A system that doesn't understand the hierarchy will miss most of the data. The same problem appears in biomedical research: “Show drug efficacy of PD-1 inhibitors in epithelial-derived cancer cell lines” requires expanding a parent concept into dozens of cell types and 13 tissue categories.

Snowflake recently published a benchmark that tackles this head-on. The team built a baseline agent using Semantic View and Cortex Analyst, then added three ontology-aware enhancements: a knowledge graph, a flattened GraphRAG, and targeted term mappings. The results offer a practical roadmap for any team migrating AI to the cloud and wanting more than just basic SQL generation.

The Baseline: Semantic View and Cortex Analyst

The baseline agent uses Semantic View, which introduces a governed semantic layer on top of physical tables. Think of it as a clean, domain-focused model that AI can work with instead of raw database schemas. In a biomedical scenario, the semantic layer represents drugs, protein targets, cell lines, and disease phenotypes as logical entities. It defines facts like drug-target interactions, dimensions like tissue type or disease state, and metrics like potency or efficacy.

But Semantic View alone can't handle hierarchical reasoning. It doesn't know that a squamous epithelial cell is a subclass of epithelial cell, which is a subclass of eukaryotic cell, and so on. That's where the ontology-aware enhancements come in.

Building a Knowledge Graph in Snowflake

The first enhancement was a simple knowledge graph stored directly in Snowflake tables. No separate graph database needed. The graph uses two tables: KG_NODE for entities (with a VARIANT column for flexible attributes) and KG_EDGE for relationships (with source, target, edge type, and optional metadata like timestamps or confidence scores).

The key operation is graph traversal—moving from an entity across multiple hops without knowing the path length in advance. Snowflake supports this with recursive common table expressions (CTEs). Recursive CTEs repeatedly join the edge table to itself, expanding the search frontier until no new nodes are found, a depth limit is hit, or a timeout occurs. This is far more flexible than fixed self-joins, which require hardcoding the number of hops.

Consider a simplified graph for drug discovery: drug targets protein, protein triggers pathway, pathway expressed in cell type, cell type affected in disease, and disease subClassOf disease category. You can't predict whether a disease is two hops away or requires subclass expansion. Recursive CTEs handle that dynamically.

The knowledge graph agent had access to seven tools, including four stored procedures (expand cohort, get ancestors, get hierarchy path, get cohort efficacy) and two dedicated Cortex Analyst Semantic Views. One example tool, get_ancestors, takes a concept like “squamous epithelial cell” and walks upward via subClassOf edges, returning all ancestors up to the root. It's deterministic and can traverse 10+ levels of hierarchy, covering all 693 descendants of “epithelial cell” when expanding downward.

But seven tools bring orchestration complexity. The agent must choose the right tool and call it in the right order. The stored procedures require exact concept names, with no synonym resolution.

Flattened GraphRAG: Simpler and Often Better

The second enhancement took a different tack. Instead of traversing the graph at query time, it precomputes a denormalized profile for every concept. Each profile includes the concept's name, definition, synonyms, local neighborhood (parents, children, grandparents, grandchildren), and aggregated attributes from all descendant concepts. These profiles are indexed into Cortex Search, supporting both keyword and vector search.

At runtime, the agent retrieves the most relevant profiles, extracts the business or scientific context, and passes it to Cortex Analyst or downstream SQL generation. This approach uses only two tools: a search tool and a SQL tool. It's architecturally simpler, handles synonyms better, and doesn't require graph traversal at runtime. The downside: quality depends heavily on how well the profiles are built and kept current.

In the Snowflake benchmark, the GraphRAG agent resolved synonyms like “flat epithelial” to “squamous epithelial cell” via semantic search. It also pre-aggregated tissue types from descendant concepts, which proved to be one of the most impactful interventions. However, it couldn't resolve compound terms that map to a union of multiple cell types, like “internal organ lining.”

Adding Targeted Term Mappings

To close that gap, the team added human-curated mappings directly into the agent's system prompt. For this benchmark, they hardcoded eight authoritative cell-type-to-tissue-type mappings and compound term definitions. For example, Squamous Epithelial Cell (CL:0000076) maps to Skin, Lung, Esophagus, Bladder, and Cervix. This effectively applies the mapping to all descendants of that cell type in Cell Ontology.

This approach compresses multi-step lookups into a deterministic mapping table, eliminating “last-mile” errors. But it requires manual maintenance and only covers concepts that have been mapped. Unmapped concepts still need dynamic search.

Using Cortex Code to Optimize the Agents

Building the agents was only half the work. The other half was tuning system prompts, tool descriptions, and tool selection heuristics. The team used Cortex Code's agent optimization skill to iteratively improve all four agent configurations. The workflow: run the evaluation suite (22 questions per configuration, repeated 5 times), analyze failure modes, propose prompt improvements, apply them, and re-evaluate.

Several design choices that boosted accuracy came directly from this loop: enriching search text with tissue-type keywords, forcing tissue-type pass-through, and standardizing statistical threshold rules. Without this tight optimize-evaluate cycle, the gains would have been much smaller.

Results and Key Takeaways

The benchmark results were clear. Each enhancement improved on the baseline. The knowledge graph added about 10 percentage points in accuracy, thanks to exhaustive hierarchical expansion. GraphRAG added another 10 points, likely due to simpler architecture and pre-integrated descendant data. The term mapping approach pushed accuracy even higher by resolving complex aliases and compound terms.

Three observations stand out for teams planning cloud migration:

• Fix the data layer first. GraphRAG with aggregated descendant attributes captured about 80% of the total gain over the baseline, even without static mappings. Precomputing tissue type lists was the single most impactful intervention. Don't hand-curate rules until your index has complete data for every concept.
• Fewer tools can work better. The flattened GraphRAG agent matched the knowledge graph agent's performance with only two tools. More tools provide more raw power, but they also expand the space for orchestration errors. GraphRAG's simplicity produced the lowest observed variance across runs. The hardcoded mapping approach had the highest peak accuracy but also the highest run-to-run variance.
• Targeted hardcoding closes the last gap. The term mapping agent's advantage over GraphRAG was concentrated on compound terms like “internal organ lining” that can't be derived through hierarchy traversal alone. For known, limited vocabularies, embedding curated mappings in the prompt is effective. Keep this layer lean—it should complement the index, not replace it.

Practical Guidance for Cloud Migration Teams

Any team moving AI to the cloud can follow the same pattern: load your ontology into Snowflake, build an index, create an agent, and optimize with Cortex Code. The benchmark used a simplified biomedical dataset, but the principles apply broadly. Start with a governed semantic layer, then layer on ontology-aware techniques. Use recursive CTEs for hierarchy traversal when you need dynamic path lengths. Precompute denormalized profiles for fast, consistent retrieval. Add curated mappings only where they fill known gaps.

The biggest takeaway: in this benchmark, improvements correlated more strongly with structured context than with added computational reasoning. That's a valuable insight for cloud migration—invest in your data's semantic richness before you invest in more complex models. The cloud gives you the scale and flexibility to do both, but the data layer is where the real leverage lies.