Can a Business Central agent run automatically when a contract arrives?

Not yet, and Microsoft states it plainly on the feature page: there are no built-in integrations to trigger a custom agent from an incoming email, an event, or a schedule. You invoke it by creating a task by hand. That matters more for contracts than for almost any other process, because contract work is made entirely of those three things.

What is actually shipping, and when?

Custom agent design in Business Central reached public preview on 6 February 2026 and is listed for general availability in October 2026. The capability arrives through the AI Development Toolkit for Business Central, and it extends the same agent runtime that already powers the built-in Sales Order and Payables agents.

Microsoft's framing is worth reading carefully, because it is a governance argument rather than a capability argument:

"The agent runtime ensures that every step taken by an agent is traceable and operates strictly within the access boundaries (permissions) assigned during configuration. It provides a timeline view of all agent activities, allowing users to review what happened and why — enabling a true human-in-the-loop experience."

That is the right design for an ERP. It is also the design we build to, and it is the reason an IT director says yes.

So what is the limitation?

One paragraph on the page, and it is the most useful sentence Microsoft has published for anyone planning contract automation:

"Although the ability to design your own agents is in public preview, there aren't yet any built-in integrations to automatically trigger these custom agents based on incoming emails, events, or scheduled recurrences (this can be done by professional developers using the APIs available in the AI Development Toolkit). However, you can simulate these scenarios by including the email header and body in the task message to mimic incoming emails, or by manually triggering the agent to emulate event, UI action, or time-based runs."

Read the two halves separately.

The first half is the gap. No built-in trigger from an email, an event, or a schedule.

The second half is honest about the workaround, and the workaround is a prototype tool. Simulating an inbound email by pasting its header and body into a task message is exactly right for validating whether your agent reasons correctly. It is not a way to run a process.

Why does this hit contracts harder than other processes?

Because contract work has almost no manual entry point.

Think about when contract work actually starts:

• A contract arrives. Usually as an attachment, on someone's email, from the counterparty.
• A notice date approaches. Nothing happens; that is the problem. The date passes and the term renews.
• A price changes on an order. Somebody edits a line, and a commitment quietly stops being fulfilled.

Every one of those is an inbound email, an event, or a schedule. They are the three things with no built-in trigger.

Compare that with the built-in Payables Agent, which Microsoft ships with the plumbing already done: it reads PDF attachments in a monitored mailbox and drafts a purchase invoice. The monitoring is the part you would otherwise have to build, and it is the part a custom agent does not yet get.

Does that mean you cannot build it?

No. It means the trigger is developer work rather than configuration, and Microsoft says so in the same sentence: this "can be done by professional developers using the APIs available in the AI Development Toolkit."

That is a meaningful distinction for planning. A consultant or a domain expert can design, test and refine the agent's reasoning in the sandbox using natural language. Getting it to run when a contract lands is a different skill and a different budget line.

It is worth being precise about what that developer work is. It is not the intelligence. The reasoning, the instructions, the permissions and the profile all come from the design experience. What has to be built is the listener: something that watches a mailbox, a date, or a field, and creates the agent task when the condition is met.

What else should you plan for?

Three things on the same page that shape a build.

Billing is per step, not per seat. Microsoft states that "custom agents consume Copilot credits as they perform their steps," provisioned prepaid or pay-as-you-go. An agent that fires on every inbound email costs differently from one that fires on a filtered subset, and that filter is part of the design rather than an optimisation you add later.

Agents are portable, as JSON. Definitions export as "simple JSON files containing properties such as agent identity, instructions, assigned profiles, and permissions," and Microsoft recommends keeping them in source control. That is unusually good news: your agent design is not locked inside one environment.

The direction of travel is MCP. Microsoft describes Business Central agents as "the foundational layer inside the product, exposing well-defined agent capabilities that in the future will be possible to surface as MCP tools and consume by Declarative Agents in Microsoft Copilot Studio and Microsoft 365." The layering is deliberate: tight, permissioned execution inside the ERP, orchestration above it.

That is the same seam we build on. The MCP server connects a model to Dynamics data so an agent can carry out a task from a plain-language instruction, with anything that moves money or stock prepared for a person to approve.

What should you do between now and general availability?

Four things, in order.

1. Prototype the reasoning now. The sandbox is available and the natural-language design experience is the cheap part. Find out whether an agent can read your paper before you build anything around it.
2. Decide the trigger condition precisely. "When a contract arrives" is not a specification. Which mailbox, which senders, which attachment types, and what happens to the ones that do not match.
3. Cost the firing rate, not the agent. Credits are consumed per step. The filter in front of the agent is a cost control.
4. Keep the definitions in source control from day one, because Microsoft has already made them exportable and there is no reason to discover that later.

Where does the ERP record come into it?

At the end, and it is the part that makes the automation worth building.

An agent that reads an arriving contract has produced a reading. The value appears when that reading is checked against what the system already holds. Business Central carries real fields for the things a contract decides — the vendor contract documentation names Cancellation possible until and Term until among the fields on a subscription line — and nothing in the ERP compares them with the document they came from.

An agent triggered by arrival, reading against your playbook, and writing its finding where the business already operates is a complete loop. Without the trigger it is a very good demo.

Sources

• Envision and design AI agents in Business Central — Microsoft Learn · ms.date 2026-06-09, updated 2026-08-27
• Vendor subscription contracts — Business Central, Microsoft Learn · ms.date 2026-05-04