Copilot Studio, Agentforce, or Custom AI Agent?

The pitch for a low-code agent platform is hard to argue with. Drag a few boxes, connect your data, and you have an AI agent answering customers or updating records by Friday. Microsoft Copilot Studio and Salesforce Agentforce both sell that speed, and for a real set of problems they deliver it. The trouble starts a few weeks later, when the agent that demoed beautifully needs to do something the platform was never built to do, and you find out where the walls are.

That is the decision worth getting right before you commit a team to any of them. Not "which platform is best" in the abstract, but which of three paths fits the agent you actually need: Copilot Studio inside the Microsoft stack, Agentforce inside Salesforce, or a custom agent built on the model APIs directly. The gap between them is not marketing polish. It is whether you can change how the agent thinks, which model it runs on, and how many jobs it can juggle before it falls over. Gartner found only 6% of organisations that piloted Microsoft Copilot moved to a larger deployment, and platform limits are a big part of why.

The low-code promise, and where it cracks

Low-code platforms win on the first mile. You skip authentication plumbing, you get a chat surface for free, and a non-engineer can wire up a working flow. For an agent that reads from a knowledge base and answers questions, or that files a ticket into a system the platform already integrates with, that is genuinely the right tool. Building it from scratch would be waste.

The crack appears when your requirement stops matching the platform's assumptions. You want to swap in a cheaper model for a high-volume task, or fine-tune one on your domain. You want the agent to remember a customer across three separate conversations in a way the built-in memory does not support. You want five agents to hand work to each other cleanly. Each of these is a normal, reasonable ask, and each one is where a configurable platform tells you no. You can configure how the agent behaves. You cannot change how it fundamentally works.

What Copilot Studio is actually good at

Copilot Studio earns its place when your company already lives in Microsoft 365. If your data is in SharePoint, your users are in Teams, and your identity runs on Entra, an agent that surfaces information and drafts content inside those tools is low-friction and fast to ship. It assists: it pulls the right document, summarises a thread, reduces the clicks on a task where a human still makes the final call.

Where it stops is worth knowing up front. You use the models Microsoft provides, so swapping in a different model or an open-source one is off the table. If you need a voice agent to answer your reception line, it is the wrong tool, and Microsoft would point you to a purpose-built voice platform. And the multi-agent story looks better in a two-agent demo than in a real deployment with five or six agents covering different domains, where the hand-offs get brittle. For a related take on the assistant side of Microsoft's stack, see our guide on Microsoft 365 Copilot for small businesses.

What Agentforce is actually good at

Agentforce is the opposite of an assistant. It acts. Built into Salesforce and driven by the Atlas reasoning engine, it executes workflows, updates records, and triggers downstream processes without waiting for a human to confirm each step. If your business runs on Salesforce and the agent's whole job is inside that CRM, closing cases, qualifying leads, keeping records clean, it is a strong fit because the data and the actions already live in one place.

The limits mirror Copilot Studio's. Advanced customisation runs out when a workflow gets genuinely complex, and orchestration across many steps has been inconsistent enough that teams report reliability problems at volume. It is also priced and scoped for companies whose gravity is Salesforce. Pull the agent's job outside the CRM, or ask it to reason in ways Atlas does not expose, and you are back to bending your problem around the product.

Where both platforms hit a wall

Strip away the branding and the two platforms fail in the same three places. Model lock-in: you run what the vendor gives you, at their price, on their timeline. Depth: custom prompt engineering, specialised memory, and non-standard tool integration are exactly the things the platforms abstract away, so if your edge depends on them, you cannot build it here. And multi-agent coordination, the thing every vendor demos, tends to hold for two agents and buckle at six.

There is a fourth risk that 2026 made concrete: platform continuity. OpenAI announced it is winding down its no-code Agent Builder, with the product leaving the platform on 30 November 2026, and pointing teams to its code-based SDK instead. Anything you build on a proprietary visual builder is exposed to that vendor's roadmap. When the logic lives in your own code against a model API, switching providers is a config change, not a rebuild. That portability is the quiet advantage of going custom, and it is the same lesson from our build versus buy decision guide: rent the commodity, own the thing that differentiates you.

A decision you can make in an afternoon

You do not need a six-week evaluation. Answer four questions honestly.

If most of your answers sit on the left, use the platform and ship this month. That is the correct, unromantic choice for a large share of internal agents. If they sit on the right, a custom agent on the model APIs will cost more up front and less over three years, because you are not paying a tax to work around limits that were never going to move. Most real companies land in the middle and run a hybrid: platform agents for the commodity jobs, custom agents for the two or three that actually matter. For a look at the tooling behind the custom route, see our overview of AI agent frameworks.

If you are weighing these paths for a specific workflow and want a straight answer rather than a sales pitch, tell us what the agent needs to do and we will tell you which of the three we would build, and why.