06-reference/research

cortex knowledge extensions vs agent publish

2026-09-24·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
snowflakecortexmarketplace-packagingphdataaccelerators

Cortex Knowledge Extensions vs Publishing a Cortex Agent: Different Layers, Not Alternatives — and CKE Is Not Partner-Gated

The question

Verbatim: "How do Snowflake Cortex Knowledge Extensions (CKE) differ from publishing a Cortex Agent — is CKE strictly the partner path for reusable retrieval content/knowledge, and does an accelerator combine a CKE + an agent template?"

Context: this is open follow-up #3 from [[2026-07-08-cortex-agent-cowork-skill-native-publish]], auto-promoted 2026-07-22. The practical stake is which Snowflake packaging primitive phData should use to ship a reusable accelerator into multiple client accounts.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The premise in the question is off, and correcting it is the finding. CKE and agent-publishing are not two routes to the same destination. They sit at different layers of the same stack. A CKE is one tool a Cortex Agent can be pointed at; the Native App is the container that instantiates the agent and everything it depends on in the consumer's account. Asking "CKE or publish an agent?" is like asking whether to ship a library or an installer. For a phData accelerator, the Native App is the vehicle and a CKE is at most one component riding inside or alongside it. If someone at phData frames these as alternatives in a packaging discussion, that is the thing to correct first.

The partner-gating half of the question is false on the mechanics and true on the narrative, and the gap between those is where the practical risk lives. Nothing documented stops phData from creating a Cortex Search Service over its own content and publishing it as an organizational or private listing. But a public Marketplace CKE enters a channel Snowflake has populated exclusively with licensed content publishers, and a consulting firm listing a CKE there is an untested motion. The low-risk version is unambiguous and available today: a private listing to a single named client account, which is also the recommendation [[2026-09-23-cortex-agent-cross-tenant-marketplace-publish]] reached for the Native App route. Note that I did not verify whether a private CKE listing triggers the same Marketplace Operations review as a public one; the CKE docs are silent on review process entirely, which is itself a gap worth treating as unknown rather than as "no review."

The provider-retains-the-index property is the fact that should actually decide this, and it cuts against CKE for most phData work. In a CKE, the corpus and its Cortex Search index live in the provider's account. That means phData would be hosting, indexing, refreshing, and paying for the content in perpetuity, and every client would be reading from one shared corpus. That is a fine shape for genuinely shared reference material: phData's own published methodology, Snowflake best-practice documentation, an industry regulatory corpus, a curated data-modeling playbook. It is the wrong shape for anything client-specific, because client data cannot be in a multi-tenant provider-hosted index, and it quietly converts a delivery firm into a content-hosting operator with a recurring compute bill and a freshness SLA. It also collides with the finding in [[2026-06-26-cortex-search-compression-strategies]] that Cortex Search exposes no index-tuning knobs, so phData would own the cost without owning the levers.

So the shippable answer for multi-client packaging: Native App is the vehicle; CKE is an optional shared-corpus add-on; and "agent template" stays internal. The accelerator is architecturally a Native App whose setup script creates the agent plus its semantic views, Cortex Search services, procedures and skills inside the client account, where client data stays client-side. phData's Jinja2 agent specs are not a distributable artifact and should not be sold as one; they are the internal generator that produces the app package. A CKE becomes worth adding only when there is a corpus that is identical across clients and that phData is willing to host indefinitely. I would treat that as a separate, later, revenue-justified decision rather than part of the first accelerator. One honest caveat: I did not verify that a CKE installed in a consumer account can be attached as a tool to an agent created by a Native App in that same account. It is strongly implied by the Cortex Agent API listing CKEs as a search parameter, but implied is not verified, and that wiring is the load-bearing assumption if phData ever does combine the two.

Why this is in the vault

This decides how phData packages a reusable Cortex accelerator for multi-client delivery: it rules out CKE as the accelerator vehicle, confirms the Native App as the container (per the 2026-08-07 GA), and reframes CKE as an optional shared-corpus component whose provider-hosted-index property creates an ongoing cost and freshness obligation phData would be taking on. It also retires a false claim already sitting in the vault, that CKE is a partner-only surface.

Open follow-ups

Related

Sources

Primary (Snowflake-owned)

Not used as evidence

Vault