Agents stopped failing on SQL. Now they fail on context, and platforms are adding the guardrails

The governed door

The Snowflake managed MCP server is the clearest version of the new pattern. The company says it is a schema-level object that allows AI assistants to access warehouse tools without running external containers, and it supports five types of tools: Cortex Agent, Cortex Analyst, Cortex Search, read-only SQL, and custom UDFs or procedures. All MCP tool calls are audited in Snowflake query history under the real user and role, tagged with the MCP request ID. The limits are stated openly too: the server currently supports a maximum of 50 tools per server, responses from GENERIC and SQL tools are truncated at 250 KB, and it does not currently support MCP resources, prompts, sampling or notifications. m:…3754

The design details show how easily governance fails when it is left to defaults. Eylon Steiner recommends separating Cortex Agent tools for business users from read-only SQL tools for engineers to prevent models from bypassing semantic layers, and semantic views are required for Cortex Analyst tools to provide accurate, governed answers. Programmatic Tokens without role restrictions can allow users to list tools even if they lack specific grants, if DEFAULT_SECONDARY_ROLES is set to ALL. Custom procedure tools used in MCP must return a VARIANT type rather than a table to function correctly. None of that is glamorous, and all of it is the work that decides whether an agent answer is trustworthy or merely fluent. m:…3754

A companion Snowflake write-up shows what happens when a team builds on top of that server. The author built a local web UI to interact with Snowflake managed MCP servers, using a proxy that prevents programmatic access tokens from appearing in browser history or devtools, and the console proxy binds to 127.0.0.1 and rejects requests with non-matching Origin headers. The UI dynamically generates forms based on the inputSchema of MCP tools, agent responses include Vega-Lite specifications for chart rendering, and the author observed that agent responses include token usage and timing metadata. The author also warns that agents may interpret user intent incorrectly despite generating valid SQL. That warning is the whole story in one line: a correct query is not the same as a correct answer. m:…2681

Context, not just connection

Zep makes the case that the missing piece is usually context, not query skill. The company says data agents now fail on context more than on SQL, and most business context lives outside table metadata. In a 2026 benchmark study cited by Zep, agents on the strongest model failed more often at finding the right data than at writing the query, and with the strongest model, more than 60% of the remaining failures came from a wrong reading of the data environment. That finding reframes a lot of agent work: improving the model or the SQL generator will not fix a failure that comes from not knowing what a field meant last quarter, or which source is authoritative this quarter. m:…9411

The evidence Zep reports is sobering for teams that treat context as documentation. None of the write-ups in its study describes a record of when a business fact applied, 13 of the 15 teams depend on people to write or approve this context manually, and 10 of the 15 teams check for stale data or context. One team saw its agent accuracy on its evaluation set fall from about 95% to about 65% in the month after launch due to stale context. The answer proposed by Zep is a temporal context graph that stores business facts as records with dates and sources. Anthropic, cited in the same write-up, keeps documents in the same repository as the model it describes to ensure updates occur in the same pull request. The common thread is versioning: business facts need a history, not just a description. m:…9411

Federation and extraction, governed

Databricks Lakehouse Federation attacks a different part of the same problem: where the data lives. The company says Lakehouse Federation allows users to query external databases without moving or migrating data, and supported external databases include SQL Server, PostgreSQL, MySQL and Snowflake. Federated connections are configured through the Databricks UI, foreign catalogs map external databases to native Unity Catalog objects, and queries against federated sources execute in real time against the source database, with no materialized views or persisted objects required. Unity Catalog allows joining federated on-premises data with shared marketplace data in a single SQL query, and Databricks Genie can translate natural language into queries for federated data. The governance benefit is that the data stays under its original controls while the agent still gets a single query surface. m:…9572

Controls around the agent itself

The new enterprise features from Writer close the loop around the agent rather than around the data. The company is releasing features for enterprise control over AI content and workflows, including Playbook approvals that create structured checkpoints for human review in agentic workflows, and new Playbook admin controls that restrict who can create and publish workflows. It shipped a skill security scanner to detect malicious instructions in skill files, customers can choose whether to automatically disable flagged skills, and a new data loss prevention guardrail blocks PII, financial data and credentials from reaching models. Writer Model Context Protocol allows running Playbooks and fetching work from MCP-compatible clients, and Enterprise Brain context will be available via Writer MCP next month. m:…5924