Building GTM AI Agents: Lessons from Deploying to 6,000 Users — Sait Izmit, Snowflake

Snowflake’s internal go-to-market assistant launched in September and grew to serve roughly 6,000 users. Izmit opens with the operating scale: more than one million questions answered and about 40,000 new questions each week. Snowflake also uses the deployment as an internal proving ground for Snowflake CoWork, the no-code agent platform beneath the assistant.

The business case starts with fragmentation. Snowflake has close to 10,000 employees, and almost half the workforce is in sales. A representative may use 15 tools because each contains a different data point, then manually combine those records in spreadsheets. Some representatives have 1,000 assigned accounts and must track product consumption, support tickets, recent news, and earnings results—then repeat similar research 30 or 40 times a day.

A shared agent promises three linked improvements:

• Data access: Users can ask questions without navigating hundreds of dashboards or waiting for an analyst.
• Tool and workflow consolidation: The assistant can bring information from separate systems into one working interface and automate repetitive work.
• Business capacity: Time saved can help sellers cover more accounts, work more effectively with customers, and potentially improve win rates, deal cycles, and revenue.

Those business outcomes are the destination, however—not evidence that a chat interface will automatically deliver them.

The central product risk is nondeterminism combined with an unrestricted interface. A free-form chat box invites users to ask anything. Izmit’s working model is that the first five answers determine whether a user returns; after a bad first impression, winning that user back may require ten times as much effort, if it remains possible at all. His team treats quality as P(-1): the prerequisite before the rest of the product work matters.

Before trying the early assistant, Izmit mapped Snowflake’s sales process into a spreadsheet of 150 questions. Engineers objected that the agent did not have the data needed for many of them. That objection was precisely why the test mattered: the evaluation represented the questions sellers would actually ask, rather than the questions the current implementation was designed to pass. The first run reached 50% accuracy.

The result led to a sharp scope decision. The team preferred answering 50 questions at 95% accuracy over attempting 100 at 70%. Narrower coverage made the product less impressive on paper, but gave early users a better chance of seeing several reliable answers in a row. Once that trust existed, users could ask for more capability instead of dismissing the whole system.

That restraint did not prevent later scale. Izmit says 60% of the connected data arrived after launch, over the following six or seven months. By the time of the talk, the assistant contained 15 semantic views, 85 tables, and 3,000 columns, plus five or six MCP connections and close to 20 skills. Coverage followed trust rather than preceding it.

Because early interactions carry so much weight, Snowflake did not expose the assistant to everyone at once. The rollout separated three questions that teams often blur together: Is the system accurate? Does it cover enough daily work to become useful? Will users return after trying it?

The pilot used AI-native employees who were willing to tolerate rough edges and provide detailed feedback. Its purpose was quality: find failures, improve accuracy, and smooth the experience before less-forgiving users arrived. After a few weeks, the team moved to a 10% beta of 600 people.

The beta tested whether the assistant was a real minimum viable product. Requests to connect more data were not all treated equally; concentrations of similar requests indicated missing information required by recurring workflows. The team also measured retention rather than relying only on question volume. It moved to general availability after weekly active-user retention exceeded 70%, giving it evidence for quality, sufficient coverage, and repeat use. Snowflake’s companion article, From Pilot to 6,000 Users, expands on this rollout and its change-management work.

General availability exposed a different failure mode. Two weeks after a launch, leaders could see low usage and conclude that the product was weak. Izmit’s counterexample was a graph showing that only 20% of the organization had tried it. A user who tries the product and does not return signals a product problem. A user who never spends five minutes trying it signals an activation problem.

Activation took months and consumed 60–70% of Izmit’s time. The work included joining sales meetings, giving demonstrations, building adoption dashboards by team, securing sponsorship from sales leaders, and asking managers to encourage participation. These activities raised the number of people who had actually experienced the assistant; only then could the team focus on increasing usage among activated users.

Izmit estimates that without this effort, usage might have reached only about half its eventual level. His warning to engineers is practical: deployment is not the end of product delivery. If enablement, leadership support, measurement, and post-launch demonstrations are missing, a technically sound agent can fail before enough people use it to judge its quality.

Four to six months later, success created another problem. At first, users celebrated being able to query company data without waiting up to two weeks for analyst help. After that behavior became habitual, the same users began comparing the assistant with newer AI products and asking why it could not perform additional tasks. Izmit calls this the collapsing wow factor: a capability changes behavior, becomes the baseline, and stops feeling innovative.

The roadmap therefore moves through increasingly consequential forms of assistance:

• Talk to your data: Replace dashboard hunting and routine analyst queues with direct questions.
• Automate my workflows: Use MCP-connected integrations to monitor inboxes and Slack channels, track customer questions, draft replies into Gmail for review, and support outreach workflows.
• Let teams build: Give go-to-market groups the ability to create their own skills, dashboards, applications, alerts, and automations instead of waiting in an IT backlog or purchasing another SaaS tool.
• Hyper-personalize: Adapt tools and outputs to individual sellers and to the evolving context of their customers and contacts.

The stages also change the user’s role. Data chat makes the seller a questioner; connected workflows make the seller an orchestrator; team-built tooling turns domain users into capability authors. Izmit argues that stopping at the first stage invites replacement because the initial breakthrough becomes expected within months. This is a directional product judgment rather than a measured switching-rate result, but it explains why the roadmap cannot freeze after a successful launch.

Izmit contrasts this iteration with enterprises that keep testing frameworks while waiting for a perfect architecture. Waiting avoids visible technical debt, but also avoids the production learning needed to discover the real system. Snowflake’s initial deployment was deliberately plain: nine pages of agent instructions, a couple of Cortex Analyst tools and semantic views for structured data, a Cortex Search service for unstructured data, and instruction versions managed in a Google Doc. That was the system released to 6,000 people.

Production pressure then supplied the architecture roadmap. The team added CI/CD and evaluation infrastructure with unit and routing tests. As business processes outgrew the main instruction document, it introduced a skill library. MCP connections expanded available tools but required more orchestration instructions, which eventually pushed the team toward progressive disclosure. User memory, task scheduling, and a Slack interface followed as the product moved beyond one chat screen.

By the time of the talk, roughly 80% of the original PRD and architecture diagram no longer matched the deployed system. Izmit estimates that 60–70% of sprint work adds features or improves quality, while 30–40% rearchitects the product around new technology. The tradeoff is explicit: moving early creates recurring migration work, but waiting six or nine months for a supposedly final design sacrifices user learning and may leave competitors three or four months ahead.

The recommendation is not to ignore architecture. It is to avoid investing as though today’s agent interfaces, instruction format, memory system, and integration patterns will remain stable. Build enough structure to operate safely and learn, then preserve the ability to replace the parts that production proves inadequate.

Izmit’s final technical recommendation is to invest in logs. At the time of this section, he cites 1.2 million accumulated questions and about 40,000 more each week. LLMs classify those interactions into topics, subtopics, and representative examples. Doing this economically at scale is itself a data-science problem, but the result is a structured picture of what users are trying to accomplish.

The log analysis supplements rather than replaces interviews. It exposes unanswered requests, recurring feature gaps, repeated questions, and visible frustration with poor answers. Those signals tell the product team where quality or coverage is failing in real workflows instead of relying solely on planned evaluations or whoever volunteers for an interview.

For sales enablement, the same data shortens another loop. After a product launch, teams might otherwise interview around 100 sellers per week to discover changing questions and missing knowledge documents or battle cards. Izmit says he can query classified logs and see those patterns within minutes. The team can then ingest material from Confluence, Jira, Slack, and PRDs, generate enablement documents and battle cards, and feed the resulting knowledge back into the assistant.

Logs also reveal coordination opportunities. Different sales teams may approach the same accounts from separate angles without knowing about one another; the platform can detect the overlap and notify them. Izmit’s claimed “hockey stick” comes from reuse: the first capabilities require the platform and data foundation, while later features can build on existing classification, integrations, and feedback paths. The talk does not quantify that growth curve, so it is best understood as an operating pattern rather than a measured exponential law.

His closing synthesis keeps four disciplines together: quality over coverage, activation after launch, continuous movement beyond the fading wow factor, and fast construction on a stack expected to change. Feedback loops connect them. They show what users ask, where trust breaks, which workflows deserve expansion, and what knowledge should return to the system.

An audience question asks whether Snowflake Intelligence was a layer beneath the assistant or the assistant itself. Izmit explains that the product had recently been renamed Snowflake CoWork and describes it as a no-code agent platform for business users. Components such as Cortex Analyst and Cortex Search come with the platform, reducing the amount of application scaffolding the internal team must build itself.

Snowflake made a strategic choice to bring first-party data, third-party data, Salesforce records, call transcripts, and other sources together in Snowflake. Agents can then inherit role-based access controls instead of creating an unrelated authorization system for every data source. CoWork also supplies the chat interface, allowing teams to deploy agents without writing UI code.

The platform does not eliminate curation. Izmit closes by emphasizing control over which data sources agents can use, along with security guardrails around their behavior. That final qualification matters: no-code deployment lowers the implementation cost, while curated access and inherited permissions remain necessary to keep an enterprise agent within the organization’s intended data boundaries.