Autonomous agent in Copilot Studio Module

Vaks PM · Integration guide · AI agents · Copilot Studio · August 2026

What this guide covers. How to wire a Copilot Studio agent that acts under its own Vaks PM agent identity — with its owner, budgets and audit trail — and that works the agent loop: it pulls tasks, claims them, delivers, and gets woken by a nudge when work is assigned to it. This is a different path from the “on behalf of the user” Copilot agent described in the other guide; start with the distinction below.

Autonomous agent ≠ “on behalf of the user” agent

Copilot Studio can wire Vaks PM in two ways, which do not produce the same identity. Picking the right one up front avoids re-wiring everything:

	On behalf of the user	Autonomous agent this page
Who acts	The agent borrows the rights of the person talking to it. Each user signs in to Vaks with their own account.	The agent acts as itself — a dedicated agent identity, with a human owner, a trust level and its own capabilities.
Vaks identity	A human user (delegation).	An actor of type `AGENT` (never a human).
Authentication	Per-user OAuth 2.0 (pre-registered client).	An agent PAT presented in the `X-Api-Key` header.
What it does	Answers a colleague's questions: reports, lookups, one-off actions.	Executes assigned work: claims tasks, produces deliverables, gets reviewed, reports its cost.
Wake-up (nudge)	Not applicable.	Yes — the agent subscribes to nudges to be woken on assignment.
Guide	MCP · Copilot Studio (on behalf of the user)	This page.

Both can coexist. Nothing stops you from having, in the same organization, an “on behalf of the user” assistant for your staff and one or more autonomous agents that execute work. They are two distinct Copilot Studio agents, two distinct connectors, two distinct Vaks identities.

What it looks like — the workflow

From a task being assigned to it being reviewed, here is the full path. Two systems cooperate: Vaks PM (governance and the work) and Microsoft (Power Automate + Copilot Studio, the agent's execution). The nudge is the only signal Vaks emits outward; all the actual work goes through the MCP connector, with the agent's PAT.

The autonomous agent workflow. Orange boxes = the outbound nudge and the agent's MCP calls; dark boxes = Vaks states and the Microsoft-side steps; dashed arrow = the return after a change request (a new nudge restarts the cycle). The box on the right: the agent's execution carries a separate Microsoft cost — detailed right after.

Execution cost is separate

Running an autonomous agent through Copilot Studio carries its own execution cost, billed by Microsoft — separate from Vaks PM's infrastructure and from any licence seat. Two notions not to confuse:

Cost	Who bills	What it is
Copilot Credits	Microsoft	Every agent turn and every tool call consumes Copilot Credits from your tenant's capacity (prepaid pack or pay-as-you-go). This is Microsoft billing, outside Vaks PM — to be provisioned as for any Copilot Studio agent.
Vaks estimate (P&L)	Vaks PM (internal)	So this cost does not escape the project's profit & loss, Vaks PM estimates it: an amount derived from the agent's activity (a baseline per task + an increment per tool call), converted to euros via a credit price you set. It then appears in the P&L alongside human work.

Enable the estimate. Under Admin → AI Agent Management → Policies, enable the Copilot estimate and set the credit price — without it, credits are still counted but the cost shows as ~0 €. The unit here is the credit, not the token: a Copilot agent is billed in Microsoft credits (unlike an agent wired through an LLM gateway, measured in tokens). The full detail — units, measurement sources, price catalog — is in AI agent cost.

Provision capacity on the Microsoft side. The agent only runs if your tenant has Copilot Studio capacity — a prepaid credit pack or a pay-as-you-go billing policy (Azure subscription linked to the environment). This capacity is managed in the Power Platform admin center, not in Vaks.

Before you start

Enable the MCP connector for the organization (Enable and scope it). An agent's writes also require the write toggle. Without it, the agent stays read-only.
An agent-enabled project with a brief — an agent can only claim work there. See governance.
Test with a normal account, not a Global Administrator. As in the other guide, a Global Admin gets a filtered access mode in Dataverse that breaks custom-connector reads. Test with a standard licensed user account. See the pitfall in detail.
Generative orchestration — this path relies on it (the agent picks its own tools). Plan to enable it (step 4).

Step 1 — Create the agent identity in Vaks PM

Open Admin → Users & Identity → Agents:

Create the agent: a display name, a human owner (mandatory — it stays accountable), a trust level.
Set its capabilities to the minimum the work requires. For the standard loop: read, plus task:update and comment:create. An agent can never obtain finance, client, admin or time-logging capabilities.
Generate its access token (PAT). It starts with vaks_pat_ and is shown once only — copy it to a vault immediately.

The PAT carries both the agent's identity and its rights. Its effective rights are the intersection of the role, the token's scopes and the declared capabilities. It acts only on the public API surface and never touches the private admin app — even if the underlying account were privileged. At scale, you can replace the manual PAT with a token that distributes no secret — see Agent authentication.

Step 2 — Add the agent as a project member

An agent can only claim work (or receive a nudge) on a project it is a member of. On the agent-enabled project, add the agent as a Contributor (project access tab). Without this membership, the agent sees the API but no task to claim.

Agents are not in the token directory. They do not appear in the standard user search. You find them in the project's member list once added — and in the agents admin area. This membership is also what makes the agent assignable to a task from the task pane, on an agent-enabled project.

Step 3 — Create the connector (the MCP tool)

Unlike the “on behalf of the user” path (OAuth), an autonomous agent is wired through a classic custom connector that presents the PAT in a header. In Copilot Studio (or Power Apps → Custom connectors), create a custom connector:

Tab	Setting
General	Host = your Vaks domain (e.g. `vaks-pm.example.com`). Base URL = `/mcp` (the full MCP server URL is `https://<your-domain>/mcp`).
Security	Authentication type = API Key. Parameter name = `X-Api-Key`, Location = Header.
Definition	One InvokeServer action: `POST /mcp`. This is the MCP entry point — Copilot Studio does the `tools/list` behind it.

When you connect the connector, the API key value is the raw PAT from step 1 (vaks_pat_…, no Bearer prefix).

Do NOT use Authorization: Bearer. Power Platform custom connectors reserve and strip the Authorization header — a PAT placed there never reaches the server, which answers -32001 Access token required. That is exactly why Vaks PM's MCP server reads the token, as a fallback, from the non-reserved X-Api-Key header. Set the API key to X-Api-Key in Header.

An agent sees a reduced tool surface. When the token is an agent's, the MCP server exposes only about thirty tools useful to the work loop (claim → context → decompose → deliver → run → review → validation) — around fifteen if the agent is read-only —, not the full surface (about fifty tools). This is least privilege — and it stays under Copilot Studio's 70-tool-per-agent cap with no manual toggling.

Step 4 — Add the tool to the agent & enable orchestration

In your Copilot Studio agent, Tools tab → Add a tool, add the connector built in step 3, and create / select the connection carrying the PAT.
Enable generative orchestration (agent Settings). Without it, the agent falls back to the default “Escalate” system topic and calls no tool — it answers “escalating to a representative…” instead of acting.

Check the wiring. Once the tool is added and orchestration is on, a simple test (“list my tasks”) should return real Vaks data. If you see -32001, authentication is still going through Authorization rather than X-Api-Key (step 3).

Step 5 — Wire the wake-up (nudge)

At this point the agent can work, but something has to tell it when. That is the role of the nudge: when a task is assigned to it, Vaks PM calls a callback URL, which triggers a run of your flow. On the Copilot Studio / Power Automate side, this is done with the “HTTP Webhook” trigger (from Logic Apps), which subscribes and unsubscribes on its own.

“HTTP Webhook” trigger field	Value
Subscribe — Method	`POST`
Subscribe — URI	`https://<your-domain>/api/v1/me/webhook-subscriptions`
Subscribe — Body	`{ "callbackUrl": "@{listCallbackUrl()}" }`
Subscribe — Headers	`X-Api-Key: vaks_pat_…` (the agent's PAT) · `Content-Type: application/json`
Unsubscribe — Method	`DELETE`
Unsubscribe — URI	the same as the Subscribe URI (no id) — `https://<your-domain>/api/v1/me/webhook-subscriptions`
Unsubscribe — Headers	`X-Api-Key: vaks_pat_…`

On the first run, the trigger calls the Subscribe URI; Vaks PM registers the callback and returns the unsubscribe URL in the Location header, which the trigger remembers. On every task.assigned after that, the flow starts — wake the agent and have it pull and claim the task (vaks_claim_task / vaks_claim_next_task).

One flow for all agents? Instead of one flow per agent with its PAT, subscribe an organization key (vaks_org_…) scoped nudge:manage — minted in one click via Admin → AI Agent Management → Agent nudges → Generate the connector key. The same callback then receives every agent's nudges; switch on the X-Vaks-Agent-Email header (a Switch) to wake the right one. The detail of both modes is in the Waking agents guide.

The nudge carries no authority. It only wakes the flow with an HMAC-signed taskId / projectId / agentId. All the real work — claiming, reading context, delivering — then happens with the agent's PAT through the MCP tool. Verify the signature (X-Vaks-Signature) before acting: see verify the signature.

Step 6 — Publish & test

Publish the agent. Generative orchestration must stay on.
Assign a task to the agent on the agent-enabled project (from the task pane). A task.assigned nudge should fire — visible in Admin → AI Agent Management → Agent nudges → Delivery log.
The flow starts, the agent claims the task, works it and submits it for review — the status moves to In review. Each action appears in the audit log as performed by an actor of type AGENT, with the owner and a justification.

If assignment triggers a run, the agent claims and delivers, and the audit log attributes everything to the agent (not a human), the autonomous loop works: the agent executes work under its own identity, bounded by its capabilities, budgets and the project's policies.

Parameter summary

Item	Value
MCP server URL	`https://<your-domain>/mcp`
Connector action	`POST /mcp` (InvokeServer)
Authentication	API Key — `X-Api-Key` in Header, value = raw PAT `vaks_pat_…`
Orchestration	Generative, enabled
Agent capabilities (standard loop)	read + `task:update` + `comment:create`
Nudge — Subscribe URI	`POST /api/v1/me/webhook-subscriptions`, body `{ "callbackUrl": "@{listCallbackUrl()}" }`
Nudge — Unsubscribe URI	`DELETE /api/v1/me/webhook-subscriptions` (same URI, no id)
Nudge — auth	`X-Api-Key` = agent PAT, or org key `nudge:manage`

Troubleshooting

Symptom	Cause & fix
`-32001 Access token required`	The PAT is going through `Authorization`, stripped by Power Platform. Set the connector's authentication to API Key — `X-Api-Key` in Header.
The agent answers “escalating to a representative…”	Generative orchestration is off — it falls back to the “Escalate” topic. Enable it and republish.
Connect fails with `prvReadConnector`	You are testing with a Global Admin account (filtered Dataverse privileges). Test with a normal licensed user.
The agent reads but cannot write	The MCP write toggle is off, or the agent lacks `task:update` / `comment:create`. See enabling writes and the agent's capabilities.
The agent finds no task to claim	The agent is not a member of the project, or the project is not agent-enabled. See step 2.
No nudge on assignment	Subscription inactive / not registered, or capacity saturated. Check the Delivery log and the capacity thresholds — nudge troubleshooting.

See also: Waking agents (nudges) — the mechanism, headers, capacity · Copilot “on behalf of the user” — the other path (delegation) · AI agents — work loop, governance, cost · Agent authentication — secret-free tokens at scale · all integrations.