Start from where the permission model already lives
If your organisation runs Microsoft and Salesforce side by side, and most of the ones I walk into do, where to build an agent gets answered by the data long before it gets answered by the product. Put the agent where the records it must read and the permission model that governs them already sit. Most of the rest of this comparison moves within a release or two. That part does not.
An agent earns trust to the degree it inherits an access model somebody already maintains. Run it under an identity the platform governs and its answers to a salesperson stay inside the rules that bound the salesperson. Hand it its own credentials and a standing grant and you have built a second access model nobody reviews on the first one's cadence.
Both vendors understand this. Agentforce runs against the Salesforce sharing model. Copilot Studio can run against the Microsoft directory and the permissions on the content it reads. The failure mode is identical on both sides. A builder in a hurry wires the agent to a connection with broad rights, because that is what got the demo working on Thursday.
Work that already lives on CRM records
An agent whose job sits on accounts, opportunities, cases and the records hanging off them has a strong argument for being built in Salesforce. Sharing rules, the role hierarchy, field level security and territory assignment encode years of decisions about who sees which customer. Reproducing that elsewhere means reimplementing it, and a reimplementation drifts the first time someone changes a rule where the rule belongs.
The mechanics are covered in what Agentforce actually is, so here is only the architectural part. The agent is tied to a user record, and what it reads and writes comes from that record. Over-permission it and you get confident, complete answers carrying data the person asking should never have seen, with nothing in any log marked as an error.
The permission work lands before the interesting part of the build. You need an identity carrying exactly the access the job requires, and somebody reviewing it on a schedule after go-live. A permission audit up front takes an afternoon. The same work after a customer has seen something they should not have takes a fortnight and a written explanation.
Work that lives across documents, mail and service records
Change the data and the answer changes with it. An agent that has to read a signed contract in SharePoint, a thread in Outlook, a policy somebody wrote in Word and a table of internal service records has its governing permission model in the Microsoft directory and on those items. Copilot Studio starts from that position, and an agent built there can run against the asking user's own access.
That inheritance is only ever as good as the file permissions underneath it. Every over-shared site and every link opened to the whole organisation becomes an agent that answers correctly by its own rules and wrongly by anyone's intent. Teams discover their oversharing problem about two weeks into a pilot, and the remediation has nothing to do with the agent.
The second half of the Microsoft answer is where the agent's own records go. Anything it creates or updates, a request it logs or a case it tracks, wants a real table with a real security model behind it. Dataverse exists for that, and an agent keeping its state in a spreadsheet will be the subject of a difficult meeting inside a year.
The hard case is a process that legitimately spans both
The difficult design starts when one piece of work crosses the line. A renewal conversation needs the opportunity and the signed contract. A support case needs the entitlement in CRM and a document somebody uploaded two years ago. Neither vendor can govern data it does not hold, so a person has to decide which model wins and what the other side gives up.
A building products manufacturer I worked with last spring had exactly this. Answering a warranty question needed the entitlement on the Salesforce case and the installation certificate the fitter had uploaded to a SharePoint library. The first build routed everything through Copilot Studio and reached Salesforce over a connection using one integration user. It demoed beautifully and failed security review, because that user could read every case in the org, so the answers were bounded by the filters the builder remembered rather than by anything auditable.
We moved the agent to Salesforce, because the entitlement decision carried the compliance weight and the auditors already trusted the sharing rules. Certificates stayed in SharePoint, and the agent fetched a named document through an action carrying the asking user's identity, so an unauthorised request failed at the document rather than inside the agent's instructions. Three weeks longer than the demo route, and it survived review. The same tension turns up wherever service account identity crosses platforms.
Both common answers cost something real. Routing through one product as the front door means the far side gets reached over a connection, and that connection's identity becomes the argument you have for the rest of the project. Building twice means two sets of instructions, two test suites and two chances for a policy change to land in one place and not the other. I have seen each work and each rot.
Both meters change the shape of what you build
Both vendors charge for agent work by consumption rather than by seat alone, which belongs in the architecture review and not only in the procurement meeting. The units differ between them and they change, so get current terms from your account team rather than from a deck or an article, including this one.
The design consequence is the same on either side. An agent taking six turns to reach an answer costs more than one taking two, which makes the shape of a conversation a cost decision as much as a usability decision. An agent that retries a failed action three times pays three times. Decide who reads the consumption report each month, and what they are allowed to change when the number moves, before anything goes live.
Metering feeds back into the spanning decision. A front door agent calling a second agent behind it meters one piece of work in two places, on two commercial models, in two reports that will not reconcile. Sometimes that stays the right call for governance reasons. It should be a deliberate choice rather than the residue of two teams building in parallel.
Somebody has to be on call for the agent
One question settles more of these debates than any feature comparison. Which team can change the agent's instructions on a Tuesday afternoon, and which team gets paged when it says something wrong at three in the morning. Build where those people already work, and be honest about who they are rather than who the org chart says owns AI.
The Salesforce admin team and the Power Platform team are usually different people with different release cadences and change processes. An agent built in the product the other team owns becomes a ticket every time one sentence needs changing, and instructions need changing more often than anyone budgets for, because agent instructions are policy and policy moves.
Neither team's regression suite covers agent behaviour yet. The agent readiness check covers the ground worth walking before a pilot, and the handoff between human and agent work is the design most teams skip until an escalation goes badly in front of a customer.
Before your next architecture meeting, write down the three records the agent must read and the name of the person who owns the permission model on each. If all three names sit in one team, you have your answer. If they do not, the spanning decision is the project, and the choice between the two products is the small part of it.
