Most AI at work still starts the same way: a person opens a chat and types a prompt. No prompt, no work.
With Copilot Studio, that is changing. On October 15, Microsoft announced new Copilot Studio capabilities for delegating shared business processes to agents. Now rolling out through the Frontier program, they let agents built in Copilot Studio take care of tasks when they need to be done, without anyone prompting them. An email arrives, or it’s Tuesday morning and the weekly review is due, and the agent gets to work. It gathers the data, chases the missing explanations, remembers what was left open last time, and prepares the decision for people.
This is process automation with Copilot Studio agents. Rule-based flows already handle the predictable steps. Agents now take on the work between those steps, the parts that need judgment, follow-up and context. And they do it on their own, as part of the process rather than as a chat someone remembers to open.
What Copilot Studio brings in Frontier:
Pro-code has made this possible for a while. Development teams have built agents that start on events, run under their own identities and keep state. With Copilot Studio, these become platform building blocks with admin controls, lifecycle management and attribution. Business units and makers will be able to automate shared processes with agents, not just developers.
This is how Copilot Studio helps organizations become AI-native: routine tasks get done because they need to be done, not because someone remembered to prompt for them. Agents prepare, follow up and remember. People decide.
It’s the next step in the story: first AI moved from answers to actions, then teams got a memory curated by AI, and now agents start the work themselves. Let’s take a closer look.
This is the core of the announcement. Triggers in the GitHub Copilot harness let agents built on the harness stay “always on.” When configured, an external signal (like an email) or a set schedule starts the agent’s cycle, with no prompt needed.
That changes the role of AI in a process. Instead of waiting for someone to remember to ask, the agent runs its part of the work when the process needs it:
Add the upcoming option for agents to use their own browser-enabled cloud computer, and processes that cross many systems become realistic candidates for redesign.
Automation that starts by itself needs clear limits, though. The more the agent does without a prompt, the more important it is to decide up front what it may do on its own and where it hands over to a person.
An agent that starts work by itself also needs to work as itself. With an agent account, the agent works in Microsoft 365 with its own credentials, much like a person would.

In practice:

Why does this matter? In the previous post about the SharePoint knowledge base, Autopilot uploaded a meeting transcript “As you” after the user approved it. With agent accounts, the agent acts as itself.
That speaks directly to one of the points in From Answers to Actions with Work IQ: you need to be able to tell “the person did it” from “an agent did it.” Microsoft says work can now be attributed to the agent, while the process owner keeps control of its scope. That improves observability and traceability.
Admins can scope access, apply extra controls and manage the agent’s lifecycle. Microsoft says further access policies, quality and cost management, and lifecycle controls for these agents are planned for the coming months.
Recurring processes have their quirks. “This cost center always reports late.” “Legal wants to see contracts over a certain value.” Today that knowledge sits in someone’s head, and it has to be explained again every time.
Business process memory lets the agent carry users’ preferences and process context into each new cycle. When one person points out a quirk to the agent, it becomes shared knowledge that everyone else benefits from. People need to repeat less every time they hand work to the agent.
Makers stay in control. Through the agent’s instructions, they set how the retained context is used and which business records and policies are authoritative.
This pairs nicely with the SharePoint knowledge base:
Both address the same old problem: the person who knows leaves, and part of the memory leaves with them.

Over the coming months, Microsoft plans to roll out agent refinements. These use the agent’s own activity to suggest improvements to the maker, who can review, test and apply them:
That is a smart loop: the agent helps its maker improve both quality and cost.
Microsoft’s example is a budget management agent built by a finance lead:
The team spends less time piecing together what happened and keeps full authority over allocations and spending.
Early customers are already using these capabilities. At Ooredoo Qatar, an executive business-case review agent works across Outlook, Teams and Word. It reviews incoming proposals against company policy and precedent and prepares decision-ready briefs for executives.
If an agent is going to work like a colleague, it also needs to be managed like one. That is the role of Microsoft Agent 365, the control plane for agents. It has been generally available for the Commercial segment since May 1, 2026, and it is built around three things: observe, govern and secure the agents in an organization.
For agent accounts, Agent 365 is not an optional add-on in the background. Agent 365 provisions and governs the agent accounts, giving admins the same kind of visibility and control they have over user accounts.
When a Copilot Studio agent with an account is published, it is provisioned with:
A nice detail: the agent’s email address uses the maker’s alias as a prefix, and the agent reports to the maker. Just like a new hire, the agent has a manager. In this preview, the prefix and the reporting relationship can’t be changed, and the email address is fixed once the agent is published, so plan the agent’s identity before publishing.
Copilot Studio agents plug into Agent 365 automatically, with no manual registration or SDK work:
This is also where the pro-code point from the beginning shows. Pro-code agents need their identity set up manually. Copilot Studio creates the agent identity automatically and connects it to Agent 365 governance.
This is a preview, and the current limitations are worth reading before choosing the first process:
The agent is becoming a colleague, not just a tool. It has an identity, a manager, a place in Teams and Outlook, memory and a schedule. That makes it easier to use, and it also makes it something that needs to be managed like a colleague.
A few questions to sort out before the first production process:
The three questions from the Work IQ post still apply: Is it allowed? Is it allowed for an agent? Does a human need to approve this specific action? The difference now is that the agent itself is the identity being asked.
These features are rolling out now through the Frontier program, with more capabilities coming soon. Agent refinements and additional admin controls are planned for the coming months. Agent accounts require Frontier enrollment, a maker license with Agent 365 (Microsoft 365 E5 + Agent 365 add-on, or Microsoft 365 E7), and a Microsoft 365 Frontier for AI Teammates license per agent, with usage billed in Copilot Credits.
Microsoft’s advice matches mine: start with one shared business process. Pick one that recurs, has clear decision points, and currently relies on a few people remembering how it works. In this preview, also pick one where the content isn’t protected and the team is comfortable sharing it with the agent.
The previous posts covered how AI moves from answering to acting, and how teams gain a memory curated by AI. This step gives the work itself an owner that doesn’t forget, doesn’t go on holiday, and starts on time, without waiting for a prompt. People stay in the driver’s seat.
Which shared process in your organization would you hand to an agent first?
Previously in this series: From Answers to Actions with Work IQ and SharePoint Knowledge Base – Team Memory, Curated by AI.
Sources and further reading

This week, we discuss AI yes/no deciders, the SaaS apocalypse, Bending Spoons, and Oxide's funding. Plus, why Google Docs still has no dark mode.
Watch the YouTube Live Recording of Episode 594
Edited and produced with PodEditor, the native Mac podcast editor.
If you have ever tried to export a SQL Server database to a .bacpac file with sqlpackage, you have most likely run into the dreaded SQL71627 error, complaining about a Windows user or login. I ran into it myself a few years ago, and the only workaround was to drop the offending users from the database (or a copy of it) before running the export.
With sqlpackage 170.6.28-preview, that workaround is no longer needed. The Export action has two new properties that let you remove objects that are not compatible with Azure SQL Database while exporting, and write a report of what was removed.

Before looking at the new options, a quick recap of the two file types, as they are often confused.
A .dacpac file contains the schema of a database - tables, views, procedures, users, permissions and so on - described in a model.xml file. You get a .dacpac by building a SQL Database project, or by running sqlpackage /a:Extract against a live database. You deploy it with sqlpackage /a:Publish, which compares the .dacpac with the target database and generates an incremental script that brings the target up to date. The target can be a new or an existing database, and the existing data in the target is kept. A .dacpac can optionally contain table data as well (/p:ExtractAllTableData=true), but it is normally used for schema only.
A .bacpac file contains both the schema and the data from all tables in the database. You create it with sqlpackage /a:Export and restore it with sqlpackage /a:Import, which always creates a new database (or imports into an empty one). Think of it as a logical, portable backup. Unlike a native .bak backup, it can be restored to a different SQL Server version and to Azure SQL Database.
Both are just zip files, so you can rename them to .zip and have a look inside. A .bacpac has a Data folder with the table data in BCP format next to the model.xml file.
Microsoft has more details in the data-tier applications documentation.
The .bacpac format was designed for moving databases to and from Azure SQL Database. For that reason, the Export action always validates the schema against Azure SQL Database, even if you plan to import the .bacpac to another SQL Server instance. Any object that is not supported in Azure SQL Database makes the export fail, and the most common offenders are Windows users and logins.
Here is an export of a LocalDB database with a Windows user:
sqlpackage /a:Export /scs:"Data Source=(localdb)\mssqllocaldb;Initial Catalog=TestBed3;Integrated Security=false;Encrypt=false" /tf:TestBed.bacpac
Connecting to database 'TestBed3' on server '(localdb)\mssqllocaldb'.
Extracting schema
Extracting schema from database
Resolving references in schema model
Validating schema model
Validating schema model for data package
Validating schema
*** Error exporting database:One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71627: The element User: [winadmin] has property AuthenticationType set to a value that is not supported in Microsoft Azure SQL Database v12.
Error SQL71627: The element Login: [MYPC\Administrator] has property IsMappedToWindowsLogin set to a value that is not supported in Microsoft Azure SQL Database v12.
The DacFx issue SqlPackage - option to skip Windows logins (microsoft/DacFx#426) was originally reported for a SQL Server connected to Azure Arc, where the export failed on NT AUTHORITY\SYSTEM. But it is not an Azure Arc issue - any database with a Windows authenticated user will fail in the same way.
sqlpackage 170.6.28-preview adds these two properties to the Export action:
/p:ExcludePlatformIncompatibleObjects=({None|SqlAzureV12} 'None')
Specifies the target platform whose incompatible objects should be excluded from the exported package and included in the compatibility report. Use None to disable exclusion
/p:CompatibilityReportPath=(STRING)
Specifies the path for the JSON Azure compatibility report. When not specified, no JSON report file is written.
The default for ExcludePlatformIncompatibleObjects is None, so the existing behaviour does not change unless you opt in. Set it to SqlAzureV12 to have incompatible objects removed from the exported package. The source database is not modified.
Running the same export again with the new options:
sqlpackage /a:Export /scs:"Data Source=(localdb)\mssqllocaldb;Initial Catalog=TestBed3;Integrated Security=false;Encrypt=false" /tf:TestBed.bacpac /p:ExcludePlatformIncompatibleObjects=SqlAzureV12 /p:CompatibilityReportPath=testbed3.json
Connecting to database 'TestBed3' on server '(localdb)\mssqllocaldb'.
Extracting schema
Extracting schema from database
Resolving references in schema model
Validating schema model
Validating schema model for data package
Validating schema
Prune Azure SQL Database incompatible objects
Processing tables for data extraction
Exporting data from database
Exporting data
Processing Export.
Processing Table '[dbo].[Artist]'.
Processing Table '[dbo].[PlaylistTrack]'.
Processing Table '[dbo].[InvoiceLine]'.
Processing Table '[dbo].[Customer]'.
Processing Table '[dbo].[Employee]'.
Processing Table '[dbo].[Track]'.
Processing Table '[dbo].[MediaType]'.
Processing Table '[dbo].[Genre]'.
Processing Table '[dbo].[Playlist]'.
Processing Table '[dbo].[Invoice]'.
Processing Table '[dbo].[Album]'.
Processing Table '[sqlproj].[DeploymentHistory]'.
Azure Compatibility Report:
Excluded objects: 3
Warnings: 2
Successfully exported database and saved it to file 'TestBed.bacpac'.
Notice the new "Prune Azure SQL Database incompatible objects" step, and the short summary at the end.
If you specify CompatibilityReportPath, you also get a JSON file with the details. This is the report from the export above:
{
"exportDate": "2026-10-16T07:59:27.1555006Z",
"sourceDatabaseName": "TestBed3",
"sourceServerVersion": "Microsoft SQL Server 2025 (RTM-CU8-GDR) (KB5122769) - 17.0.4085.5 (X64) \n\tAug 26 2026 17:29:26 \n\tCopyright (C) 2025 Microsoft Corporation\n\tExpress Edition (64-bit) on Windows 10 Enterprise 10.0 \u003CX64\u003E (Build 26200: ) (Hypervisor)\n",
"targetPlatform": "AzureSqlDatabase",
"summary": {
"totalObjectsProcessed": 257,
"objectsExcluded": 3,
"warningsGenerated": 2
},
"excludedObjects": [
{
"objectType": "SqlLogin",
"schemaName": null,
"objectName": "MYPC\\Administrator",
"excludedBecause": "DirectlyUnsupported",
"reason": "Windows authentication logins are not supported in Azure SQL Database.",
"recommendation": "Create a contained database user or use Microsoft Entra authentication.",
"warningCode": "ASDB_WINDOWS_LOGIN",
"dependsOn": []
},
{
"objectType": "SqlUser",
"schemaName": null,
"objectName": "winadmin",
"excludedBecause": "DirectlyUnsupported",
"reason": "Windows-authenticated database users are not supported in Azure SQL Database.",
"recommendation": "Create a contained database user or use Microsoft Entra authentication.",
"warningCode": "ASDB_WINDOWS_USER",
"dependsOn": []
},
{
"objectType": "SqlPermissionStatement",
"schemaName": "Grant.Connect.Database",
"objectName": "dbo",
"excludedBecause": "DependsOnExcludedObject",
"reason": "Windows authentication logins are not supported in Azure SQL Database.",
"recommendation": "Create a contained database user or use Microsoft Entra authentication.",
"warningCode": "ASDB_WINDOWS_LOGIN",
"dependsOn": [
"MYPC\\Administrator",
"winadmin"
]
}
],
"warnings": [
{
"objectType": "SqlDatabaseOptions",
"schemaName": null,
"objectName": null,
"warningCode": "SqlDatabaseOptions.IsTornPageProtectionOn",
"message": "Property \u0027IsTornPageProtectionOn\u0027 was reset to its target-platform default. Property is not supported on the target platform.",
"recommendation": "Review the Azure SQL Database compatibility report."
},
{
"objectType": "SqlDatabaseOptions",
"schemaName": null,
"objectName": null,
"warningCode": "SqlDatabaseOptions.PageVerifyMode",
"message": "Property \u0027PageVerifyMode\u0027 was reset to its target-platform default. Property is not supported on the target platform.",
"recommendation": "Review the Azure SQL Database compatibility report."
}
]
}
A few things worth noting:
excludedObjects lists everything that was left out of the .bacpac. The excludedBecause value tells you if the object itself is unsupported (DirectlyUnsupported), or if it was removed because it depends on an excluded object (DependsOnExcludedObject). In this case the GRANT CONNECT permission for the Windows user was removed as well, as it would be invalid without the user.reason and a recommendation, so the report doubles as a to-do list for setting up access in the new database, for example with Microsoft Entra authentication or contained database users.warnings lists properties that were not removed, but reset to the Azure SQL Database default value - here two database options related to page verification.The report is a good thing to keep with the .bacpac file, so you know exactly what is missing after the import.
The feature is in the 170.6.28-preview release of sqlpackage. If you use the .NET tool, you can install or update to the preview like this:
dotnet tool install -g microsoft.sqlpackage --version 170.6.28-preview
Exporting a database with Windows users to a .bacpac no longer requires you to clean up the database first. Add /p:ExcludePlatformIncompatibleObjects=SqlAzureV12 to the Export command to leave out objects that Azure SQL Database does not support, and add /p:CompatibilityReportPath to get a JSON report of what was excluded and why.
As this is a preview, please give it a try and report any issues or feedback in the DacFx GitHub repository.
This is a preview-channel build for the PowerToys 0.102 release train, produced from the stable branch. It follows v0.102.2862.0; these notes cover changes since that preview, not the complete 0.102 versus 0.101 changelog. This is not the final stable release.
| Description | Filename | sha256 hash |
|---|---|---|
| Per user - x64 | PowerToysUserSetup-0.102.2883.0-x64.exe | 8F76B417BD374AA75557DF8CE4EE28430D5F0B734E94B9E91FFE4DA0579AA52F |
| Per user - ARM64 | PowerToysUserSetup-0.102.2883.0-arm64.exe | F739926D12AA251D683912B88FD1EA00B3A864089745A49A53D4F3EDFD5E2FCD |
| Machine wide - x64 | PowerToysSetup-0.102.2883.0-x64.exe | 8E7D8608CE97AF984E0E0A3825EA570DD2708C4410F625C75FFC25065C33F3D2 |
| Machine wide - ARM64 | PowerToysSetup-0.102.2883.0-arm64.exe | 9F7D98587FCE90EE4075018455E758E1A33E48ED3B2FBC864D508E6B52DFC26E |