Snowflake Cortex Agents: build and test a data assistant

Snowflake Cortex Agents↗ (opens in a new tab) lets you build an assistant that plans requests and calls configured tools over governed data. Start with one job, add the tools needed for it, and test the answers and permissions before widening the scope. A working response is only the beginning; you need evidence that the response is useful and supported. fenbs can keep your test questions, accepted definitions, and remaining checks available for the next development session.

For example, build an assistant that explains a weekly operations measure using an agreed definition. Do not start with “answer anything about the business.” A narrow job lets you identify the right data, choose known answers, and decide when the assistant should ask a person instead of inventing a conclusion.

How do you create the first agent?

Snowflake’s getting-started tutorial↗ (opens in a new tab) documents Snowsight → AI & ML → Agents → Create agent. Add sources in Tools, enter instructions in Orchestration, and select Save. The tutorial uses ACCOUNTADMIN for its setup. Treat that as a prerequisite for that example, rather than a rule that every future caller should be an account administrator.

1. Write the assistant’s job and the questions it should decline or pass to a person.
2. Identify a small approved source and an owner who can verify its meaning.
3. Create the agent and configure only the tool access needed for the first question.
4. Add instructions that define the output and how to handle missing evidence.
5. Run a known example, inspect the answer, and record the result before adding more sources.

Keep the first example simple enough to check by hand or against an established report. If several sources disagree, resolve the disagreement with their owners before teaching the assistant a preferred answer. Otherwise, you are testing whether it repeats your preference rather than whether it answers accurately.

Which tools should the assistant receive?

Snowflake documents tools including Cortex Analyst, Cortex Search, code execution, custom functions or procedures, and remote MCP connectors. An agent without configured tools cannot query account data, according to the Cortex Agents documentation↗ (opens in a new tab). Choose tools by the question they need to answer, rather than adding everything because it is available.

For a first version, write a sentence explaining why each tool belongs. A measure question needs an approved way to obtain the measure. A policy explanation needs the relevant written source. A tool that changes another system needs a separate reason and a clear point where a person reviews the intended change.

Remote tools add an administration task. Snowflake’s MCP connector guide↗ (opens in a new tab) describes an API integration, an external MCP server object, agent configuration, and user authorization. MCP is a standard for letting AI apps use outside tools. This setup brings tools into the agent; the Snowflake MCP server workflow exposes Snowflake tools to other assistants.

What instructions make results easier to evaluate?

Give the assistant a narrow responsibility and an output you can inspect. For the weekly operations example, ask for the measure, reporting period, source reference, and unresolved limitations. Require a clear distinction between an observed change and a proposed explanation. A format like this makes unsupported reasoning visible.

• Use the agreed definition of the measure and ask when that definition is missing.
• State the reporting period and population before interpreting a result.
• Support conclusions with the relevant available evidence.
• Say what could not be established instead of completing the answer with a guess.
• Stop before actions that the responsible person has not approved.

These are proposed instructions, not guarantees about behavior. Test each one with a question that could expose a failure. If you instruct the assistant to distinguish a fact from an explanation, include an example where the data shows a change but says nothing about the cause. Save human-approved definitions in fenbs’s Decisions and rules so another assistant does not reopen them by accident.

Which test questions should you run?

Build a small evaluation set, meaning questions with reviewed expectations. Include normal requests, unclear requests, missing information, and requests outside the intended job. Record the question exactly as asked and the evidence needed to accept its answer. Do this before refining the assistant repeatedly against one easy example.

Repeat the set after changing a source, instruction, or tool. Check whether an improvement on one question damages another. A useful test record states what changed, which questions were rerun, and which results a person reviewed. Browse AI at work for other ways to turn generated output into work that can be checked.

How do you test access without weakening it?

Snowflake documents caller roles, privileges on the agent, and privileges required by its tools. Tool execution context matters; an inaccessible tool does not mean the agent has gained elevated rights. Consult the Cortex Agents guide↗ (opens in a new tab) when checking the intended caller. Test with a representative user instead of accepting a successful administrator run as proof for everyone.

Use approved examples for both allowed and denied requests. Record the role used, the expected outcome, and the actual outcome without copying confidential data into a test log. If the denial is unexpected, identify the missing operation and ask the owner to review it. Do not solve a narrow test failure by granting unrelated access.

Also separate an application experience from its underlying agent. The Snowflake Intelligence article covers asking and checking business questions. The Cortex Code article covers development work. Those are different jobs even when they contribute to the same assistant.

What should you save before changing the assistant again?

Save the current purpose, configured tool list, approved definitions, and the exact test questions with their reviewed outcomes. Mark unreviewed answers clearly. Name the next change and the check it is meant to improve. This stops a future session from mistaking a promising draft for an accepted version.

Keep the record small enough to read before work starts. “Two ambiguous questions still produce assumptions; ask the owner to review the wording” is a useful stopping point. “Testing complete” is misleading if you checked only ordinary questions. The next assistant needs your evidence and limits, not just your confidence.

How to keep agent tests with fenbs?

Keep the questions you tested, the outcomes someone checked, and the next improvement. You can carry on from that same point on any device and in another connected AI without losing the reasons behind a change.

1. Create a free account.
2. Add a task for the assistant’s next improvement. Write the question it should answer and the examples you will use to check it.
3. Connect Snowflake Cortex Agents to fenbs using Integrations, with the remote connection configured and approved by your administrator.
4. Save the questions, checked outcomes, and mistakes worth avoiding. Save the definitions a person approved so the next AI knows which meanings to use.
5. Save where you left off and the next check, so your next connected AI can continue on any device without losing the work.

fenbs keeps the work between sessions. It does not replace the agent runtime, perform Snowflake access checks, or judge the truth of a generated answer. Keep sensitive test data in its approved environment and save only the references and conclusions permitted outside it.