Tool autonomy levels: when the agent should ask before posting

The first question every BC practitioner asks about AI is some variation of: can it post something I did not approve. The second is: how do I prove what it did afterwards. Smart Agents answers both with four layers of control. None of the layers is novel on its own, and that is the point. The novelty is that they compose into a story compliance can read end to end without leaving Business Central.

LAYER 1: TOOL SCOPING

The agent can only invoke tools that are declared on its template. Tools live as rows in the Smart Agent Tool Link table. When you configure a template (or a custom agent) you pick which tools it exposes. The agent's system prompt can describe capabilities the template did not grant, but the runtime in the SA Tool Call BG Runner rejects any call outside the declared set with a recorded denial in the audit log.

This is the narrowest knob and the cheapest one to use well. A statement-generation agent that never needs to touch inventory should not have inventory tools enabled. The shipped templates often arrive with broader scopes than a tenant actually needs because they are designed to be useful out of the box; trimming them is a five-minute job per agent that pays back every audit. The Smart Agent Tool Configs page lets an admin enumerate the tools, see which agents reference which configs, and disable tools at the config level for the entire tenant if the customer's policy says so.

LAYER 2: AUTONOMY LEVELS

Autonomy controls what the agent does once it has picked a tool. There are three levels we see tenants use in production.

The first is read-only. The agent can query and summarize but never write. This is the right default for new deployments where the team is still learning what the agent does and how often it gets things right. Most tenants spend the first week here.

The second is ask before write. The agent assembles the write (the journal entry, the emailed statement, the exported report) and posts a preview to the user. The user clicks Confirm to commit. This is the default for any template with write tools enabled, and it is what nine out of ten production agents stay on indefinitely. The user reads the preview, sees what is about to happen, and approves it; the audit log captures both the preview and the approval.

The third is execute. The agent completes the write without confirmation. This is reserved for low-risk tools like drafting an email into the user's outbox (the email is not sent until the user opens Outlook and clicks Send) or exporting a PDF to the user's folder. We do not recommend execute autonomy for anything that posts to a ledger.

The autonomy level lives on each agent record (Smart Agent), not on the tenant. A read-only reports agent and an execute-level email-drafter can coexist in the same tenant without any conflict. The important rollout move is to default new agents to ask-before-write and let each power user earn execute rights one workflow at a time. Every tenant that flipped everything to execute on day one regretted it by day three.

LAYER 3: USER-SCOPED SESSIONS

Every conversation runs inside the BC session of the user who opened it. The Smart Agent Session table carries the user ID. When the chat engine submits a message, the tools execute through the BC API gateway under that user's permission set, company filter, and dimension access. If the user cannot post to a restricted G/L account, the agent cannot either. Not because Smart Agents added a rule on top, but because BC returns the same permission denial it would to any other client.

The phrase we use internally is "the agent can never do more than the user." In practice this means you do not have to build a parallel permission model for the AI. You inherit the BC one, which the customer's IT team already manages. Sub-agent delegation keeps the same envelope: a sales agent that hands a question to an inventory sub-agent passes along the same user context. There is no privilege escalation through delegation because there are no elevated credentials to escalate into.

This matters for GDPR. It matters more for internal review. When compliance pulls the audit log, each row has a real BC user, not a generic system account.

LAYER 4: AUDIT TRAIL

Every tool invocation lands in the SA Tool Call Log table with the user, the timestamp, the agent, the model tier, the tool, the parameters, the data scope touched, 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 can alert on them.

Default retention is 365 days, configurable up to 7 years on the Smart Agent Setup record. The log is populated synchronously: if the audit write fails, the tool does not execute. That is the same reliability contract as the regular BC change log, which compliance has accepted for years. They do not need to accept a new one.

Export the log as CSV from the SA Email Log and Tool Call Log pages, or query it via the SA Tool Call Log API page for integration with an external SIEM. Filter by user when HR asks. Filter by agent when you are tuning cost. Filter by tool when you are investigating a specific kind of write.

A WORKED EXAMPLE: MONTH-END STATEMENTS

Think about a statement-generation agent built from the Sales Invoice Manager template. Tool scoping limits it to three tools: read customer, format statement, draft email. Autonomy is ask-before-write on the email step; the agent shows the user a preview of every email before it is sent. Sessions are the AR clerk's, so only customers she can already see in BC are visible to the agent. The audit log shows who ran what against which customers, in which company, at what cost, and whether the email was approved.

Each layer alone is weak. Tool scoping without audit is unverifiable. Audit without autonomy lets the agent do surprising things very fast. Autonomy without user-scoped sessions lets the wrong user approve the wrong thing. All four together, all enforced inside BC by the AL extension, are what lets compliance sign off and what lets the IT lead leave the meeting without an action item to disable the integration.

A SECOND WORKED EXAMPLE: VENDOR 360 DEEP DIVE

Consider an agent built from the Vendor 360 View template (the templates module line 66). A buyer is investigating why a vendor's deliveries have been late three months running. Tool scoping limits the agent to read tools for vendor records, purchase orders, receipts, vendor ledger entries, and payments; no write tools are enabled because the agent's job is investigation, not action. Autonomy is moot for a read-only agent.

The buyer types: "Show me everything about vendor V-1042 for the last six months and flag any patterns." The agent runs four tool calls in sequence: vendor card read, PO history, receipt history, payment history. Each call lands in the SA Tool Call Log with the buyer's user ID, the timestamp, the tool name, the data scope (vendor V-1042), the model tier (Smart by default), and the credit cost (about 1.2 credits total for the four lookups plus the final summary).

The agent returns a summary: receipts have averaged 4.2 days late since June, the vendor has 14 outstanding POs, and three of the last five payment runs were delayed on the buyer's side. The buyer now has a defensible story to take to the vendor and to the AP team. Six months later, when the same buyer is challenged on a procurement decision, the audit log proves the analysis happened and shows what data informed it. That is the compose-it-all loop.

DEFAULT VS RECOMMENDED CONFIGURATION

For a fresh tenant we recommend the following: leave Smart as the tenant-default model tier, set new agents to ask-before-write autonomy, narrow the tool scope on every customized template before activation, and grant SMART AGENTS ADMIN to a single named admin (not the BC SUPER role). The Smart Agent Setup table carries the tenant defaults and any deviation should be approved at a Smart Agents steering meeting, not by the agent author alone. Most pilots that hit governance problems hit them because someone widened a default without telling the rest of the team.

For more on the underlying architecture, see the related blog post on why Smart Agents lives inside BC, and /docs/admin for the permission set walkthrough.