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.

Create one

In the Admin Center, go to 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).

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 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 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 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:

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.

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