Should Snowflake launch its own AI agent marketplace in 2027?

The procurement meeting where this decision actually gets made

Picture a mid-market logistics company with about 900 employees and a four-person RevOps team. They already run Snowflake as their warehouse: Salesforce and NetSuite land through Fivetran, ticket data arrives from Zendesk, and a dbt project produces the revenue models the CRO reads every Monday. In March, the VP of Sales asks for an agent that reads open pipeline, flags deals with no buyer-side activity in fourteen days, and drafts a re-engagement sequence for the AE. The RevOps lead has three realistic options and roughly six weeks before the quarterly business review where they have to show something.

Option one is a point vendor that runs its own cloud. The agent needs pipeline data, so RevOps opens a reverse-ETL path out of Snowflake into the vendor's platform, which means a security review, a data processing agreement, a new egress line item, and an argument with the data governance lead about whether opportunity records with named contacts can leave the account. Realistically that is four to eight weeks of non-engineering work before a single agent run happens. Option two is building it in-house. The team can do it — Cortex Analyst can turn "deals with no activity" into SQL, and a scheduled task can post to Slack — but it becomes a maintained internal product with an owner, a runbook, and an on-call story that a four-person team does not have. Option three is installing an agent from a marketplace where it runs inside their own Snowflake account, against their own tables, under their own masking policies, billed against credits they already committed to.

Option three is the one that clears procurement in an afternoon, and it is the one Snowflake does not currently offer as a first-class product surface. That gap is the entire argument. Every quarter the third option does not exist, this company either picks a competing platform's agent layer, builds internally and never buys, or does nothing. All three outcomes are bad for Snowflake, and the third is the worst because it teaches the buyer that agents on their data are a nice-to-have rather than a line item.

The RevOps angle matters more than it appears. The buyers most ready to install a data-native agent are not data engineering teams — they are revenue operations, finance operations, and support operations teams who already treat Snowflake as the system of record but do not want to write Python. They have budget, they have an urgent use case, and they have almost no appetite for infrastructure work. A marketplace listing that installs into their existing account is the only distribution shape that reaches them. That is the customer segment a Snowflake agent marketplace wins, and it is a segment competing platforms are courting directly.

How an agent listing would actually work inside the existing platform

The mechanism is less dramatic than the strategy. A Snowflake agent is a Native App with three additions: a planner configuration, a declared tool catalog, and a telemetry contract. Everything else — packaging, versioning, install flow, consumer/provider separation, secure views over consumer data — already exists in the Native Apps Framework and does not need to be reinvented.

The planner configuration names the model and the orchestration behavior. Snowflake already ships Cortex Agents as a first-party primitive that combines Cortex Analyst for structured retrieval over semantic models and Cortex Search for unstructured retrieval over documents, with tool-calling on top. A partner agent declares which of those primitives it uses and supplies its own system instructions. The tool catalog is the list of actions the agent may take: run a query against a granted view, call an external endpoint through an external access integration, write to a specific table, or request human approval. The install flow already asks the consumer to grant privileges to a Native App; agents extend that same consent screen with tool-level grants, so an admin can install an agent with read access to ANALYTICS.PIPELINE and no write access anywhere.

Runtime is the part people assume is missing and is not. Stateless UDFs are wrong for agents because a planner loop is long-running and holds state between tool calls, but Snowpark Container Services exists precisely for long-running containerized workloads inside the account's own compute. A partner packages the planner loop as a container service, the container calls Cortex or an approved external model, and conversation state persists to a table in the application's own schema. Nothing crosses the account boundary unless the partner explicitly declares an external access integration, which the consumer must approve.

Governance is the differentiator and it comes free. Horizon policies — dynamic masking, row access policies, tags, and lineage — apply to the views the agent reads because they apply at the object level, not the caller level. If an email column is masked for a role, it is masked for the agent running under that role. This is the structural claim that no agent platform outside the warehouse can make: they enforce policy at their own perimeter and hope it matches yours; a marketplace agent inherits yours by construction.

mermaid flowchart TD A["Consumer installs agent listing from Snowflake Marketplace"] --> B["Native App provisions into consumer account"] B --> C["Consumer grants roles and tool-level privileges"] C --> D["Planner loop runs in Snowpark Container Services"] D --> E["Cortex Analyst structured retrieval"] D --> F["Cortex Search unstructured retrieval"] D --> G["Declared tools write, external call, approval"] E --> H["Horizon policies applied at object level"] F --> H G --> H H --> I["Telemetry rows run id, tokens, credits, outcome"] I --> J["Consumer dashboard and provider quality score"] J --> K["Consumption billed on existing credit contract"]

The consequence of this design is that the incremental engineering surface is small and concentrated in three places: a manifest field that marks a listing as an agent, a discovery taxonomy in the Marketplace UI so agents are browsable by function rather than buried among data listings, and a required telemetry schema so every agent emits comparable run records. Those are metadata, UI, and contract changes — not new infrastructure. A standalone marketplace, by contrast, would require duplicating the install flow, the entitlement system, the partner certification pipeline, and the billing integration, none of which produce customer value that the existing surface does not already deliver.

What the numbers look like when you scope it honestly

Strategy documents fail on arithmetic, so it is worth being concrete about what is knowable and what is not. What is knowable: Snowflake reports thousands of customers and the Marketplace already carries thousands of listings with an established install-into-account flow. What is not knowable from outside is Snowflake's internal engineering capacity, so any effort estimate here is a scoping frame, not a claim about their roadmap.

Scope the listing-type extension by workstream. A manifest field plus validation is small — days of work, not weeks, because the Native Apps manifest already parses extensible metadata. Discovery taxonomy and filter facets in the Marketplace UI is the larger visible piece: category definitions, badge treatment, listing page layout for agent-specific fields, and search indexing. Call that a two-to-three sprint UI effort. The telemetry contract is the most under-appreciated item and deserves the most care, because a schema you ship publicly is a schema you support for years; budget a full quarter of design review even if implementation is fast. Certification policy for agents that write data or call external endpoints is a policy workstream, not an engineering one, and it runs in parallel. Add partner enablement — reference implementations, documentation, a sample agent that a partner can fork — and the realistic shape is one quarter to a credible beta with a handful of named partners, two quarters to general availability with a populated catalog.

Compare that to a standalone storefront. There you rebuild install and entitlement flows, stand up a separate partner agreement and rev-share, create a second certification queue, integrate billing again, and — the expensive part — build discovery traffic from zero. Marketplace SEO and in-product placement took years to accumulate. Splitting it means both surfaces underperform the combined one. The honest comparison is not "three months versus nine months of engineering"; it is "one quarter of engineering versus nine months of engineering plus two years of audience rebuilding."

On pricing, the useful move is publishing SKU templates rather than letting every partner invent one. Three shapes cover nearly all agent value: per-token for open-ended assistants where consumption tracks conversation length, per-task for bounded jobs like enrichment or classification where the unit is a processed record, and per-outcome for agents that close a loop such as a resolved ticket or a completed reconciliation. Per-outcome is the strongest for enterprise procurement because it converts an AI purchase into a unit-economics question a finance team already knows how to evaluate: cost per resolution against fully-loaded cost of a human resolution. Per-token is the weakest for the same reason it is easiest to implement — nobody can forecast it, so procurement caps it, and a capped agent is a disabled agent.

Snowflake's cut on agent consumption should match whatever the Native Apps revenue split already is rather than introducing a separate rate, because a different rate is the fastest way to make partners treat agents as a distinct business with distinct negotiation. The genuine economic prize is not the take rate anyway. It is that agent workloads are compute workloads: every planner loop, every retrieval, every embedding call burns credits in the consumer's account. An agent that runs a hundred times a day against pipeline data is a recurring consumption driver that also increases switching costs, because the agent is configured against that account's semantic model and grants.

For a launch cohort, the correct number of partners is small. Five to ten well-integrated, documented, benchmarked agents across distinct functions — a RevOps pipeline agent, a support triage agent, a data quality agent, a finance reconciliation agent, a research and enrichment agent — beats fifty unvetted listings by a wide margin, because the first browse experience sets the perceived quality of the entire surface. A catalog where three of the first ten listings are abandoned demos teaches buyers that marketplace agents are not serious.

Where this could go wrong, and the alternatives worth weighing

Four paths exist and only one of them survives scrutiny, but the losing paths lose for instructive reasons.

Extending the existing Marketplace is the recommendation: moderate investment, roughly a quarter to beta, low partner friction because it is one listing and one billing relationship, and it compounds the discovery asset rather than splitting it. Its real risk is that agents get lost among data listings — a search for "pipeline" returning forty datasets and one agent is a discovery failure that looks like a demand failure. That is why the taxonomy work is not cosmetic.

A standalone sub-brand is the tempting path and the wrong one. It buys a launch narrative and a keynote slide, and it costs a duplicated install surface, a second certification queue, a fragmented partner economics conversation, and a split funnel. Field friction is the underrated cost: an account team already carries Marketplace, Native Apps, Cortex, Horizon, and Snowpark into every conversation, and a sixth named surface does not get sold — it gets skipped. Partners face the mirror image, choosing between two listings and usually publishing to one. The pattern of separate agent storefronts being folded back into a parent app marketplace has repeated across enterprise platforms for the same structural reason every time: agents are software distributed to the same buyer through the same install path, so a separate storefront is a taxonomy decision masquerading as a product decision.

A first-party-only Cortex agent gallery is cheap and fast — Snowflake could ship a curated set of its own agents in weeks. It is also a strategic dead end, because the point of a marketplace is partner supply, and a gallery with no partner path tells the ecosystem to build somewhere else. It is defensible only as a stepping stone: ship first-party agents to prove the runtime and the telemetry contract, then open the same surface to partners on a published timeline. Ship it without that timeline and it reads as a closed platform.

Acquiring an existing agent hub is the highest-cost, highest-conflict option. The acquired hub's value is its partner roster, and that roster is usually multi-cloud by design; forcing it Snowflake-only destroys the thing that was purchased, while leaving it neutral means Snowflake paid a premium for a surface that also distributes to Databricks and AWS. Worth revisiting only if a category-defining asset appears at a price that beats organic partner recruitment.

Doing nothing is the option that gets chosen by default when a decision is deferred, and it has the worst risk profile. Competing platforms are all building agent distribution adjacent to enterprise data. Salesforce pairs Agentforce with Data Cloud, which competes directly for the "agents on your business data" narrative. ServiceNow ties agents to workflow execution, which Snowflake structurally cannot match without a workflow engine — and should not try to. Microsoft distributes agents through Microsoft 365, which owns any agent touching documents and email. Databricks is the closest architectural peer, having shipped the Mosaic AI Agent Framework as a development framework announced at their June 2024 Data + AI Summit; the framework is not itself a marketplace, but the distance from "framework partners build on" to "catalog partners publish to" is short, and closing that distance first is a real advantage.

The honest counterargument to launching at all deserves a hearing: agent quality across the industry is uneven, and a marketplace full of demos that fail on real data damages platform trust more than absence does. That argument is a reason to gate hard on certification and to publish measured quality scores, not a reason to skip the surface. The mitigation is structural — require a benchmark run before a listing goes live, publish the eval set so results are reproducible, and show the score on the listing page the way model cards show evaluation results. A marketplace that publishes uncomfortable numbers is more trusted than one that publishes none.

The failure modes that kill agent marketplaces before they get traction

The first pitfall is unbounded cost. An agent whose price is per-token and whose planner can loop is a budget hazard, and one runaway bill teaches a finance team to block the category. The fix is enforced at the platform level rather than left to partners: a per-install spend ceiling the admin sets at install time, a hard cap on planner iterations per run, and a kill switch that suspends the application without uninstalling it. Publish these as guarantees on every listing page. "This agent cannot exceed the budget you set" is a stronger sales line than any capability claim.

The second is silent failure. Agents fail differently from applications — they do not crash, they return confidently wrong answers, and nobody notices for weeks. This is why the telemetry contract must be mandatory rather than encouraged. Every run emits a row: run identifier, agent version, invoking role, tools called, tokens consumed, credits burned, latency, and the outcome the agent declared. Without a required schema, every partner invents their own logging, comparison across agents becomes impossible, and buyers fall back on brand recognition instead of measured performance. With it, a customer can answer "is this agent still working?" with a query instead of an anecdote — and a platform can spot a listing whose success rate collapsed after a model update.

The third is the missing human-in-the-loop primitive. Every agent that takes a consequential action needs an approval step, and today every partner rebuilds the same Slack-or-email approval flow. That duplicated cost is pure waste and it produces inconsistent security postures — some implementations authenticate the approver properly and some accept any click on any link. A first-class approval primitive with a Snowsight inbox plus optional Slack and email delivery removes the most common partner rebuild and standardizes the audit trail. Approvals then become queryable objects: who approved what, when, and what the agent did afterward.

The fourth is missing attribution. When an agent writes a row or triggers a downstream process, lineage should record that an agent did it, which version, and on what evidence. Without agent-aware lineage, data teams discover mystery writes and respond by revoking write access entirely, which reduces every agent to a read-only chatbot. Extending lineage to carry agent identity is the change that lets an admin grant write access with confidence, and it is the difference between agents that advise and agents that do work.

The fifth is a cold-start catalog. Marketplaces fail when the first browse returns thin results, and the failure is self-reinforcing: no buyers means no partner investment means no listings. The counter is a curated launch with a small number of genuinely useful agents, each with a published benchmark, a documented data contract listing exactly which tables it needs, and a real customer reference. Pair that with a trial period — a bounded free credit allowance for a new install — so evaluation does not require a purchase order. Trial data is also the fastest way to learn which agent categories convert.

The sixth pitfall is specific to RevOps buyers and frequently missed: the agent that cannot see the semantic layer. A pipeline agent that queries raw Salesforce tables will disagree with the dashboard the CRO reads, because the dashboard runs on dbt models with the company's actual definition of a qualified opportunity. Two numbers, one meeting, and the agent loses permanently. Agents must be required to declare which semantic model or curated views they bind to, and installation should fail loudly when those objects are absent rather than silently falling back to raw tables. The agent that agrees with the executive dashboard gets adopted; the one that contradicts it gets uninstalled that week, and no amount of model quality recovers from that first contradiction.

Related questions

Does an agent marketplace require new Snowflake infrastructure?

Largely no. Native Apps handles packaging and install, Snowpark Container Services runs long-lived planner loops, and Cortex Agents supplies orchestration primitives. The genuinely new work is a listing type, an agent discovery taxonomy, a required telemetry schema, and an approval primitive.

How should agents be priced on a marketplace?

Publish a small set of SKU templates — per-token, per-task, per-outcome — and require partners to choose one. Per-outcome pricing converts an AI purchase into unit economics procurement already understands. Pair any model with an admin-set spend ceiling.

What stops an installed agent from seeing restricted data?

Horizon masking and row-access policies apply at the object level, so an agent running under a role sees exactly what that role sees. Tool-level grants at install time further limit which objects the agent may read or write.

Why not launch a separate agent storefront for marketing impact?

A separate storefront duplicates install, billing, and certification while splitting hard-won discovery traffic. Partners facing two listings usually publish to one. The narrative gain is short-lived; the funnel and field-confusion costs persist.

Who is the actual buyer for a data-native agent?

Frequently RevOps, finance operations, and support operations teams rather than data engineering. They own the use case and the budget but not infrastructure appetite, which makes install-into-your-own-account distribution the only shape that reaches them.

FAQ

Would partners have to build agents differently from regular Native Apps? Not fundamentally. An agent is a Native App that additionally declares a planner configuration, a tool catalog, and telemetry conformance. Existing container services, secure views, and data integrations carry over, so a partner already shipping a Native App is mostly adding a manifest section and an eval run rather than rewriting their product.

How would existing Marketplace users experience the change? They would see agent categories and an agent badge alongside data and application listings, with the same click-to-install flow they already use. The consent screen gains tool-level grants so an admin can see exactly which objects an agent reads and writes before approving anything.

What prevents an agent from generating a surprise bill? Platform-level controls rather than partner promises: an admin-set spend ceiling per install, a hard cap on planner iterations per run, and a suspend switch that stops execution without uninstalling. These should be enforced by the runtime and displayed as guarantees on every listing page.

How do buyers compare two competing agents? Only if telemetry is mandatory. A required run schema — run id, version, tools called, tokens, credits, latency, declared outcome — makes cross-agent comparison a query. Pair that with a published benchmark harness and eval set so listing-page scores are reproducible rather than vendor-supplied.

Is a first-party-only agent gallery a reasonable first step? Only with a published timeline for opening it to partners. Shipping first-party agents proves the runtime and telemetry contract quickly, but a gallery with no partner path signals a closed platform and pushes ecosystem investment toward competing frameworks.

What is the biggest adoption risk once agents are live? Semantic mismatch. An agent that queries raw source tables will contradict the governed dashboards executives already trust, and it loses that argument permanently. Requiring agents to bind to a declared semantic model or curated views — and failing installation when those objects are missing — is the mitigation.

Sources

• https://docs.snowflake.com/en/user-guide/native-apps/native-apps-about
• https://docs.snowflake.com/en/developer-guide/snowpark-container-services/overview
• https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents
• https://other-docs.snowflake.com/en/collaboration/collaboration-marketplace-about
• https://docs.snowflake.com/en/user-guide/security-column-intro
• https://www.databricks.com/blog/announcing-mosaic-ai-agent-framework-and-agent-evaluation
• https://www.salesforce.com/agentforce/
• https://learn.microsoft.com/en-us/microsoft-copilot-studio/
• https://www.servicenow.com/products/ai-agents.html
• https://investors.snowflake.com/

Related on PULSE

• [Should Outreach launch its own AI agent marketplace?](/knowledge/q1785)
• [Should Datadog launch its own AI agent marketplace?](/knowledge/q1725)
• [Should ServiceNow launch its own AI agent marketplace?](/knowledge/q1665)
• [Should Salesforce launch its own AI agent marketplace?](/knowledge/q1555)
• [Should Snowflake launch its own foundation model?](/knowledge/q1600)
• [Should Salesforce launch its own foundation model?](/knowledge/q1551)