Why Smart Agents lives inside Business Central, not on top of it

When we started Smart Agents, the easy path was obvious. Ship a SaaS product, connect to Business Central via web services with one shared service account, build a slick UI on top, and call it integrated. It would have demoed well. We did not take it. The reason is that the architecture you choose on day one decides every governance conversation you ever have afterwards, and the bolted-on path loses every one of them.

THE SERVICE ACCOUNT PROBLEM

A chatbot that talks to BC through a shared service account has exactly one permission profile: whatever that account can touch. Ask it to generate a customer statement and it will. Ask it to post a journal and, unless you added a hand-rolled guard, it will do that too, for any user, in any company, at any amount. That is not an AI problem. It is an architecture problem. You cannot layer governance on top of a surface that already has too much reach.

The day an auditor asks who posted the November accrual, the answer becomes some variant of "the bot, on behalf of someone, we think." Compliance does not accept "we think." CFOs do not accept "we think." The conversation ends with an exception in the audit report and an action item to disable the integration.

THE EXTENSION PATH

Smart Agents ships as an AppSource extension. The publisher ID is QUALIA Technik GmbH and the extension ID is 776a67fc-e35b-45f7-8e97-ec0bc6cb9077, registered in the app manifest with the brief "Talk to your ERP. It understands." It runs on Business Central 26.0.0 in the cloud and on tested on-premises deployments. The extension installs into BC like any other AppSource app, claims the object range through , and brings its own permission sets named SMART AGENTS USER and SMART AGENTS ADMIN.

When the AR clerk opens the Smart Agent Chat page, the chat session belongs to her, the underlying Smart Agent Session record carries her user ID, and every tool invocation runs inside her BC session. If she cannot post to G/L account 6100 because her permission set says no, the agent cannot either. Not because we wrote a middleware rule that says so, but because the codeunit Smart Agent BC API Gateway calls BC the same way any other client would, and BC returns the same permission error it would have returned to a manual user.

We call this "the agent can never do more than the user." It is not a tagline. It is what falls out when you put the agent inside the permission boundary instead of next to it. The behaviour you get for free includes company filters, dimension restrictions, and posting-group rules. None of those need to be re-implemented. The agent inherits them.

TOOL SCOPING IS A FIRST-CLASS CONCEPT

Inside BC, every tool an agent exposes is a declared object. Look in the Smart Agent Tool Link table and you can enumerate exactly which tools each agent is allowed to call. Run aged receivables, draft an email, export to Excel, post a payment journal, look up a stock balance, send a customer statement. Each one is a row, not a string in some prompt the AI might or might not honour.

That means you can allowlist tools per template, you can turn write tools off for a given agent and leave only read, and you can audit the tool surface at any time without reading the system prompt. When a BC admin opens the Data Access subpage on a Smart Agent card, they are looking at actual BC tables and actual tools, not a vendor-specific abstraction layer.

Compare that to screen-scraping or RPA. A typical bolt-on flow records the click path through Customer Ledger Entries, exports a CSV, and parses it. It works on Tuesday. On Wednesday the page changes in the next BC wave update and the flow breaks at 03:00 in the customer's tenant. Tool-level integration via the AL gateway survives those wave updates because the gateway uses BC's stable AL APIs, not the rendered DOM. It also produces audit data BC understands natively, which leads us to the next point.

AUDIT IS NOT AN ADD-ON

Every tool call lands in the SA Tool Call Log table with the BC user, the timestamp, the agent, the tool name, the parameters, the result size, the model tier, the token counts, the credit cost, and the outcome. The Smart Agent Telemetry codeunit emits the same events to Application Insights so the customer's monitoring stack picks them up alongside the rest of their BC telemetry. Default retention is 365 days, configurable to 7 years for tenants under regulatory obligations.

This is not a best-effort log file written into a vendor SaaS. It is a BC table written synchronously: if the log write fails, the tool does not execute. Compliance teams sign off on this pattern because it is the same reliability contract as the regular BC change log. They have already accepted it for the rest of their ERP. They do not need to accept a new one for the agent.

WHAT THIS COSTS US

Inside-BC is harder to build. We write AL. We ship through AppSource and live with its review cadence. We version alongside BC cumulative updates, currently at the current version against Business Central.0.0. On-premises tenants need a signed .app file. The tradeoff is that the product does the work in the place the user already trusts with their ledger, with the permission model the user already manages, in the audit log the user already reads.

The alternative, an external agent that pretends to be integrated, works fine for demos. It does not work when the CFO asks who posted the November accrual, when the external DPO asks where customer PII went, or when the auditor needs a query to prove that a certain G/L combination was never touched by the AI for the entire fiscal year. Those questions get short, accurate answers from the audit log table on day one. They do not get those answers from a SaaS chatbot connected to BC through one service account.

For consultants evaluating Smart Agents for resale: the in-extension architecture is the part of the product that makes the rest of the product saleable to risk-averse customers. The chat UX is fine. The 32 templates are useful. The one thing that turns evaluations into signatures is the answer to "how do we prove what it did," and that answer ships in the AL extension, not in the marketing slides.

A WORKED SCENARIO: THE NOVEMBER ACCRUAL

A short scenario makes the architecture concrete. The CFO of a wholesale distribution tenant asks her controller, in early December, to identify every AI-generated entry that touched the November accrual G/L accounts. In the bolt-on world this question takes a week: open a ticket with the SaaS vendor, wait for them to dump their log file, parse it, hope the timestamps line up with the BC posting dates, and present a partial answer with a disclaimer.

In Smart Agents the answer takes about three minutes. The controller opens the SA Tool Call Log page in BC, filters by tool name = post-journal and date = November and G/L account = the accrual range, exports to Excel, hands it to the CFO. Each row carries the BC user who initiated the chat, the agent that ran the tool, the parameters of the journal entry, the credit cost, and a session ID that links back to the full chat conversation. The controller can pull the conversation for any flagged row by filtering the Smart Agent Message table by session ID and walk the CFO through what the user asked the agent to do.

The answer is not partial. It is not approximate. It is a BC table the controller already knows how to query, exported in a format the CFO already knows how to read. The conversation moves on to the next agenda item.

If you want to see this in practice, see /docs/admin for the permission set walkthrough, /docs/getting-started for the install steps, and the related blog post on tool autonomy levels for how the layered controls compose at runtime.