Decision models offer a new fast-path for knowledge agents; rather than using a reasoning model for every question, the agent can use a decision model to provide the original source to the user rather than generating text.

Take a fictional help-desk agent as an example:

“How long are deleted reports retained?”

The support article already answers that: deleted reports stay in Trash for 14 days, then they're permanently removed. A customer asking this question just needs the retention policy, and decision models can provide the stored answer without generating new text for that response.

Illustrative recording of one session on synthetic data with EmbeddingGemma 2. Each timing is a single response, not a benchmark; see End to End Performance for measured medians.

Both the standard RAG and fallback paths use Claude Sonnet 5.5 (claude-sonnet-5-5) through the Cortex Inference Messages API.

Prepare the Knowledge Base: embed each article and link its vector to the original text and ID. Reuse the index across questions, with a separate index for each embedding model. This demo keeps those indexes in memory. In a production system, you can persist the embeddings alongside the article text and IDs in Snowflake® tables using the VECTOR data type, then use vector similarity functions for retrieval. You can also use Cortex Search for managed hybrid retrieval.

Answer the query: embed the question with the matching model and retrieve the three closest articles. A standard RAG always sends the articles to an LLM for generation. Our new system first asks decider-2b to select an article ID or decline. If the decision model selects an article, it can be returned directly; otherwise, the same evidence goes to the LLM.

The decision model in this example is deployed and served on Snowflake ML using the pattern described in an earlier post: Decisions Are All You Need: Run Jev-Class Models on Snowflake.

You can bring your own decision model and serve it on Snowflake ML, as we did with decider-2b, or use a managed model such as Snowflake Decision Fast (private preview). Both options can select stored text or fall back to Sonnet 5.5.

We compared these paths with Snowflake Arctic Embed M v2.0 and Arctic Embed L v2.0, and EmbeddingGemma 2. The table shows median complete-answer times across three embedders and five repetitions per case. Each path retrieved matching evidence, and all generation used the same Sonnet settings. The 135 responses completed without errors or truncation.

When both models selected the stored answer, self-hosted decider-2b was fastest. Managed Decision Fast still returned the complete answer in 356 ms, compared with 1,424 ms for always generating with Sonnet.

The second route shows why answer selection matters as much as decision speed. Managed Decision Fast selected the available article in all 15 calls, while decider-2b fell back in all 15. Avoiding generation brought the managed path's median complete-answer time to 340 ms.

When neither model selected an article, both called Sonnet. The decision step is additional work on that path; variation in generation time means the difference between complete-answer medians is not a measurement of decision-model time alone. These three synthetic cases illustrate the tradeoffs, not general accuracy or cost savings.

Decision models are a new frontier and offer a wide range of possibilities for tasks. In this post, we aimed to show how decision models can offer benefits to agents in addition to the classification tasks that are more commonly discussed. You can choose a model and serve it on Snowflake ML, or use a managed decision model. The architecture stays the same: return stored text when it answers the question, and use Sonnet when generation is needed.