Joule, Agentforce, Copilot: when does your own agent make sense?

If you run SAP, Salesforce and Microsoft 365, AI agents now come more or less built in. SAP embeds Joule in its applications, Salesforce offers Agentforce on its own platform, and Microsoft brings Copilot into Office, Teams and Dynamics 365. At first glance, building your own agent seems unnecessary.

It isn’t quite that simple. The answer depends less on how good each agent is and more on the shape of the process. This article looks at what native agents are built for, where they reach their limits, and how to combine the two sensibly.

Their biggest advantage is context. Joule knows SAP’s applications and data model. Agentforce works with Salesforce data, flows and the platform’s permission model. Copilot can reach mail, documents, chats and calendars in Microsoft 365. None of them has to learn what a sales order or an opportunity is. They sit where the data lives.

Then there’s the user interface. People stay in the application they already know, and the agent shows up there as an assistant or an action. The vendor’s roles, permissions and privacy settings apply automatically, and the vendor takes care of operating and improving the agent.

For tasks inside a single system, that is hard to beat. Summarizing an opportunity, drafting a reply to a service request, pulling figures from the ERP, following up on a meeting: before building anything, check what the native agent already does.

Things get harder when a business process crosses system boundaries. Order-to-cash is a good example. The opportunity is won in Salesforce, the sales order is created in SAP, and questions and approvals go through Outlook or Teams. Each native agent sees its own slice. None of them sees the whole process.

Three issues carry particular weight:

• Processes spanning several systems: an agent built for one platform rarely drives steps in other platforms reliably. Handovers stay manual or get patched with point-to-point integrations.
• Transactions in other systems: reading data from another system is usually solvable. Creating an SAP order from a Salesforce context, with checks, approvals and protection against duplicate execution, is a different job.
• Consistent governance: each vendor handles permissions, logging and approvals its own way. Run three agent platforms and you have three rulebooks and three logs, with no shared view of what agents are doing across the company.

None of this is a flaw in the individual products. Vendors optimize for their own platform, which makes sense from where they stand. The gap opens up between platforms, which is often exactly where most of the manual work sits.

voluro Nexus is the execution and governance layer between agents and enterprise systems. It doesn’t replace native agents. You can register them in Nexus and make them part of a process, just like your own agents built with LangGraph or connected via MCP.

One way this can play out in order-to-cash: Agentforce prepares the won opportunity in Salesforce. Nexus takes over, checks the business partner, prices and availability in SAP, and decides under your rules whether the order is created automatically, needs approval or is blocked. Nexus then updates the opportunity and sales gets notified.

Every agent involved runs under the same policies and the same audit trail. Governance is decided by Nexus, not by the language model. So you can always trace which agent triggered which action in which system, and when, regardless of vendor.

Your own agent pays off when a process is specific to your company and no vendor covers it. That often applies to the very areas where you differ from competitors: your own pricing logic, special delivery terms, exception rules that have grown over years.

Even then, you don’t have to start from scratch. Nexus turns existing SAP OData services, Salesforce flows, Apex actions and custom APIs into controlled agent tools that several agents can share. For processes such as order processing or delivery exceptions, Process Packs provide prepared business solutions that are mapped onto your system landscape during the project.

So the key question is rarely “native or custom?”. A more useful one is: where does the process end, and who controls the steps between systems?