Coworker, Not Copilot: The Architecture Behind Enterprise AI's Rebrand

Over one summer, the platforms that answer questions about your data converged on the same word. Glean now calls itself "the enterprise AI coworker". Snowflake renamed Intelligence to CoWork. Databricks shipped Genie One as an "all-new agentic coworker," the same day Microsoft's Copilot Cowork reached general availability. Then the connectors followed: Genie One shipped into Excel and Google Sheets, and Snowflake's own path into Teams and Microsoft 365 Copilot was already waiting. The same vendors renaming their products around "coworker" are the ones building the plumbing to put those products wherever their users are already working. Not just in Excel and Teams but in whatever tool is holding the actual task. "Coworker" seems to sell better than "intelligence" right now. But that is not a reason to discount the pattern, as it offers considerable insight into the technical aspects of its implementation and governance in general.

Lookup Versus Action

"Intelligence" branding, the lineage that includes Salesforce's Einstein Analytics, IBM's Watson Analytics, and Snowflake's own product before June, described a smarter kind of lookup: pose a question in a dedicated interface, receive a better answer than before. The transaction completes entirely inside that interface. A user visits, asks, reads the answer, and leaves; nothing about the tool needs to exist anywhere else. "Coworker" hints at a different job. Databricks describes Genie One as drafting documents, generating reports, and scheduling tasks, not merely answering questions about a table. The Excel and Google Sheets connectors are what make "drafts documents and generates reports" something other than aspiration. Snowflake, having already built the Teams equivalent months earlier, only had to point to it.

This also explains why the destination-app model, dominant for most of the last decade, is ending now rather than earlier. It was never simply that a better chat interface would have solved user adoption. The model assumed the principal challenge was building an interface compelling enough that people would change their habits to visit it. That assumption holds fine for a lookup tool. It breaks for a tool whose job is to act, because an agent that takes action has nowhere to put the result except inside the tool where the work actually lives. Both the branding shift and the distribution shift are downstream of the same capability claim: answer-only tools can stay in their own room, action-taking tools cannot.

The Governance Bill That Comes With Doing, Not Just Answering

Claiming a product acts, rather than only answers, raises the standard it has to meet once it leaves its native interface. The permissions that would ordinarily gate a query, row-level security, column masking, whether a table is visible at all, must be enforced at query time inside a tool the platform does not fully control. This works only because the permission check is real at query time. The Databricks Excel Add-in authenticates via SSO, and Genie enforces Unity Catalog permissions through on-behalf-of-user authentication, so the same access control governing Genie One's native interface applies identically when the request originates from an Excel cell. Snowflake's Cortex Agents integration inside Teams and Copilot runs through an OAuth service principal for the bot application itself, with row-level security enforced underneath it, so the bot can talk to Snowflake, but the row-level policy still stops it from returning anything the requesting user is not authorized to see.

The semantic layer's central promise is a single governed answer, consistent across every surface where the question is asked. Multiplying the surfaces, Excel, Sheets, Teams, Slack, Copilot, the native chat window, is a direct stress test of that promise, and it is a harsher test for a tool that acts than it ever was for a tool that only answers. Whether the governance actually holds under that stress test is a question no announcement can settle on its own, but the architecture itself starts to answer it. It also is not the only test running. By this point in the summer, the same governance model was being asked to answer to a caller no one had designed a spreadsheet cell for.

A Second Kind of Visitor

Databricks moved Genie One into Beta as a Managed MCP server, reachable at /api/2.0/mcp/genie. Around the same time, it published databricks/databricks-agent-skills, an officially maintained GitHub repository packaging Databricks-specific knowledge as Agent Skills, an open standard, alongside a new databricks aitools CLI command group. Here we can extend the argument established at the outset: a product built to act rather than only answer has to be reachable from wherever the action is actually happening, not only from a dedicated interface built for someone to visit. For a human employee, that meant showing up inside Excel and Teams instead of a standalone chat window. For an AI agent, running inside an IDE, an orchestrator, or another agent's own tool-calling loop, it means the identical thing: being reachable from wherever that agent already does its work, not only from Genie's own front door.

The plumbing this required on the human side, SSO into the Excel Add-in, on-behalf-of-user auth for Genie, an OAuth-backed Cortex Agents bot inside Teams, has a direct counterpart here, aimed at a different caller. Where the Excel connector lets a person pull Genie into a spreadsheet without opening Genie, the MCP server lets an agent, running inside Cursor, Claude Desktop, or a custom orchestrator, pull Genie into whatever it is building without a developer wiring up a bespoke integration first. The distribution problem it solves is the same one, aimed one layer up the stack.

Two Directions Through the Same Door

Model Context Protocol, the open standard Anthropic introduced for connecting AI systems to external tools, has always supported traffic in both directions for a platform like Databricks. Genie One has, for some time, supported custom MCP connections outward, letting an organization's own agents call external tools through Unity AI Gateway. What is new is the reverse direction becoming a first-class, Databricks-managed product: Genie One itself, exposed as the tool being called, by clients Databricks does not operate and did not build.

This is a materially different commitment than adding a chat window. A destination interface can be as capable or as limited as a vendor chooses, because every request arrives through that vendor's own front door. A tool exposed over MCP has to behave correctly for callers whose behavior the vendor cannot fully anticipate, from clients that support the interactive MCP Apps extension, rendering charts and citations inline, to plain text-only clients that see only an answer.

The governance question here is the same one raised above, and Databricks answers it the same way: the managed proxy in front of the MCP server issues each call on the authenticated user's own OAuth token, so a request arriving from Cursor or Claude Desktop is evaluated by Unity Catalog exactly as a native query would be, not through a looser, separate access model built for outside callers.

Skills as the Quieter Half of the Bet

The Agent Skills repository, published the same week, addresses a narrower but related problem: an external coding agent may be permitted to call Genie, and still not know how to use Databricks well. Skills, as a category, package procedural knowledge and conventions and common workflows, rather than live access to data. Microsoft made a parallel bet in June with Fabric Skills for GitHub Copilot, Claude, and CLI, an open-source toolkit that lets coding agents directly author and query Power BI semantic models and other Fabric assets. Neither company is simply exposing an API. Both are teaching outside agents how to be competent inside their platform without requiring a developer to first become an expert in it.

Taken together, the MCP server and the Skills repository extend the same argument one step further. The Excel and Teams work established that a product built to act has to be reachable from wherever the action happens, not just from its own front door. The MCP server and the Skills repository establish something adjacent: reachability alone does not make a caller competent. An external agent calling Genie for the first time does not automatically know Databricks' conventions, which is what the Skills repository is for. Databricks has now removed both barriers that kept its coworker inside its own interface: where you have to go to use it, and what you have to already know to use it well.

#The Test That Is Actually Running

None of this is settled by announcements, and every claim in this piece is, in the end, a vendor's own account of its architecture: a Managed MCP Server still sits behind a workspace preview flag, and on-behalf-of-user authentication is easier to describe than to audit at scale. But the design itself, as described, is consistent. Excel, Teams, and MCP are three separate surfaces, built by different teams on different timelines, for two different callers, a human and an agent. Each one reaches for the same primitive anyway: not a separate, more permissive credential scoped for the outside caller, but the same OAuth token and the same Unity Catalog or row-level check that already governs the native interface. This kind of consistency tends to appear when the underlying enforcement was already built to be called from anywhere. Whether it survives adversarial testing at scale is a separate question, and only the governance logs will answer it. But on the evidence assembled here, the permission model does appear to travel intact rather than thin out at the edges, and "coworker" turns out to be more than the marketing department's word for it.