When an AI agent gives someone an incorrect answer, getting from the request ID in monitoring to the actual reason for the mistake can take up the entire afternoon, even though the solution itself is usually simple once you find it.
Often, agent issues are related to bad metric definitions or to some other instruction, usually inside a semantic view. A year or two ago, semantic views at Snowflake started out as the context for a single Snowflake Cortex Analyst deployment, and it was assumed that one or two people would know the data well enough to maintain it. But as data agents have taken off, semantic views now get read by every agent and every BI tool that touches a metric, so a one-line change can affect all of them at once. The editor we built for that first audience was a single page in the AI & ML section of the Snowsight interface, somewhat disconnected from all the other work data people were doing.
We’re excited to announce that Semantic Studio, the IDE for semantic views, is now generally available. It brings semantic view authoring into Workspaces, next to the SQL, notebooks and dbt projects your team already has there, and adds deep Snowflake CoCo integrations, git versioning and UX improvements.
Try Semantic Studio in Snowflake today | Read the docs
What it takes to fix one number #
In the past, fixing issues in agents was a multistep process. The first stop was checking monitoring so you could find the details of the request and get its request ID. From there you opened the agent trace to work out which tool was responsible. Narrowing it down meant reading the generated SQL and comparing it to a query you would have written yourself.
The semantic view editor was in a different section of Snowsight, and it opened at the top of the file because the UI had no context about which agent error you were fixing. Checking a hypothesis about a metric meant running semantic SQL against a definition you hadn’t saved yet, so you opened a worksheet and hand-wrote the query the agent would have generated. If it worked, you went back to the editor, back to the agent and back to monitoring to confirm.
Four surfaces went into a one-line fix, and the work of connecting them was on you.
Our internal telemetry showed more than half of all agent builders were moving back and forth between the semantic view UI and the agent admin UI, and when we asked builders what made maintenance hard, what they described was this work rather than the editing itself.
The same afternoon in Semantic Studio #
Correlating all of that is work you'd want to hand to a coding agent. Semantic Studio puts semantic views in Workspaces, where CoCo runs in the panel beside the editor. Tabs are not page loads, so moving between a definition, an eval and the result of that eval feels much faster
The session still starts in the same place, with a request ID from monitoring. Just giving the ID to CoCo can tell you which metric produced the number and why, because it has access to the agent configuration, the query that ran, and the logs together. The answer comes back in natural language, and you can then just ask it to make fixes to your semantic view.
Trusting that answer is easier when a definition sits next to the data it produces. A definition can always be easily checked by asking CoCo what it returns rather than by reading the expression and imagining the result.
The fix arrives as a diff (a comparison showing what would be added, removed or changed) that you accept or reject. It shows up in the visual editor or in YAML, and the two always stay in sync.
Every other agent and dashboard reading those metrics gets the change too, so the last part of the afternoon is spent shipping it carefully. In Workspaces, a semantic view is a file in a repository your team owns, which makes it a version you promote rather than a live object you overwrite. Running the eval set against the edited view first tells you whether the questions that used to work still work.
From there it's the same workflow as anything else the team ships. The change goes out as a pull request, so someone else reads the diff and the reasoning behind it, and CI can run the evals on merge. Deploying shows exactly what will change and waits for confirmation, and one file can point at development, staging and production separately. Afterward the change sits in history with an author and a reason attached, and you can roll it back.
How to get started with Semantic Studio #
Opening a semantic view in Snowsight now takes you to Semantic Studio. Try Semantic Studio in your account, or read the documentation for more.