AI concepts for Business Central consultants
This primer explains the ideas behind Smart Agents in plain language, using
This primer explains the ideas behind Smart Agents in plain language, using Business Central things you already know. If you can set up a Job Queue, design a permission set, and configure a report request page, you already understand more about AI agents than you think — the concepts map across surprisingly well.
Read this once before you configure your first agent. Every page manual links back to the terms defined here, and the glossary gives one-line reminders.
1. What is a "Smart Agent"?
A Smart Agent is a configured AI assistant that users talk to in plain language to get work done in Business Central — look up data, create records, run reports, draft emails.
An agent record gathers everything that defines one assistant in a single place. Just as a Role Center + permission set + user setup together decide what a person can see and do, an agent record bundles:
- an identity (name, description, icon) — like a job title,
- a brain (the AI model) — how clever and how expensive it is,
- permissions (capabilities, data connections, tools) — what it's allowed to touch,
- instructions (its standing orders) — how it should behave.
You build agents on the Agent Card. Each one is a separate record in the Smart Agents list, just like customers in the Customer list.
Worked example. A "Finance Helper" agent: model = Smart, can read Customers and Sales Invoices, can run the Aged Accounts Receivable report, instructions say "You help the finance team chase overdue invoices. Always show amounts in the customer's currency." A user types "Which customers are more than 30 days overdue?" and the agent looks it up and answers.
2. The AI model (the "brain") and model tiers
The AI model is the large language model (LLM) that actually reads the user's message and writes the reply. Smart Agents doesn't run the model itself — it calls a backend service that hosts several models. You don't manage raw models; you pick a tier.
A model tier is a named quality/cost level — for example Fast, Smart, Expert, Premium. A faster/cheaper tier answers simple questions quickly; a higher tier reasons better on hard tasks but costs more per message.
You choose the tier that fits the job: higher for hard reasoning, lower to save credits on routine work.
- You see the available tiers on the AI Models page (a read-only cache refreshed from the backend).
- Each tier has a credit multiplier — how many credits it burns relative to the baseline (see credits below).
- You set a tenant-wide Default AI Model in Setup, and can override it per agent on the Agent Card.
How to choose: start every agent on a mid tier (Smart). Move up only if the agent makes reasoning mistakes on real tasks; move down if its work is simple lookups and you want to save credits.
3. Tokens and credits (how you pay)
LLMs read and write text in chunks called tokens (roughly ¾ of a word). The more text that goes into a request — the user's message, the agent's instructions, the data it pulled, its memory — and the more it writes back, the more tokens it uses.
You don't pay in tokens directly. Smart Agents converts usage into credits.
Every message the agent processes draws down your credit balance, scaled by the model tier's credit multiplier (a Premium message costs more credits than a Fast one). You top the balance up, or it's metered — depending on your billing mode below.
Two billing modes exist (set by your subscription, shown on the Credits page):
- Prepaid — you buy a credit balance up front (via Stripe) and draw it down.
- Subscription — usage is metered and billed through Microsoft.
Practical consequences for an admin:
- A stopped request charges no credits — users can safely hit Stop.
- Big instructions, large knowledge files, and high search-result limits all increase tokens per message, so they cost more credits. Keep them lean.
- Track spend per agent under Usage on the Credits page.
4. Instructions (the agent's standing orders / "system prompt")
Instructions are the always-on guidance you write for an agent: its role, tone, rules, and what it should never do. The AI reads them at the start of every conversation, before the user's message.
Much like the defaults on a Customer Posting Group, instructions apply automatically to everything the agent does without anyone re-stating them.
You write them in the rich-text editor on the Agent Card. Good instructions are specific: "Only answer questions about inventory. If asked about payroll, say it's out of scope. Always quantities in base unit of measure."
5. Capabilities — what the agent is allowed to do
On the Agent Card you switch on capabilities. These are coarse on/off gates, like the top-level toggles on a permission set before you get into detail:
| Capability | Plain meaning | Configured in detail under |
|---|---|---|
| BC Data Access | The agent may read/write Business Central data | BC Data Connections + Tool Configurations |
| Knowledge Base | The agent may read documents you upload | Knowledge Files |
| Web Search | The agent may look things up on the public web | — |
| Image Analysis | The agent may "see" images users attach | — |
Turning a capability on only opens the door; the detail pages decide exactly what's behind it. (BC Data Access with no connections configured still does nothing.)
6. Tools and "tool calling" — how an agent acts in BC
This is the most important concept and the one with no everyday equivalent, so read slowly.
A bare LLM can only produce text. To actually do something — read a sales order, create a customer, run a report — it needs tools. A tool is a specific action you expose to the agent: one API page, one table, one report, one web service.
The model decides, in the middle of a conversation, "to answer this I should call
the salesInvoices read tool with a filter on customer X", and the app runs that
call against BC and feeds the result back to the model. This back-and-forth is called
tool calling (or function calling).
A tool configuration is essentially a permission set for the AI — except richer. For each object you add, you decide:
- Read — may the agent look at this data?
- Create / Modify / Delete / Bound Actions — each can be Not Allowed, Allowed, or On Confirmation (the agent proposes the change and a human must approve it before it commits).
You build these on the Tool Configuration Card, then attach a configuration to an agent.
Why "On Confirmation" matters. It's the AI equivalent of an approval workflow: the agent prepares the posting/record, but nothing hits the database until a person clicks Approve. Use it for anything that writes data until you trust the agent.
Supporting concepts:
- Usage description — a sentence telling the AI when to use a tool. The model reads it to pick the right tool, the way a person reads a field's tooltip.
- Field rules / Tool Field Defaults — hide a field from the AI, force a value, or pre-fill one (e.g. always set Responsibility Center to the user's default). Like field-level defaults on a template.
- Parent-Child Field Links — copy the key from a header tool to a line tool, so "create the invoice and its lines" wires up correctly — like how a Document No. flows from header to lines.
7. Autonomy level — how much the agent checks with you
Autonomy controls how often the agent stops to ask before acting. It's a single setting on the Agent Card with four levels:
| Level | Behaviour | In BC terms |
|---|---|---|
| Low: Step by Step | Asks permission for every action | Approve every line before posting |
| Medium: Plan and confirm | Asks clarifying questions up front, then proceeds | Confirm the plan, then it runs |
| High: Confirm write tool calls | Only pauses at the final destructive step | Approve only the post, not the prep |
| Autonomous: Act and report | Full autopilot, reports back when done | A scheduled Job Queue task |
Autonomy and tool permissions work together: even an Autonomous agent still respects On Confirmation on a specific tool. Autonomy is the general posture; tool permissions are the hard gates.
How to choose: new agents and anything that writes data → Low or Medium while you build trust. Read-only reporting agents → High or Autonomous is fine.
8. Knowledge base (uploading documents the agent can read)
If you switch on Knowledge Base, you can upload documents — policies, product sheets, manuals — under Knowledge Files. The agent can then quote and reason over them when answering.
Under the hood this is retrieval-augmented generation (RAG): the app finds the most relevant passages from your files and hands them to the model along with the question. You don't manage any of that — you just upload files.
Unlike a normal file attachment, the agent can actually read and use these documents in its answer, not just store them.
When to use: facts that live in documents, not in BC tables — return policies, SLAs, internal procedures. For data that lives in BC tables, use BC Data Access (tools) instead.
9. Thread memory (the agent's scratchpad for one conversation)
A long task can span many back-and-forth messages. Thread memory is a per-session scratchpad where the agent records its goal, plan, verified data, decisions & rules, and errors & retries, so it doesn't lose the thread across turns.
It behaves like a work-in-progress journal the agent keeps open during one conversation and clears when the conversation ends. It is per session, not permanent agent configuration.
You cap its size (in characters) on the Agent Card; 0 disables it. If you allow it, users can even view and edit the memory from a side panel during the chat — handy when the agent has misunderstood the goal.
10. Output type: Chat vs JSON
- Chat — the normal mode: the agent replies in natural language to a person.
- JSON — the agent returns structured data matching a schema you upload, for another system or automation to consume instead of a human.
Chat output is meant for a person to read; JSON output is structured data — an API/web-service payload — for another program to ingest. Most agents are Chat. Choose JSON only when something downstream needs machine-readable output.
11. Channels: where users meet the agent
An agent can be published to one or more channels:
- In Business Central — the chat window, a pop-out, or a panel embedded on a record page.
- Microsoft Teams — chat with the agent in Teams.
- Email — the agent monitors a mailbox and auto-replies.
It's the same agent delivered in different places. You manage channels under Published Channels and the Email Channel section of the Agent Card.
The email channel deserves a note: it polls a Microsoft 365 mailbox on a schedule using a Job Queue Entry — exactly the BC mechanism you already use for recurring tasks. It can validate the sender against a BC table (Customer, Vendor, etc.) before replying.
12. Testing agents: test cases, test runs, benchmarks
AI is non-deterministic — the same question can produce slightly different wording. So Smart Agents gives you a way to check behaviour stays correct:
- A test case is a saved conversation with an expected outcome. You can capture one straight from a real chat.
- A test run replays test cases and grades each one Pass / Partial / Fail — the grading is done by an AI model acting as judge ("LLM as judge").
- Benchmarks compare models or configurations against the same set of tasks so you can pick the best setup.
Test cases are regression tests for your agent — rerun them after you change instructions, switch model, or before a release to confirm nothing broke.
13. Sharing agents across tenants
If you build a great agent, you can share it with another Business Central tenant: you send an invite, they accept, and the agent appears in their incoming shares. See Sharing.
It works like distributing a configuration package or per-tenant extension — you publish, they consume.
Putting it together: building an agent end to end
- Setup once: register the tenant, set the default model, confirm you have credits.
- Create the agent on the Agent Card: name it, pick a model and autonomy level, write instructions.
- Grant capabilities: switch on BC Data Access / Knowledge Base / Web Search as needed.
- Connect data & tools: build a tool configuration (the AI's permission set) and attach it; upload knowledge files if relevant.
- Activate the agent and chat with it to try it out.
- Publish it to Teams or email, and share it if others need it.
- Test it with test cases so it keeps behaving as your data and instructions evolve.
Keep the glossary open the first few times — every manual uses these terms.