Four channels, one agent brain: Teams, Email, Web, and BC

Smart Agents exposes one agent brain through four surfaces. The user picks the surface that fits the moment. The agent does not care which surface it is answering from because the tool scope, autonomy level, permission set, and credit meter are the same everywhere. What changes is the ergonomics. This is the right shape for a BC tenant because no two of your users live in the same application all day.

CHANNEL 1: BUSINESS CENTRAL (THE SURFACE OF RECORD)

BC is the primary channel. The Smart Agent Chat page sits inside the BC client, alongside the pages the agent is reading from. When the AR clerk asks "pull up customer 10000's open entries," the response is a table rendered inline, with action suggestions that link back to the underlying Customer Ledger Entries page in one click. This is the channel to use for anything that ends in a BC action: posting, running a report, generating a statement, editing a record.

For consultants who spend all day in BC anyway, this is also the shortest feedback loop. Open the chat, ask, verify against the page you can see in the next tab, move on. The Smart Agent Chat Engine codeunit handles the asynchronous submit-and-poll pattern: your message returns to the user immediately while the backend runs the model and the tool calls in the background, so the BC client does not block.

CHANNEL 2: MICROSOFT TEAMS (THE SURFACE FOR THE USER WHO IS NOT IN BC)

Teams is the right channel for the user who is not in BC right now. The AR lead is in a stand-up. Sales is on a customer call. Operations is on the shop floor with a tablet. They do not want to alt-tab into BC to ask one question; they want to message the bot in a Teams chat and get the answer.

The Teams channel requires a one-time tenant setup: granting the Teams app the email platform scopes it needs and pinning the bot in the customer's Teams admin centre. After that, the same agents you activated in BC are available in Teams under the same names. The Teams bot answers questions, drafts emails, exports PDFs as attachments. It does not currently let the user post journals from Teams; we chose to keep write-through-chat inside BC for the launch release because the confirmation UX in Teams is not yet rich enough for us to be confident the user saw what they approved. That is on the roadmap (see the blog post on what we have not shipped yet).

For manufacturing pilots we ran, Teams turned out to be the highest-usage channel. Shop-floor supervisors do not open BC. They do open Teams.

CHANNEL 3: EMAIL (THE CHANNEL NOBODY CELEBRATES AND EVERYBODY USES)

Email is the back-office channel that never goes away. Most inbound work arrives as email: "send me the statement," "where is my order," "what was the price on the last shipment." The email channel lets an authorized mailbox (for example invoicing@yourdomain.com) be read by an agent, which drafts a reply with live BC data and parks it in the user's outbox for review.

The SA Email Handler codeunit, all 1,141 lines of it, polls the email platform at a configurable interval, routes incoming emails to the agent flagged with a matching Email Address and Email Enabled flag on the Smart Agent table, and posts the agent's draft reply back through Graph. The SA Email JQ Runner is the scheduled task that drives the polling loop. Every email lands in the SA Email Log table with sender, subject, agent, and outcome.

By default the draft sits in Drafts until the user reviews and sends. You can promote a specific template to execute autonomy so it sends without review, but we do not recommend that for external customer mail until you have watched at least two hundred drafts look right. The deeper email walkthrough is in the related blog post on email triage.

Email requires the email platform mailbox delegation through Azure Key Vault for the OAuth client credentials. Your IT team provisions it once per mailbox. Afterwards, the agent reads only the threads the mailbox owner would read anyway.

CHANNEL 4: WEB CHAT (THE PUBLIC-FACING SURFACE)

Web chat is the surface for customers and prospects. Embed the chat widget on your portal or support page. It can answer knowledge-base questions grounded in your BC data, like catalogue lookups, order status given an order number and a customer match, simple availability queries. Web-chat agents run under a service identity you configure on the Smart Agent Publisher table with a deliberately narrow data scope. They cannot see internal cost prices, cannot post, cannot access other customers' data. They can only see what the service identity is permitted to see.

Use web chat for customer self-service. Do not use it for anything that needs a full BC user session, because it does not have one.

WHEN TO USE WHICH

A rough decision matrix from the pilots: posting, reconciliation, anything that writes to the ledger goes through the BC channel under ask-before-write autonomy. Quick lookups during meetings go through Teams. Customer correspondence in bulk goes through Email with drafts to the outbox. Public-facing FAQ with BC data goes through Web with a narrow scope.

The channels share conversation history per user, so an answer the AR clerk got in Teams at 09:00 is visible in the BC chat page at 10:00 when she wants to pin it to a record. The credit meter is the same pool: one credit spent in Teams is one credit less available for Outlook the same hour. That makes monthly budgeting simple, because you have one number to track, not four.

ONE BRAIN IS THE POINT

We could have shipped four channel-specific products. It would have doubled our engineering surface and halved the audit clarity. Instead we shipped one set of agents, one permission model, one audit log (the SA Tool Call Log is shared across all channels), and four ways in. That is the shape users asked for and the shape compliance signs off on.

A WORKED EXAMPLE: ONE QUESTION, FOUR SURFACES

Maria is the AR lead at a wholesale distribution pilot. On Monday morning at 08:50 she is standing in the warehouse waiting for a stand-up to start. She opens Teams on her phone and asks the Smart Agents bot: "Top five overdue customers as of today, with totals." The bot returns a five-row table with names, totals, and days overdue. Cost: about 0.4 credits at the Smart tier.

At 09:15 Maria is back at her desk, opens BC, navigates to the Smart Agent Chat page, and sees the same answer waiting for her in the conversation history (the Smart Agent Session keys conversations by user, not by channel). She clicks one of the customer rows and the chat panel suggests three follow-up actions including "Generate September statement and draft email." She picks it. The agent runs the tool, drafts the email, parks it in Drafts. Cost: another 0.6 credits.

At 10:00 the agent's email channel runs its scheduled poll. Three customers from Friday's mailing have replied with payment confirmations. The SA Email Handler routes each one to the appropriate AR follow-up agent, which reads the body, matches the payment to the open invoice in Cust. Ledger Entry, drafts a thank-you reply, and parks it in Drafts. Cost: about 1.5 credits across the three.

Three surfaces, one user, one credit meter, one audit log. Total cost so far: about 2.5 credits or two and a half cents. Maria has not opened her statement-generation spreadsheet once, and every action is recorded in the SA Tool Call Log table for the controller's monthly review.

For the deeper architecture story see the related blog post on why Smart Agents lives inside BC. For setup, see /docs/getting-started.