If you end up architecting agent connectivity, the selection between Mannequin Context Protocol (MCP) and a standard API has actual penalties. Because the architect, you might be accountable for designing an answer that gives the exterior agent with dependable entry to vital enterprise information with out sacrificing efficiency, safety, or interoperability.
Take into account the problem of Croft & Thread, a legacy B2B attire model partnering with a number one agentic AI private shopper platform to open a brand new direct-to-consumer gross sales channel.
In episode six of Suppose Like an Architect, we reconstruct the architectural pondering course of for this situation. Slightly than trying on the accomplished answer, strolling via this pondering course of helps construct the psychological muscle tissue wanted to judge necessities, weigh trade-offs, and justify your integration strategy.
Use the “What, How, and Why” Method
To design scalable options, we use a repeatable three-step methodology to maneuver from uncooked enterprise necessities to justified architectural selections:
- What: Spotlight key phrases in enterprise necessities to paraphrase the essence of the issue into concise Excessive-Stage Necessities (HLRs). This helps make sure you remedy the appropriate downside from the beginning.
- How: Align technical answer choices on to your HLRs. Use reside diagramming to visualise choices and digital sticky notes to seize questions, assumptions, and selections.
- Why: Doc your justifications. Creating an Architectural Resolution Document (ADR) ensures that stakeholders, and your future self, perceive the rationale behind a selected path.
Be taught concerning the Suppose Like an Architect sequence
Design future-ready options on this interactive livestream sequence. Break down real-world eventualities, be a part of reside Q&As, and vote on the subjects you wish to see subsequent.
What: From Enterprise Necessities to HLRs
Within the “What” step, let’s take a look at the particular problem from episode six. We begin with a uncooked enterprise requirement and use highlighting to point the important thing components, as proven under.
Paraphrase into HLRs
By highlighting key phrases, we filter out the enterprise narrative to make sure we deal with the core issues from the beginning. Based mostly on the third-party agent situation, we set up 5 distinct HLRs:
- Retrieve wealthy product information for the agent.
- Securely expose pricing to the exterior agent.
- Present real-time warehouse stock lookups.
- Allow the agent to position orders on behalf of the shopper.
- Proactively push achievement and repair updates again to the private shopper platform.
Observe that the HLRs paraphrase reasonably than use the precise phrases from the enterprise requirement. That is important for validating with enterprise stakeholders that you simply understood the intention of their necessities.
To proceed with evaluating answer choices, let’s transfer into the “How” step by following the path of questions, assumptions, and selections captured throughout our reside session.
Architect the Agentic Enterprise with MuleSoft
Uncover how you can construct safe, scalable integrations for AI brokers. This information explores the foundational ideas of utilizing MuleSoft to energy your agentic enterprise.
How: Aligning options to your HLRs
Within the “How” step, we consider answer choices towards the HLRs. To maintain our pondering organized, we monitor questions, assumptions, and selections alongside our technical diagram.
Evaluating HLR 1: Retrieve wealthy product information
We begin by asking the place that wealthy product information lives, and we assume {that a} Product Data Administration (PIM) instrument is the most effective supply of that information. Subsequent, we should decide how you can ship the information to the exterior agent platform. We make two key assumptions right here: first, for the reason that agent platform works with a number of distributors, it maintains its personal product catalog reasonably than querying every vendor in actual time; second, Croft & Thread’s catalog information is comparatively static. We determine to implement a day by day scheduled batch job by way of API to push these catalog updates. Lastly, we determine to route this integration via MuleSoft to offer a vital layer of abstraction and guarantee future flexibility ought to the mixing ever have to transition to FTP or different various feed strategies.
Evaluating HLR 2 and three: Securely exposing pricing and real-time stock
Subsequent, we have to securely expose pricing to the agent. We assume that Salesforce is the supply of account pricing and that there aren’t any exterior customers supplied in Salesforce. Whereas Headless360 is an possibility for agent connectivity, we be aware a present limitation: it supplies restricted assist for service accounts as a result of authentication mechanism. Based mostly on this, we determine to make use of an API as an alternative, with a service account,in order that we are able to use a longtime machine-to-machine integration sample to reveal Salesforce pricing. We then determine to route this API entry via MuleSoft’s MCP Bridge to securely translate Salesforce pricing to the agent via an MCP instrument. This enables the agent to dynamically work together with pricing information with out the restrictions of strict, deterministic REST constraints.
To offer real-time stock availability to the agent, we assume Croft & Thread’s Warehouse Administration System (WMS) serves because the system of report, because it manages achievement throughout their a number of warehouse areas. This assumption drives our determination to reveal the real-time stock name by way of the established MCP Bridge. Utilizing this unified layer centralizes our agent connectivity technique, permitting the agent to securely question each pricing and reside stock via a single MCP server.
Evaluating HLR 4 and 5: Putting orders and pushing achievement updates
Lastly, we work on putting orders and sending order standing again to the agent platform as our last two necessities. Beginning with order placement, we assume their platform has its personal Order Administration System (OMS) to trace multi-vendor orders. We additionally assume that a longtime firm like Croft & Thread has an Enterprise Useful resource Planning (ERP) system for its core operations. This ERP can be the system of report for orders. We determine to route order submissions to the ERP as an alternative of passing via Salesforce to reduce intermediate steps and eradicate potential factors of failure. We additionally determine to deal with this system-to-system routing by way of API calls via our integration layer, MuleSoft, as a result of we now have already established it as the mixing layer for the agentic platform based mostly on the opposite necessities.
To deal with the order standing updates, we assume an API push notification is the most effective path to offer real-time standing modifications as a result of the agentic platform would need probably the most up-to-date info for his or her clients. Nevertheless, the structure requires a dependable mechanism to deal with failed notifications, for instance, if there’s a community outage. MuleSoft supplies assured supply capabilities, making it the only option to handle these outbound push notifications.
Why: Justify your design with ADRs
Within the “Why” step, you justify your path to stakeholders and your future self. Throughout the livestream, we emphasize that an architect’s worth isn’t within the answer, however within the rationale. With the qu
estions, assumptions, limitations, and selections we captured, we are able to apply the steering within the Architectural Selections: A Human-Led, AI-Powered Method weblog put up to create an ADR utilizing LLMs. We use the notes we took within the “How” step to:
- Tie assumptions to selections: A call might have to vary if an assumption is later confirmed incorrect. For instance, if the belief that the agentic platform has its personal Order Administration System (OMS) is wrong, the choice to make use of a system-to-system API sample for order creation would possibly have to shift to a special strategy.
- Doc the “pondering work”: Whether or not you current a posh diagram or a easy slide, crucial half is that the pondering work, together with questions, assumptions, and selections, is documented.
Professional Q&A
Throughout the session, Ross Belmont (Product Administration, Integration) and Gulal Kumar (Software program Engineering Architect) joined us to dive deeper into the technical nuances of MCP and integrations.
Understanding MCP vs API (and expertise)
- How do you determine between MCP and conventional APIs? In case you have an MCP shopper (like an agent), you must join utilizing an MCP server. Sidestepping MCP to focus on REST APIs means lacking out on capabilities designed particularly for brokers that deterministic REST purchasers can’t deal with. For system-to-system integrations with out an agentic shopper, persist with conventional APIs.
- In essence, between MCP vs API, is the reply to make it each? A number of technical components affect this determination. In case you have a ready-built MCP server that handles your whole agent-specific integrations, conventional APIs are pointless for these explicit interactions. API integrations solely enter the image for brokers as a fallback when MCP servers aren’t available. In these eventualities, the choice usually comes right down to the place you need the mixing effort to sit down: constructing an MCP server requires work on the supply aspect, whereas pointing an agent at a standard API shifts the burden to the buyer aspect.
- Is MCP the primary go-to for an agent now reasonably than expertise? Expertise are a implausible option to instruct an agent on how you can accomplish a job, however with regards to fetching information from downstream methods, MCP or APIs are normally a greater match, though APIs require further configuration. One of the best strategy is commonly combining them: writing a talent that calls an MCP instrument or an API to retrieve the information, after which having the talent course of it. If further processing is required or if an current MCP server is missing, the talent + API mixture works properly.
- Does utilizing MCP make sense throughout prerelease API improvement (the place issues can change), or do you have to design the API upfront? Beginning with MCP makes a number of sense when there are nonetheless many unknowns, as it might probably assist disguise underlying volatility from the agent to get began shortly. Alternatively, an API-first strategy stays extremely efficient as a result of instruments like MuleSoft permit for API stubbing. This makes it straightforward to construct mock endpoints for testing when you work towards a deeper understanding of the mixing. Finally, the path is determined by the agent improvement crew’s preferences and the way they plan to orchestrate routing, particularly in the event that they find yourself coping with many various distributors working their very own MCP servers with an identical instruments.
Safety and the function of MuleSoft
- Why use MuleSoft as an alternative of direct APIs? If underlying methods retire or API contracts change, MuleSoft supplies an abstraction layer that protects the mixing. MuleSoft acts as a gateway, offering out-of-the-box insurance policies for price administration, safety, governance, and observability, whereas dealing with “final mile ugliness” for legacy methods missing fashionable APIs.
- If I don’t want MuleSoft for a broader integration, can I simply wrap current Apex callout logic into an Invocable methodology and expose it via a Salesforce-hosted MCP server? This works in case your integrations are predominantly inside your organization, however you’d nonetheless want a person in Salesforce for the hosted MCP connection. If you wish to keep away from constructing out an MCP server fully, a short-term answer is to make use of a regular API alongside some customized logic (or talent) on the agent aspect.
MCP servers and authentication
- When do you have to use out-of-the-box MCP servers versus customized MCP servers? Salesforce presents out-of-the-box servers for core CRM information, Knowledge Cloud, and Tableau. Customized instruments are sometimes constructed for safety causes: directors might not belief AI brokers with the identical broad entry as a human person, so customized instruments can tightly constrain the agent’s permissions. Customized servers are additionally invaluable for reframing exterior system information (like uncooked DocuSign envelopes) into customer-centric CRM phrases.
- How does authentication work with MCP presently? As we speak, widespread MCP purchasers (like Claude) require per-user interactive OAuth, that means a human should click on to grant entry. Whereas it’s technically potential to wire a customized agent to make use of machine-to-machine authentication (like JWT bearer flows or certificates), it presently requires considerably extra implementation effort.
Closing wrap-up
An essential takeaway for architects is to prioritize the best and most traditional instrument accessible. Begin with conventional APIs for system-to-system integrations and use MCP for direct agent interactions earlier than contemplating specialised options just like the MCP Bridge. As your architectural panorama grows extra advanced, using MuleSoft turns into very important. Its strong governance and observability capabilities present the mandatory guardrails to maintain integrations safe, manageable, and clear.
- Subsequent episode: Be a part of us for the subsequent episode on July thirtieth, the place Miriam will return to speak about navigating trade-offs and saying no with confidence.
- Vote on future episodes: Assist us form the way forward for the sequence. Inform us what subjects you wish to see and the way we are able to present extra worth to you.
