AI agents

What an AI agent is

• An AI agent belongs to one tenant and lists: custom instructions for the AI assistant (up to 4000 characters), the MCP roles it references, the skills it allows per area, and the tools it allows.
• Instructions are a starting point for the conversation — extra context, tone or procedure the tenant administrator wants the AI assistant to follow — not a way to grant access a role does not already allow.
• A tenant administrator creates, edits and publishes AI agents in the Admin Center. A user whose MCP role includes AI agents: Write can also propose a new agent or a change from an AI client; the proposal is saved as a draft and does nothing until an administrator publishes it in Agent Studio.

Three layers, one rule

The rule is always the same: effective access is the user's access intersected with the AI agent's. If the AI agent does not mention a role, a skill or a tool the user has, that role, skill or tool is simply not offered while the AI agent is selected — it is never added on top of what the user already has. An AI agent with an empty list for something (no roles listed, no skills restricted) means it inherits the user's full access for that layer instead of narrowing it.

Permissions of an agent's roles

Each level of an AI agent's chain (the agent and every ancestor) can reference MCP roles. Roles belong to a kind of connection (Business Central or Dynamics 365 CRM), so a level that references roles only works on a connection those roles cover.

• If the roles of any level of the chain do not cover the connection, the AI agent reads nothing in it. Access is denied, never widened — the rule fails closed.
• The AI client gets this message: The AI agent's roles do not cover this connection. Ask a tenant administrator to add a role for it to the agent, or select another agent.
• The fix is in the Admin Center: add a role that covers the connection to the AI agent's Roles tab, or select another AI agent.
• A level with no roles is not restricted: it inherits what the level above allows, as described in Three layers, one rule.

Create one

In the Admin Center, go to Developers → AI & MCP → AI agents and press New AI agent: give it a name, write its instructions, and pick the MCP roles, Business Central sections and tools it should narrow the connection to. A tenant administrator can do this directly — see MCP roles for how roles themselves are created and assigned. Users without administrator rights can only propose an agent, as described next.

Propose agents from an AI client

An AI client connected to the Business Central or Dynamics 365 CRM server can help a user design an AI agent or a sub-agent, and a skill to go with it, without opening the Admin Center. Everything it creates is a draft.

Permissions. Add the AI agents and Skills lines, each with Read or Write, to an MCP role of the Business Central destination and assign it to the user. Read lets the AI client look at the existing definitions and the catalog; Write lets it propose drafts. The lines also apply on the Dynamics 365 CRM server: a CRM session still needs a Business Central role that carries them. Write on one line does not give Write on the other.

Steps.

1. The AI client reads the catalog of what the user can use: limits, review policy, existing agents, tools, skills and the roles that can be assigned.
2. It proposes a new agent (optionally as a sub-agent of an existing one) or a change to an existing agent, and, when the agent needs one, a new or changed skill. The user can ask for adjustments until the draft reads well.
3. When the user confirms, the AI client sends the draft to review.
4. A tenant administrator reviews and publishes it in Agent Studio; a skill is published in Skills → Proposed changes. See Agent studio.

Until then, the published agent and the published skill keep working exactly as before.

Tools. Nine plure_* tools cover these steps:

Good to know.

• A new agent cannot be used until its first publication: it appears as Awaiting first publication and select_agent does not find it. A sub-agent cannot be published before its parent.
• The roles added to a proposal can never grant more than the user's own roles.
• A proposal can only use tools and skills its parent agent allows, and an agent managed by Plur-e cannot be changed this way.
• Proposals are not offered in autonomous runs, and an AI client cannot publish, enable or delete an agent.
• The agent-authoring guide, which the AI client reads before proposing anything, explains the model: instructions, tools, skills, roles, versions and the errors it can hit.

Pick it when connecting

• Consent screen: tenant users seeing the OAuth consent screen while connecting get an AI agent dropdown listing the tenant's AI agents, plus "None". Picking one fixes it for that connection.
• select_agent: any client can call select_agent with the agent's exact name, or with "none" to clear the one already selected, at any point in the conversation.
• X-Plure-Agent header: stateless clients that send a header on every request can send X-Plure-Agent with the agent's name on every call; sending X-Plure-Agent: none clears it.

Two read-only tools help a client discover what is available: plure_list_agents (the tenant's AI agents, name and description) and plure_current_agent (the one selected for this connection, if any).

What changes

• Instructions picked on the consent screen or through the X-Plure-Agent header are injected into initialize, so the AI assistant sees them from the very first message.
• Instructions picked mid-conversation with select_agent come back in that tool's result instead — a client can only see them once it calls the tool — and are also available afterwards from the MCP resource plure-bc://agent (Business Central) or plure-crm://agent (Dynamics 365 CRM).

Tool list follows the active agent

On the Business Central (/bc) and Dynamics 365 CRM (/crm) servers, the list of tools the AI client sees follows the active AI agent: tools the agent (or any ancestor) does not allow are not listed.

• When you select an agent, hand off to a sub-agent or return to its parent, the server sends the client a notifications/tools/list_changed message, so a client that supports it refreshes the list without reconnecting.
• If the active AI agent stops being available (for example, it was disabled), only select_agent, plure_list_agents, plure_current_agent and select_tenant are listed, so the AI client can choose another one.
• plure_delegate and plure_delegation_result are hidden while the server's agent runner is turned off.
• The list is a convenience. The real restriction is applied to every call: a tool that is not allowed is rejected even if a client still shows it.

Business Central granularity is the section

An AI agent narrows Business Central access at the section level — the same 16 sections (bc_wms_receipts, bc_sales, …) that MCP roles areas map to — not at the level of an individual method inside a section.

Sub-agents and delegation

An AI agent can have sub-agents: smaller AI agents, each focused on one area, that a parent AI agent hands work to. The AI assistant talks to the parent; the parent delegates each request to the sub-agent that owns it and summarises the answer.

An agent tree

An AI agent can have a parent, and the tree can go up to 3 levels below the root. For example, a mobile operations tree for Business Central:

Mobile
├── Sales
├── Purchases
├── Payments
└── WMS
    ├── WMS Basic
    └── WMS Advanced

Trees exist inside one tenant. Plur-e platform AI agents have no sub-agents, and the delegation and hand-off tools below are not available on the platform endpoint.

A sub-agent can only narrow

A sub-agent never gets more than its parent. Its effective access is the user's access intersected with every level of its chain, for roles, skills and tools alike:

• An empty list at one level means that level inherits what the level above allows.
• Disabling an AI agent also disables its sub-agents.
• Selecting a sub-agent directly (consent screen, select_agent or X-Plure-Agent) and delegating to it from its parent give exactly the same limit.
• A change made to an ancestor can take up to 1 minute to apply to its sub-agents.

Create the tree

In the Admin Center, go to Developers → AI & MCP → AI agents:

• Choose a Parent agent when you create an AI agent, or later in its General tab. Leave it empty for a root AI agent.
• The Sub-agents tab of an AI agent lists its direct children and lets you add one.
• In the Roles, Skills and Tools tabs of a sub-agent, anything its parent does not allow appears disabled with Not allowed by parent.
• An AI agent that has sub-agents cannot be deleted until its sub-agents are moved or deleted.
• When you clone an AI agent from the platform area you can include its sub-agents.

Plur-e offers the Mobile hierarchy above itself, as system AI agents: you see all 7 of them in Developers → AI & MCP → AI agents and customise them without copying them (see System AI agents and customisation). Each one already has the Business Central sections it needs:

Sub-agents: hand-off vs delegation

There are two ways to use a sub-agent from an AI client. Pick by who does the work:

Use a hand-off for a focused task you want to follow and steer in the conversation. Use delegation only when the sub-agent should work on its own on the server.

plure_handoff_to_agent(agent, task)
plure_return_to_parent_agent(summary)

• plure_handoff_to_agent passes the conversation to a direct child of the active AI agent. From then on the sub-agent's instructions, skills and tools apply, and the limit is exactly the same as selecting it directly.
• plure_return_to_parent_agent goes back to the parent with a short summary of what was done. The hand-off ends when you are back at the AI agent where it began.
• select_agent (any value, including "none") and select_tenant also end the hand-off.
• Hand-offs are not available when the AI agent is fixed by the X-Plure-Agent header or by the token of an autonomous run, nor for clients that do not keep a session. They are only offered on the Business Central and Dynamics 365 CRM servers.
• The hand-off state lives in the MCP session. If the session restarts or expires, it is lost, and the AI client has to select the AI agent again.

Delegate from your AI client

With an AI agent selected that has enabled sub-agents, plure_list_agents shows them, and the AI assistant can call:

plure_delegate(agent, task, allowWrites?, waitSeconds?)

• The sub-agent works on the Plur-e server with the AI model configured for it. It sees only the task text, not the conversation, so the task must carry every detail it needs. It answers with a report.
• You can delegate only to direct children of the selected AI agent that are enabled. The report is treated as untrusted data, never as instructions.
• plure_delegate waits up to about 150 seconds. If the sub-agent has not finished, the answer carries a runId: call plure_delegation_result(runId) to get the report.
• If the client disconnects, the sub-agent keeps working and you can get the result later with plure_delegation_result.
• allowWrites is false by default: the sub-agent can read but not change data. Set it to true only in an interactive session when the task must write; the MCP client asks you to confirm.
• Each user can have at most 3 delegations running at the same time.

In autonomous runs

An autonomous run can also delegate to sub-agents:

• Sub-agents in an autonomous run never write, whatever the run itself is allowed to do.
• What the sub-agents spend counts against the same budget as the root AI agent's run.
• Cancelling a run cancels its sub-agents' runs too.

Sending email

An AI agent can send an email with plure_send_email, from Plur-e's mailbox, to people in your own domains. It is switched off until a tenant administrator sets it up:

1. Allow recipient domains. In Developers → AI & MCP → Settings, fill in Allowed recipient domains (AI agents): up to 20 domains separated by commas, for example contoso.com, fabrikam.com. A domain matches exactly — subdomains are not included. Empty means AI agents cannot send email.
2. Grant the tool. Select plure_send_email explicitly in the AI agent's Tools tab. Inheriting every tool does not include it. For a sub-agent, an ancestor that restricts its tools must list it too.

Limits and behaviour:

• A recipient outside the allowed domains rejects the whole email; the message lists the domains, not the addresses.
• The Plur-e server can have email turned off; the tool then answers that email is disabled on the server.

Autonomous runs. A trigger has a Send emails without approval checkbox. With it on, nothing is queued for approval: plure_send_email is sent immediately in that trigger's runs, even when the trigger's Writes setting is Deny. It only affects plure_send_email: every other write still follows Writes. Sub-agents, interactive delegations and tests are not affected.

AI models

Autonomous runs and delegations use the AI models that Plur-e makes available to AI agents (Available to AI agents). Plur-e configures each model with the Provider that serves it.

• Some providers accept an Effort setting, which sets how much work the model puts into each reply: Model default, Low, Medium, High, Extra high or Max. Providers that do not support it ignore it.
• Models that are available only to AI agents are not used by the training chat.

Disable by Plur-e

Plur-e can disable an AI agent for every user of a tenant from the /super server or the Admin Center's platform area, regardless of what the tenant configured. A disabled AI agent cannot be selected on the consent screen, with select_agent or with the X-Plure-Agent header until Plur-e re-enables it.

To customise Plur-e's system AI agents without copying them, watch your AI agents live, inspect their runs, pause them and review versions, see the Agent studio.

Related: MCP roles · Connect your AI client · Business Central mobile flows