Copilot & AI Agent Toolkit

The problem

The interesting question about AI in an ERP is not whether a model can draft a purchase order. It is what happens when it does. An assistant that answers questions about your data is low-risk and low-value. An agent that can actually act — release a purchase order, adjust inventory, register a payment — is high-value and, without controls, unacceptable. Most teams end up stuck between the two: a chat window that cannot do anything, or an integration account with broad permissions and no record of why it did what it did.

Dynamics 365 Finance & Operations already has the primitives for the answer. It has a workflow framework with real approval hierarchies. It has role-based security with duties, privileges and segregation of duties rules. It has the database log and audit trail. What it does not have is a layer that forces an AI agent through those primitives instead of around them. That layer is what this toolkit is.

What ECOSIRE builds

ECOSIRE builds a governed agent framework for Dynamics 365 Finance & Operations as X++ extension models, with no overlayering. The governing principle is simple and enforced in code: an agent never writes directly to F&O. Every agent action follows one path — propose, evaluate against policy, gate for approval where required, execute, record.

Agent identity and the tool registry

Each agent is a first-class record in F&O with its own identity, an explicit allowlist of tools it may call, a risk ceiling, and a rate limit. An agent that is not allowlisted for a tool cannot invoke it, regardless of what a prompt says.

Tools are the only way an agent touches the system. Each tool is a registered X++ class with a declared name, a typed input contract, and a fixed risk level assigned at design time — not chosen by the model. Read tools query data entities: open purchase orders, on-hand inventory, aged receivables, vendor history, production orders. Write tools call the same business logic your users call — sales order creation, purchase requisition submission, inventory adjustment journals, warehouse work — through supported extension points. Financial-commit tools such as posting a journal, registering a payment or approving a purchase order are classified at the highest risk level and are hard-coded to always require human approval, at every autonomy setting. That is not a configuration option that can be turned off.

Policy, approval and execution

A proposal from an agent hits the policy gate first: is this tool allowlisted for this agent, is the agent within its rate limit, is the tool's risk level at or below the agent's ceiling, is the agent suspended. Anything that fails is rejected and recorded with the reason — rejections are logged as thoroughly as executions, because a pattern of rejected proposals is exactly what you want to see.

Proposals that pass but exceed the auto-execution ceiling become work items in the standard F&O workflow framework, routed to the approvers your existing hierarchy already defines. The reviewer sees the tool, the exact typed input, and the agent's stated reasoning before approving. Approved actions execute on the batch framework, so long-running or high-volume work is durable and retried under your control rather than tied to a session.

The ledger

Every proposal, decision and execution is written to an append-only action ledger: which agent, which tool, the full input, the policy outcome, who approved it, what the execution returned, how long it took, and which model and prompt version produced it. The ledger is queryable in F&O, exposed as a data entity for Power BI, and exportable. When someone asks in six months why a credit limit was raised, the answer is a record, not a reconstruction.

Autonomy levels

Agents are dialled through named autonomy levels rather than a scatter of individual switches. At the lowest level an agent only suggests and every action needs approval. Higher levels permit low-risk read and draft actions to execute automatically, then progressively more, with a digest of what ran. The highest level still never auto-executes a financial commit. Moving an agent up a level is an explicit, logged administrative action, and any agent can be suspended immediately — suspension is checked at the policy gate, so in-flight proposals stop too.

Grounding and integration

Agents are grounded in your data through retrieval over F&O entities and, where you want it, your document estate — so an answer about a vendor cites the purchase orders and invoices it came from rather than being generated from a model's general knowledge. The framework is model-agnostic and connects to the AI service you nominate; where you already run Power Platform, agents can be surfaced through Power Automate or a conversational front end, and Dual-write is used only if you run it and want customer-engagement context alongside F&O.

Who it is for

Organisations on Dynamics 365 Finance & Operations that want AI agents doing real operational work — chasing overdue receivables, triaging exceptions, drafting replenishment — but operate under audit, segregation-of-duties or regulatory requirements that make an unmonitored assistant a non-starter. It suits finance, supply chain and shared-service teams with high-volume repetitive judgement work and a low tolerance for unexplained changes.

How delivery works

This is a build-to-order engagement.

1. Scoping call. We identify the two or three agent use cases worth building first, the exact tools each needs, the risk classification of each tool, your approval hierarchy, and which AI service you will use. We review your F&O version, security model and existing customisations. 2. Fixed quote. You receive a written scope listing every tool to be built with its risk level, the policy and autonomy model, the ledger and reporting surface, and a fixed price and timeline. Typical build time is one working week depending on tool count and integration complexity. 3. Build. We develop the framework and the scoped tools against a build environment matching your version, with tests covering the policy gate, the approval path and the ledger. 4. Install in test. The deployable package goes to your sandbox through LCS. Agents start at the lowest autonomy level — suggest only — so your team can review a period of real proposals and decide what is safe to automate before anything executes on its own. 5. Production. After sign-off the package is promoted through your LCS pipeline. Agents go live at the autonomy level you choose, and you raise it when the ledger gives you reason to. 6. Support. A defined support window follows go-live, covering defects, tool configuration and adding tools to the registry.

You own the extension source, the tool definitions and the ledger data. Nothing about the governance model depends on ECOSIRE remaining in the loop.