Snowflake Cortex through FDE job ads: what Cortex Analyst, Cortex Search and Streamlit are for

Snowflake once advertised a role titled “Forward Deployed Engineer - Finance Analytics & AI Specialist”. The posting closed on 8 July 2026. The products it named were Cortex Analyst, Cortex Agents, Cortex Search, Cortex Code and Snowflake CoWork.

More telling than the product list was the description of the work: building and improving semantic models so that users can query a customer’s data tables in natural language through Cortex Analyst.

That detail shows that much of an FDE’s work sits in the layer that gives data its meaning, and less of it in the LLM itself.

If you plan to apply for an FDE role around a data platform, at Snowflake or elsewhere, understand the three tools below and how they fit together, rather than memorising a feature list.

Each tool is for a different kind of question

Snowflake’s documentation describes Cortex Analyst as a fully managed, LLM-powered Cortex feature for building applications that answer business questions on structured data. It is offered as a REST API, so it can be embedded in any application. For it to understand the data, you have to supply a semantic model.

Cortex Search handles a different kind of question. It is a hybrid search service, combining vector and keyword search, that runs over text data and supports low-latency fuzzy search.

According to the documentation, its two main uses are RAG and enterprise search. Contracts, emails and reconciliation notes go to Cortex Search; numbers held in tables go to Analyst.

Streamlit is an open-source Python library for building web apps. Streamlit in Snowflake lets you build, deploy and share these apps inside Snowflake, so the data never has to leave. The job ad states that the FDE will build finance, operations and analytics dashboards as Streamlit apps running natively in Snowflake. These are production dashboards, not just demos.

The semantic model is the real product

According to the documentation, a Cortex Analyst semantic model is written in a lightweight YAML file. For new deployments, Snowflake recommends Semantic Views. YAML files placed on a stage are still supported.

A semantic view is a schema-level object with four components: logical tables, dimensions, facts and metrics. Snowflake defines a metric as a quantitative measure of business performance.

Imagine the finance team asks: “What was net revenue by region last quarter?” Suppose the customer has an orders table and a regions table. The logical tables are those two tables; the dimensions are region and quarter; the facts are the amount, refund and discount on each order line; and the metric is net revenue.

The hard part is the metric. Sales may treat net revenue as total order value, while accounting subtracts refunds and discounts. The sketch below only illustrates how that definition is written into the model. It is not exact syntax; look up the specific field names in Snowflake’s spec.

# Illustrative sketch, not exact Snowflake syntax
logical_tables:
  - name: orders
    dimensions: [region, quarter]
    facts: [amount, refund, discount]
metrics:
  - name: net_revenue
    description: "Total order value minus refunds and discounts, per the approved accounting definition"
    expr: SUM(amount) - SUM(refund) - SUM(discount)

Without the expr and description lines that accounting has agreed to, the model still generates SQL but has to guess what the questioner meant. The result is an answer that looks plausible and is still wrong.

So when you arrive at a customer, the first job is to sit with the finance users and write out each metric’s definition in words, and only then open the editor.

The job ad says the FDE will work onsite with the customer’s team to clear deployment blockers as they come up. A session to settle metric definitions with users is a textbook example of that kind of blocker.

Evaluate from the start

Another role, “Forward Deployed Engineer, Applied AI”, sat in the Cortex AI team; that posting has also closed. The hire would build production AI systems on Snowpark and Cortex and spend at least 25% of their time onsite with Snowflake’s most strategic customers.

The ad also stressed that evaluation must be a core part of the build, not something left for later.

For Cortex Analyst, the most direct way to evaluate is to compile a set of sample questions, each with an answer SQL approved by the finance users. Every time you change the semantic view, you rerun the whole set and compare results.

Go back to the net revenue example. If the set includes that question, with an answer that subtracts refunds and discounts, a definition error shows up on the first run instead of surfacing in a meeting with the CFO.

Limits and what to learn first

The first limit is the boundary between the tools: Analyst works on structured data, Search on text. The job ad also names Cortex Agents in the same product suite; if a customer asks questions that need both tables and text, that is the next thing to read up on in the documentation.

The second limit is that answers are only as good as the semantic model allows. When the model answers wrongly, check the definitions before suspecting the LLM.

As for learning order, start with SQL and data modelling, to the point where you can tell dimensions, facts and metrics apart on a real dataset. Then learn enough Python to build a Streamlit app, then RAG and hybrid search to understand Cortex Search.

On your CV, instead of writing “knows Cortex”, describe a semantic model you have built: how many metrics it has, how many questions are in its test set, and how much the correct-answer rate rose after each revision.

Snowflake puts its AI tools right next to the data. So the people hired for these roles are the ones who can explain what a customer’s tables mean.