Design semantic views around business questions, not agents

When building semantic views for business users in Snowflake, it's crucial to focus on coherent business questions rather than specific agents or interfaces. The agent acts as an interface and orchestration boundary, and it should not determine where the business model begins and ends.

A semantic view is a schema-level object that maps business concepts to physical data, including logical tables, dimensions, facts, metrics, and their relationships. It determines what a term means, rather than just providing friendly column names. For example, when asking for "booked revenue," the semantic view needs to define how revenue is calculated, what date to use (booking, departure, or payment), how to handle cancelled bookings, refunds, currency conversion rates, and additive behavior.

Avoid creating one view per physical table, as this can lead to a situation where it's unclear where certain business concepts live and how they should be joined. Instead, group logical tables into semantic views that form understandable analytical subjects. For instance, when analyzing booking performance, the view should include all necessary tables, metrics, and relationships to answer those questions consistently.

Similarly, don't create a single massive enterprise view containing every table, metric, and query. This approach makes the model difficult to reason about and maintain. Instead, split the model when questions serve different business decisions, have different grains, are owned by different teams, have ambiguous relationships, or require separate access boundaries and evaluation cycles.

For a travel platform, this might result in separate views like booking_performance, customer_value, and service_disruption. These views represent business subjects and provide a clear separation between different domains. While multiple views can be exposed for routing purposes, remember that Cortex Analyst still needs to choose the most appropriate view for each query. However, this approach separates the responsibilities of routing and semantic definition, making both easier to test and maintain.