Estimated reading time: 17 minutes

Most Copilot Studio agents still wait for a prompt. Someone opens a chat, types a request, and the agent answers on that person’s behalf. The October announcement from the Copilot Studio team describes a different kind of agent. Instead, it has its own account in Microsoft 365 and remembers how a recurring process works. It starts itself when an email arrives or a schedule fires. Between the moments people step in, it keeps the work moving.

That idea suits shared business processes, such as a weekly budget review, a proposal review board or an execution tracker. It also changes the governance question. An agent you prompt borrows your identity and your judgment for a few minutes. By contrast, an agent with its own mailbox, Teams presence and shared memory is closer to a new colleague. So it needs the onboarding, access decisions and boundaries you’d give one.

This post covers what shipped and what you need before the feature appears. It then looks at the agent’s identity and the shared-memory behavior to understand before a pilot. Finally, it covers the harness’s current gaps and billing. I based it on Microsoft’s announcement and the Microsoft Learn documentation as of 22 October 2026. Agent accounts are a Frontier preview, so expect details to change.

The announcement bundles five capabilities, and they don’t share one status. The blog post and the documentation also label some of them differently. For that reason, this table uses the documentation’s labels wherever they exist.

Capability	What it does	Status (as of 22 October 2026)
Agent accounts	The agent gets its own Microsoft Entra account, mailbox, Teams presence and directory entry. People reach it by email, in Teams and through @mentions in Office comments.	Frontier preview
Business process memory	The agent carries preferences and process context into each new cycle. For agents with an account, this memory is shared across everyone who works with the agent.	Part of the agent accounts Frontier preview
Triggers in the GitHub Copilot harness	An event in a connected service (an email, a new SharePoint item) or a schedule starts the agent without a prompt.	Preview (the blog says “availability”; Learn labels it preview)
Agent refinements	Activity-based recommendations for makers, such as turning repeated steps into workflows or picking a better-suited model.	Planned “over the coming months”
Browser-enabled cloud computer	The agent uses its own browser-enabled cloud computer.	Upcoming; computer use is listed as “Planned” for the GitHub Copilot harness

All of it sits on the GitHub Copilot harness, the newer authoring and runtime environment in Copilot Studio. Despite the name, it’s a Copilot Studio framework rather than the GitHub Copilot service. Microsoft’s documentation states that these agents don’t send customer data to GitHub Copilot, and GitHub Copilot doesn’t process it.

Microsoft’s customer example is Ooredoo Qatar. Its executive business-case review agent works across Outlook, Teams and Word. It also reviews incoming proposals against company policy and precedent and prepares decision-ready briefs. The announcement doesn’t publish numbers for it, so neither will I.

---

A persistent agent runs in cycles. Something starts the cycle, and the agent reasons over its instructions, memory and tools. Next, it produces an output and hands decisions to people. Then it waits for the next trigger.

Triggers start the cycle

In the GitHub Copilot harness you add triggers from the agent’s Build tab. A trigger can be a connector event (a new email in a folder, a new SharePoint item) or a Recurrence. In addition, each trigger can carry its own extra instructions. That matters when one agent handles several triggers differently. When you share the agent, you can also mark trigger options as Editable by user. Test every trigger before publishing: Start listening waits for a real event, or you replay a previous one. The agent runs autonomously only after you publish and activate it.

Instructions and tools do the work

The harness replaces topics with natural-language instructions, Skills and Hooks. Hooks are workflows that run at points in the agent’s lifecycle, such as session start or before a tool call. Tools are connectors, MCP servers, workflows and connected agents. The harness reasons over the goal, breaks it into steps and adjusts when a step fails. That’s why Microsoft positions it for long, multi-step business processes rather than short Q&A.

Memory carries context between cycles

Without memory, every cycle starts cold. With it, the agent keeps preferences, open questions and how the team works. However, for agents with an account, everyone shares that memory. The governance section below explains why that matters.

People stay in the decisions

Microsoft’s documentation includes a starter configuration called Cadence, a team execution-review agent. It runs on a recurrence trigger, reads an approved tracker, generates a new review document and asks reviewers for decisions. A few lines of its instructions show the intended balance:

Preserve uncertainty: missing replies do not mean work is on track. Do not invent metrics, owners, dates or completion.
People own prioritization and sign-off. Do not change permissions, expand the audience or act on sensitive findings without the required approval.
If a source, connection, permission or output tool is unavailable, explain what is missing and stop the affected action.

---

The feature has four gates: tenant enrollment, admin settings, the environment and the maker’s license. If any of them is missing, the Agent account button simply isn’t there.

1. Tenant enrollment. A global admin enrolls the tenant in the Microsoft Frontier program and accepts the Microsoft Agent 365 Terms of Service. The enrollment starts in the Microsoft 365 admin center under Agents > Overview > Try now. Enrollment provisions the tenant with Microsoft 365 Frontier for AI Teammates licenses.
2. Template activation. In the Microsoft 365 admin center, a tenant admin opens All Agents and filters by Agent template: Yes. Then they select Copilot Studio (Frontier) and activate it. The activation wizard asks which users or groups may create agents with accounts. Only those people can.
3. Early-release environment. The environment’s Release cycle must be Early in the Power Platform admin center.
4. Environment setting. An admin turns on Copilot > Settings > Agent accounts per environment in the Power Platform admin center. Conversely, turning it off removes the button for agents in that environment.
5. Maker license. The maker needs Microsoft 365 E5 with the Microsoft Agent 365 add-on, or Microsoft 365 E7, which includes Agent 365.
6. A free agent license at publish time. Each agent with an account consumes one Frontier for AI Teammates license when you publish it. If none is free, publishing fails. An admin then has to free one from another agent or acquire more.

Where you build the agent and run the pilot

You create the agent itself in Copilot Studio Preview and add the account before the first publish. One detail for European tenants: agent accounts are available in the EEA. In markets where Microsoft licenses Teams separately, the agent still gets its mailbox and directory presence. However, it appears in Teams only if the tenant licenses Teams.

For an architect, the early-release requirement is the one to plan around. The pilot lives in a dedicated environment on an earlier update cadence, not in production. As a result, your ALM path has to account for that.

---

With an account, the agent becomes a directory object your identity team can see and govern. In practice it ends up with two identity artifacts:

• The agent account. A Microsoft Entra account with a mailbox, Teams presence and directory entry.
• Microsoft Agent 365 provisions and governs it and gives admins user-grade visibility and control.
• A Microsoft Entra Agent ID. Copilot Studio creates one for each agent that has an account, and admins manage it separately. Since May 2026, Copilot Studio creates an Entra Agent ID for every new agent. Older agents still use app registrations until you migrate them.

Three details matter for governance.

Publishing fixes the identity

The agent’s email address uses the maker’s alias as a fixed prefix, and the agent reports to the maker. However, in this preview you can’t change the prefix or the reporting relationship. You also can’t change the email address after you publish the agent. Agree on naming before the first publish, because you can’t rename the agent afterwards.

Connector permissions and Conditional Access

When you publish an agent, Copilot Studio attaches API permissions to its Entra Agent ID. It adds them for each Power Platform connector the agent uses. Adding the whole connector as a tool grants Operations.Execute.All; adding specific actions grants individual operation scopes. As a result, Entra and Microsoft 365 admins can review these without opening the Power Platform admin center. The connector runtime still revalidates them against your data and advanced connector policies. The caveat: today, Entra enforces Conditional Access on the agent identity only when the agent runs in Teams. Other channels show the scopes but don’t evaluate Conditional Access on the agent identity yet.

Tool authentication switches to the agent

When you add an account, Agent account becomes the default authentication mode for tools that support it. The account doesn’t automatically grant every permission. So check which identity each tool uses, and grant only what the job needs. Tools set up for end-user authentication still require each person to complete their own sign-in and consent.

Why this beats the previous model

This is the real improvement over the previous model. Without an account, you activate an autonomous agent in one of two ways. “For myself” runs it with the maker’s own credentials; sharing it makes each user run it with their own. An agent account, by contrast, gives the work its own attributable actor. My recommendation is to treat that actor exactly like a new joiner. Give it an owner, a documented purpose, least-privilege access and a review date.

---

This is the section to put in front of your security and compliance teams before any pilot.

Copilot Studio now has two memory models in the GitHub Copilot harness. An agent account switches the agent from one to the other:

	Personal memory (agent without an account)	Shared memory (agent with an account)
Scope	A separate memory store per user	One memory across everyone the agent works with
Who can see it	Private to the user; the maker and other users can’t see it	Anyone who works with the agent can view or delete saved memories
Privacy boundary between users	Yes	None. The agent is guided not to raise one person’s details with others, but there’s no boundary
One-to-one chats	Personal	Still shared, even in one-to-one chats
User opt-out	Maker turns Memory on or off per agent	No opt-out in the preview; using the agent means consenting
Admin control	Per-agent toggle	Can’t be turned off separately; an admin must turn off agent accounts altogether
Retention	Deleted after 28 days without interaction	Deleted after 28 days without anyone interacting

The sentence that matters most is the notice Microsoft shows on the agent’s People card: “Any files or chats you share can be summarized and included in the agent’s responses to any user, even users without permissions to the files or chats and regardless of sensitivity label.”

That’s a deliberate design choice for team processes, and Microsoft documents it openly. Elsewhere in Microsoft 365, a user sees a document only if they have access to it. However, what the agent remembers doesn’t follow that rule. A summary of a confidential spreadsheet shared in a chat can surface for someone who could never open the spreadsheet.

What shared memory leaves out

Microsoft does limit what shared memory keeps. It excludes:

• personal details such as ID numbers, birth dates, account numbers and home addresses
• passwords, credentials, secrets and tokens
• anything someone asks it not to remember
• judgments about anyone’s performance or conduct
• health information and protected characteristics
• information already in the agent’s instructions or knowledge
• conclusions it inferred

When a memory conflicts with the instructions, Microsoft’s guidance has the agent follow the instructions.

There’s a related, separate limitation: agents with an account can’t read protected documents. That includes files labelled Confidential or Internal Only. Microsoft also explicitly warns against relabelling documents to make them readable for testing.

Three rules for a pilot

For a pilot, that leads to three practical rules:

1. Pick processes where everything in scope is fine for the whole team to see. A team execution review fits. A process that touches HR cases, salary data or customer-confidential material doesn’t, until the controls mature.
2. Tell participants how memory works. Explain it in the agent’s instructions and in the pilot briefing, not only through the People card notice.
3. Make “turn off agent accounts” part of your exit plan. Right now it’s the only admin switch that stops shared memory.

---

Agent accounts, triggers in this new form, Skills and memory exist only in the GitHub Copilot harness. You can’t move agents between harnesses in either direction. Choosing the harness is an architectural decision, not a setting you can change later.

Compared with the standard harness, the documentation lists these gaps today:

Area	Standard harness	GitHub Copilot harness
Azure AI Search knowledge	Supported	Not supported
Channels: SharePoint, WhatsApp, Dynamics 365 Contact Center	Supported	Not supported
Manual / custom authentication	Supported	Not supported
Custom entities	Supported	Not supported
Prompt tool	Supported	Replaced by Skills
Computer use	Supported	Planned

Two things carry over and matter for Power Platform teams: solutions and ALM support, and DLP and governance controls. The harness also supports Dataverse tables as knowledge and MCP servers as tools. An agent can still work against your Dataverse data through the Dataverse MCP Server.

Microsoft’s own guidance adds a warning. On this harness, simple scenarios “can incur unnecessary reasoning, latency, and Copilot Credit consumption without materially improving the result”. So for short, predictable interactions, the standard harness and agent flows remain the better fit.

---

Cost works differently from what many teams know from Copilot Studio in Microsoft 365.

• No Microsoft 365 Copilot coverage. A Microsoft 365 Copilot license covers that user’s use of standard harness agents in Microsoft 365 channels. It doesn’t cover GitHub Copilot harness agents: “Creation and runtime activities consume Copilot Credits regardless of the user’s license.”
• Building and testing cost credits too. Using, building, testing and evaluating agents on this harness may consume Copilot Credits.
• Autonomous runs bill to the environment. For shared autonomous agents, Microsoft totals each user’s usage and bills it through the environment that hosts the agent.
• The account license is separate. The Frontier for AI Teammates license covers the account; usage-based charges come on top.

Microsoft publishes estimated credit ranges by task complexity in its billing overview for the harness, plus an estimator. Use those for budgeting, then add monitoring in the Power Platform admin center. Treat any always-on trigger, such as a busy mailbox, as a cost driver to model before go-live.

---

These documented preview limitations each change what you can design:

• No external users. The agent doesn’t respond to anyone outside its tenant, and there’s no workaround.
• No protected documents. It can’t reach sensitivity-labelled content it can’t decrypt.
• New documents only. It can generate new documents but can’t co-author or make targeted edits to existing ones. Office-comment @mentions support limited scenarios.
• Email audience of 250 people at most. Larger threads fail with reference code MCS-4043. The same code can appear when access verification fails for other reasons.
• Partial Microsoft Graph coverage. Agent accounts don’t support all Graph operations and scopes yet.

---

Here’s my reading of where this fits.

It’s the first credible pattern for agents that own a recurring process. Until now, autonomous agents either ran as the maker or needed each user to activate them. A dedicated identity, attributable activity and a recurrence trigger change that. “The agent prepares the weekly review” becomes a design you can defend in an architecture board. That builds on the always-on direction I covered in Microsoft Scout and the organizational context that Work IQ exposes.

Treat it as an identity project, not just a maker feature. The enablement path runs through Microsoft 365 admins, Entra admins and Power Platform admins. Bring all three in before anyone builds the first agent. Agree on naming, ownership and access reviews for agent accounts together.

Keep the standard harness and agent flows where predictability matters. Some work still belongs in agent flows, Power Automate or standard harness agents. That includes deterministic steps, approvals with audit requirements and channels the new harness doesn’t support. A workflow can call an agent for the step that needs reasoning. As a result, you don’t have to pick one model for the whole process. If you’re weighing Copilot Studio against pro-code options, my Copilot Studio vs Azure AI Foundry guide covers the broader trade-offs.

Plan the environment strategy now. Use an early-release environment for the pilot, and set a clear rule that production waits for general availability. Use solution-based ALM from day one, so the agent’s definition is in source control from the first iteration.

---

1. Choose one recurring, team-internal process where every participant may see all data in scope.
2. Confirm Frontier enrollment, the Agent 365 terms and enough Frontier for AI Teammates licenses for the pilot.
3. Activate the Copilot Studio (Frontier) template for a named security group of pilot makers only.
4. Create a dedicated early-release environment and turn on Agent accounts there only.
5. Agree on the agent’s name, email address and owner before the first publish; you can’t change them later.
6. Review every tool’s authentication mode; grant the agent account least-privilege access.
7. Write instructions that state what the agent must not remember, share or decide.
8. Brief participants on shared memory, including the People card notice.
9. Check that the process needs no protected or highly confidential content, and don’t relabel documents to work around it.
10. Review the agent’s API permissions in Entra. Apply Conditional Access, knowing Entra enforces it only in Teams today.
11. Set up Copilot Credit monitoring for the environment, and model trigger volume before go-live.
12. Define the exit plan: who turns off agent accounts, how you reclaim licenses and what happens to outputs.

Agents that hold a seat in a business process are coming whether governance is ready or not. Teams that run a small, deliberate pilot now can say yes with confidence once the feature reaches general availability.

---

Over to you

Would you give an agent its own account in your tenant today? Which process would you trust it with first?

---

Resources

• Delegate shared business processes to agents that are more persistent and proactive with Microsoft Copilot Studio — Microsoft Copilot blog
• Give your agent an account (Frontier) — Microsoft Learn
• FAQ for agent accounts (Frontier) — Microsoft Learn
• Agents powered by the GitHub Copilot harness overview — Microsoft Learn
• Add triggers to an agent (GitHub Copilot) (preview) — Microsoft Learn
• Memory (GitHub Copilot) (preview) — Microsoft Learn
• Compare Copilot Studio agent harnesses — Microsoft Learn
• Manage costs for agents powered by the GitHub Copilot harness — Microsoft Learn
• Microsoft Entra Agent IDs for Copilot Studio agents — Microsoft Learn
• Agent identities and authentication for Copilot Studio — Microsoft Learn