Build a Sigma agent that plans a request, grounds it in governed data, and hands back an answer someone besides its builder can verify — not just one that returns a fast guess.
Getting an answer has never been the whole job. A real request gets planned into something precise, explored against context, verified against the underlying data, acted on, and shared with whoever needs it next. A model pointed straight at a warehouse can do the first of those things. The rest is what an agent needs a governed platform underneath it to do at all.
That's what a Sigma agent is: the same governed, warehouse-native architecture that already makes Sigma trustworthy for a person to work in directly, put behind a conversation. It reads through the same object model as every other Sigma element, so what an agent can see and do is exactly what you've already governed — no separate model, no separate rules to maintain.
A Sigma agent can be reached five different ways — a manual trigger, a chat window, a schedule, a REST API call, or another agent over MCP — and every one of them lands on the same governed core: the same data connection, the same write-back audit trail, the same tools, no matter which door you walked through.
This QuickStart demonstrates the door most people start with: chat — but not the chat window built into Sigma Assistant. Sigma Assistant is Sigma's built-in way to ask questions of your data; the agent you'll build here is a separate, named object you configure yourself, with its own data sources and its own instructions, that happens to also be reachable through a chat window, alongside a schedule, an API call, or another agent over MCP.
We will build a Sigma agent from the ground up — attach it to a data source, write the instructions that scope what it's allowed to do, and have a conversation with it to see how it decides what to do with a request before it answers.
Along the way you'll learn how to:
- Create a Sigma agent and attach a governed data source to it
- Write instructions that scope what an agent can and can't do
- Test an agent in a chat conversation and read how it reasons through a request
- Recognize where this agent could go next — the tools, actions, and entry points covered later in this series
For more information on Sigma's product release strategy, see Sigma product releases
If something doesn't work as expected, here's how to contact Sigma support
Target Audience
The typical audience for this QuickStart includes Sigma workbook authors and admins who want to move from viewing AI-generated answers to building the agent that produces them.
Prerequisites
- Any modern browser is acceptable.
- Access to your Sigma environment with permission to create and manage agents.
- A workbook or data model you can attach as a data source — no warehouse-specific setup is required for this QuickStart.
- Some familiarity with Sigma is assumed. Not all steps will be shown, as the basics are assumed to be understood.
Every Sigma agent needs something to reason over. Before building the agent itself, let's give it a home — a workbook — and a data source it's allowed to see.
Create a new workbook
From Sigma Home, click Create New and select Workbook.
In the top left, click Save as and name it:
My First Sigma Agent - QuickStart
Add a data source to the page
From the element bar at the bottom, add a Table element from the Data group, and connect it to:
BIG_BUYS_POS
from Sigma Sample Database > RETAIL > BIG_BUYS.
Rename the table element to something identifiable:
Agent Source Data
Rename the page from Page 1 to Data.
Click Publish:
The workbook has a data source now. This is where the agent that reasons over it gets built.
Open the Agents panel
Click a blank area of the canvas to deselect any element. In the right panel, click the Agents tab.
You'll see "No agents have been created yet."
Create a new agent
Click the + button to create a new agent.
Click the pencil icon and change the default name from (Agent 1) to:
My First Agent
Add the data source
Under Data sources, click Add data source (+). Select Elements > Data > Agent Source Data — the table added in the previous section.
Write the instructions
Click the Instructions tab and enter:
You are a retail data assistant. Answer questions using Agent Source Data — orders, products, regions, and sales figures.
When responding:
- Be concise and specific
- Reference exact figures from the data, not estimates
- If a question can't be answered from Agent Source Data, say so rather than guessing
Set a greeting
Click Greeting, enable Fixed, then enter:
Ask me about the retail data in Agent Source Data — orders, products, regions, or sales.
Save the agent
Click Save.
My First Agent now appears in the Agents panel, with a data source and instructions attached — ready to connect to a chat element.
The agent exists, but nothing on the page can talk to it yet. A chat element is the interface — the agent underneath is the same one you just built, no matter how many chat elements end up pointed at it.
Add the chat element
Click + next to the page tabs to add a new page, then rename it from Page 1 to:
Chat
On the new Chat page, add an element from the element bar at the bottom: click UI > Chat.
Connect it to the agent
Click the chat element to select it. In its configuration, select the agent to power it:
My First Agent
Publish and ask a question
Click Publish. In the published view, use the chat element to ask:
How many orders are there for the Computers product type?
The agent greets you on the way in:
The agent reads Agent Source Data, answers using only what's in that table:
We can check this value by setting a Summary calculation on the Agent Source Data table on the Data page, and filtering it for Computers. If you do this, be sure to remove the filter when done.
Test the boundary
Let's try asking for something the data can't actually support:
Did a recent marketing campaign drive the increase in computer sales this quarter?
Agent Source Data has no marketing or campaign columns — nothing about a campaign exists in BIG_BUYS_POS to confirm or deny.
An agent following the instructions from the previous section says it doesn't have that information instead of guessing. If it answers as though it does, that's a sign the instructions need to be more explicit about the boundary, not a sign the agent is being helpful.
You've now built and tested a Sigma agent end to end — data source, instructions, greeting, and a chat element that puts it in front of a user. Everything later in this series adds a new capability to an agent built exactly this way.
We built a Sigma agent from nothing — a data source, a set of instructions, a greeting, and a chat element to put it in front of a user — and then tested that it actually stays inside the boundary we gave it instead of guessing past it.
Core concepts
- An agent is a configured object, not a chat window — the chat element you added is just one door to it; the agent itself is a separate, named thing with its own data sources and instructions, reusable behind a schedule, a REST API call, or another agent over MCP, the other doors from the Overview. That's different from Sigma Assistant, which doesn't require a custom agent as a data source the way agents do.
- Data sources are the governance boundary — an agent can only see what's explicitly added to it, nothing else in the connection and nothing else in the workbook
- Instructions are scope, not a suggestion — a well-written boundary is the difference between an agent that says "I don't have that information" and one that quietly invents an answer
Key takeaways
The data source list is the real security model:
- Whatever isn't added as a data source doesn't exist from the agent's point of view
- This is the same governance a person already works inside — the agent doesn't get separate rules
- This QuickStart used a plain table to keep the first build simple. For an agent you're putting in front of other people, attach a Sigma data model instead — the same governance boundary, plus curated columns, defined metrics, and any row- or column-level security already built into the model
A weak boundary looks fine until you test it correctly:
- An open-ended "why" question can get answered honestly from real data without ever proving the agent respects its instructions
- The real test is asking about something structurally absent from the data — that's what actually separates "grounded" from "guessing"
The chat element and the agent are independently reusable:
- One agent can power chat elements on multiple pages within the same workbook, or several at once
- Swapping which agent a chat element points to changes what's behind the same door, without touching the door itself
Next steps
This is QS #1 in Sigma's Agents series. Everything after it adds one new capability — a warehouse agent as a tool, an MCP server, an external API call, write-back actions, persistent memory, a Python calculation, or a schedule — to an agent built exactly the way this one was.
Explore the rest of the Agents series.
For more on agent configuration, see Build agents.
Additional Resource Links
Blog
Community
Help Center
QuickStarts
Be sure to check out all the latest developments at Sigma's First Friday Feature page!
