How to build an agentic application with Fabric and Foundry

Fabric has three places that speak T-SQL, and they differ on one point that matters here:

Pick SQL database in Fabric and something happens that simplifies your architecture: the data is replicated into OneLake automatically and stored there in Parquet, ready for analysis. A SQL analytics endpoint is created for you at the same time, and that endpoint is read-only over those same mirrored files. So you don't need a copy pipeline to query operational data analytically.

Route A, the Fabric data agent. In Fabric you build a data agent over your Lakehouse, Warehouse, semantic models or KQL databases, publish it, and attach it in Foundry as a tool on your agent. The translation from question to SQL, DAX or KQL is built in. The important part is stated outright: the integration uses identity passthrough, on-behalf-of, and the tool runs queries under the identity of the signed-in user. Row-level security and permissions in Fabric keep applying, without you building anything for it.

Three conditions come with it. This route is preview, so no SLA and not recommended for production. Every end user needs access to the data agent and to the underlying sources themselves, or the tool call fails. And service principal authentication is not supported: it has to be a user identity.

Route B, your own tool. You write a function that runs SQL and register it with the agent. Full control, production-ready today, and it works with a service principal or managed identity. Except that every query then runs under that one identity. Row-level security still works, but on the rights of the service principal, not on those of the person asking. Two users get the same answer, even when they are allowed to see different data.

Curated views are the cheapest form. One view carrying exactly the columns the agent needs, in a schema of its own, is easier to govern than twenty tables with joins between them:

CREATE VIEW agent.SalesData AS
SELECT
    t.TransactionDate,
    c.CustomerName,
    c.Country,
    p.ProductName,
    p.Category,
    t.Quantity
FROM dbo.Transactions AS t
JOIN dbo.Customers AS c ON t.CustomerId = c.CustomerId
JOIN dbo.Products AS p ON t.ProductId = p.ProductId;

Underneath sits the tooling Fabric already ships: row-level security filters rows per identity, object-level security keeps whole tables or columns out of reach, and dynamic data masking masks what may be counted but not read.

Mind the order: masking and filtering belong in the database, not in the prompt. An instruction saying "do not show salaries" is a request to a model. A security policy is a rule the model cannot route around.

The model has to support function calling, and not every model in the catalogue does. The limits page carries a matrix stating per model whether functions are enabled. Two numbers on that same page touch your design: an agent may register at most 128 tools, and rate limiting happens not on the agent but on the model deployment, so in tokens per minute.

If you build in code, the Microsoft Agent Framework is the direction Microsoft points to for new work, as the successor to AutoGen and the Semantic Kernel Agent Framework. It is preview, and you install the packages as prerelease. In the same move, workflows in Foundry are being retired on 1 December 2026.

You are an assistant for company data about sales, customers and products.

Use the available data tools whenever a question asks for company data.
Never invent data.
If the information is missing, say explicitly what you are missing.
When you state a number in a sentence, show how it was calculated.

The tool around it gets hard limits, and you put those in code and not in the prompt. Refuse anything that writes (INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE), allow only the schema your view lives in, and cap the number of rows. Combine that with a read-only user in the database: the first limit is a check you wrote yourself, the second is a right the agent simply does not have.

For the connection from your API there is a worked route from App Service to a SQL database in Fabric using a managed identity, system-assigned or user-assigned. That leaves no password anywhere in a configuration file.

One step is nearly always forgotten and otherwise costs an afternoon: at tenant level, the setting for service principals using Fabric APIs has to be on. That is an administrator action, not a developer action, so ask that question early.

Do check the label. Tracing is generally available for prompt agents and hosted agents; for workflow agents and external agents it is preview, and so is monitoring with dashboards and alerts. That difference belongs in your design, because it decides what you may lean on today.

And consider what you are recording: prompts and answers are data themselves, often with company information in them. They belong under the same retention and access rules as the rest.