AI’s biggest breakthrough isn’t a model or an agent. It’s a protocol.

The investment that should survive the next model

AI’s biggest breakthrough isn’t a model or an agent. It’s a protocol. For enterprise AI, that is my investment thesis, not a claim that language models stopped improving or that one technical standard solves integration. The practical question is what a business can keep when its preferred assistant changes.

Coming from enterprise technology leadership and now advising businesses, I look at the responsibilities that remain after a product announcement: maintaining integrations, explaining permissions, resolving conflicting data and supporting the people who rely on the result. A convincing interface has to earn its place in that operating environment.

Consider an inventory capability built separately for a service assistant, a store assistant and an ecommerce assistant. If each project independently interprets stock, pickup eligibility and reservation rules, the company is paying repeatedly to solve the same business problem. It is also creating several places where its customer promise can drift.

A common connection standard creates an opportunity to consolidate that work behind a capability the business understands and owns. The benefit is conditional on good service design and real reuse. Wrapping three inconsistent processes in the same protocol would preserve the inconsistency while making it easier to distribute.

This article develops the argument from my LinkedIn post into a decision framework. The retail scenario is illustrative, not a reported client implementation or a performance benchmark. The aim is to show what I would test before recommending a wider investment.

The most durable AI investment may be a business capability that several assistants can use correctly. I would fund that reusable foundation before assuming the next model announcement requires another integration project.

Michel Junior Julien

What MCP actually standardises

The Model Context Protocol introduction describes MCP as an open standard for connecting AI applications to external systems. A compatible application can discover capabilities exposed by a server and use them to obtain information or perform supported operations. This is the useful starting point, before attaching broader claims about autonomy or transformation.

The official architecture overview distinguishes the host application, its clients and the servers providing capabilities. Servers can expose tools, resources and prompts. The protocol does not dictate the application's reasoning strategy or how it manages the supplied context. Those choices remain part of the application and implementation.

For an executive, the distinction is straightforward. MCP can make the connection more consistent. It does not decide whether a store may promise an item, whether a customer qualifies for an exception or whether a refund was successfully recorded. Those are business and transaction responsibilities.

I would therefore describe an MCP initiative in terms of the capability being exposed. Inventory availability for an eligible store is meaningful. Connecting our AI to everything is too broad to price, govern or evaluate. A useful proposal identifies the consumer, the permitted operation, the authoritative information and the condition that counts as success.

Implementation versions and supported features still matter. Before choosing a client and server, confirm the versions, authentication approach and required capabilities they both support. A standards badge is a starting point for compatibility testing, not an acceptance test for the complete workflow.

MCP complements APIs; it does not replace your architecture

An order management system may already provide an API for availability and reservations. An MCP server can expose selected operations from that service in a form an AI application can discover and invoke. The underlying API, access rules and system of record can remain in place.

That distinction protects an existing investment. The team does not need to rebuild inventory management because an assistant needs access. It needs to determine which capabilities to expose, what information is necessary and how the assistant will handle a response it cannot safely interpret.

There are two design extremes to avoid. Exposing every low-level endpoint transfers too much business interpretation to the assistant. Creating one enormous tool that can perform any commercial action makes authority and failure diagnosis difficult. I would start with small, bounded business operations whose effects are easy to explain.

For example, check pickup eligibility can combine an item, location, requested time and current fulfilment policy. Its response should distinguish eligible, ineligible and unknown, with reasons. That is a stronger contract than returning several raw records and expecting each assistant to invent the meaning of available.

MCP also has to justify its own overhead. If one stable application already calls a reliable API and there is no credible reuse requirement, another interface may add maintenance without removing work. Conventional integration remains a valid choice. Adopt the protocol where a common interface solves a concrete problem.

Follow one inventory promise across the business

Imagine a customer asking whether a medium jacket can be collected from a particular store this evening. Customer service, a store associate and the website may all receive that question. They should not need three independently maintained interpretations of stock and pickup policy to answer it.

The proposed shared service checks the product identifier and variant, the store, sellable stock, existing reservations and pickup conditions. It returns a timestamp, the relevant location and an explicit eligibility result. It should distinguish an item physically present from an item the retailer can responsibly promise.

The service might report that two units were available five minutes ago but that the store's latest inventory update is delayed. In that case, the correct answer may be that availability cannot yet be confirmed. A model should not turn a stale quantity into a confident collection promise because the customer asked urgently.

If the customer then asks to reserve the jacket, a separate operation should recheck availability and authority before committing. The earlier read did not lock the item or create a reservation. Another customer may have bought the last eligible unit while the conversation continued.

This is where an apparently simple agent demonstration becomes a real architecture decision. The value lies in maintaining one dependable definition of the promise, then allowing suitable interfaces to use it. The conversation can vary by channel while the inventory obligations remain consistent.

Design the business contract before the connector

The MCP tool specification supports defined inputs and structured results, including output schemas. Use that structure to make a business operation understandable and testable. A technically valid response is necessary, but the service still needs to represent the business situation correctly.

For pickup eligibility, I would define the required item, store and time inputs, then specify the possible results. An eligible result includes its evidence timestamp and expiry. An ineligible result provides a stable reason. An unknown result identifies missing or unreliable evidence without pretending it is a confirmed no.

Document effects as carefully as inputs. A read must not quietly create a hold. A reservation should return a durable reservation identifier, its expiry and the system that recorded it. The person using the assistant should be able to distinguish a proposed reservation from a completed one.

Keep commercial rules in the service that owns them where practical. Pickup cutoffs, restricted products and allocation limits should not be rewritten into every assistant's prompt. This makes a policy change easier to apply consistently and gives the operating team a place to inspect the rule that was actually used.

Version changes deliberately. If a service changes the meaning of available, every consumer can be affected even when the response shape stays identical. Maintain representative acceptance cases, announce consequential changes and define a retirement path for older contracts. Reuse creates shared value and a shared obligation to manage change.

A successful connection is not permission to act

MCP has an authorization framework for protected access. That helps establish how a client obtains access to a server. It does not decide your company's commercial approval thresholds or grant every connected application the same authority. Those policies have to be expressed and enforced in the implementation.

A service employee may be able to inspect stock across stores while being permitted to reserve only for an identified customer. A marketing assistant may need aggregate availability without customer records. Both could use compatible clients, but their permitted operations and data should differ.

For the worked example, the reservation service should evaluate the caller, delegated purpose and requested action when the write occurs. It should reject an operation that exceeds the permitted scope even if the assistant describes a plausible reason. A natural-language explanation is not an approval credential.

Human confirmation should name the actual commitment: which item, which store, for whom and until when. A vague confirmation to continue is insufficient if the plan has changed. Recheck material conditions after approval, because consent to an earlier proposal does not settle a later price, quantity or location change.

This also affects organisational ownership. The platform team may operate the connection, but the commercial owner must define the promise and exception policy. Security defines access requirements, and operations owns recovery. Writing those responsibilities down is practical delivery work, not a committee exercise postponed until after the pilot.

Design recovery before allowing commitments

Suppose the OMS records the reservation but the response fails to reach the assistant. Repeating the entire operation may create another hold. Reporting failure immediately may persuade the customer to try again through a different channel. Neither response is safe without checking what the authoritative system recorded.

The reservation operation needs a stable request identifier and duplicate protection. After an uncertain result, the workflow should query the recorded status using that identifier. It can then return the existing reservation, retry a permitted incomplete step or escalate when it cannot establish the outcome.

Failures are not all equivalent. A temporary network problem may justify a bounded retry. An invalid store identifier needs correction. An expired approval needs renewed consent. An unavailable inventory source may require a human check. These outcomes should be explicit enough that the application can handle them without guessing from a generic error message.

Cross-system work also needs a clear completion boundary. If the reservation succeeds but a confirmation message fails, the stock hold still exists. Recovery should address the message and explain the state to the customer. It should not automatically release or duplicate stock simply to make the conversation look complete.

Assign an owner and a time limit to unresolved work. A durable exception record should show what happened, what remains uncertain and which action is permitted next. Test the handoff with the people who will actually receive it. A recovery procedure that nobody can use is another untested dependency.

A shared interface needs explicit trust boundaries

The MCP security guidance describes risks including confused-deputy attacks, unsafe token passthrough and compromised local servers. The existence of an open standard is not a security certification for a particular server. Evaluate the server, its dependencies and the privileges it receives.

An assistant may encounter customer notes, product descriptions or documents that contain instructions aimed at changing its behaviour. Those fields belong to the evidence being processed. They must not become a route for expanding tool permissions or approving a commercial action. The application should preserve that distinction even when the text appears inside a legitimate response.

Minimise the information returned for the task. Pickup eligibility usually does not require a complete customer profile, unrestricted transaction history or every internal inventory field. Smaller, purposeful responses can reduce unnecessary exposure and make business interpretation easier to evaluate.

Inspect credentials and downstream access independently from the model. A server should receive only the permissions its supported operations need. If a connector depends on a broadly privileged service account, document and address that exposure rather than relying on a prompt to keep the assistant well behaved.

Finally, make the deployment boundary visible. Establish where the host, server, model and logs run, which data crosses each boundary and how access can be revoked. A diagram of the actual request path is more useful than an assurance that the system is secure because one component supports MCP.

Portability is something to demonstrate

The protocol creates a common interface, but the surrounding application still chooses tools, presents approvals, manages context and handles failures. Two assistants can connect to the same service and produce different outcomes. That is why I would distinguish connection compatibility from behavioural equivalence.

Test the inventory capability through two intended clients using the same cases and permissions. Include ambiguous product names, unavailable stores, stale stock, expired reservations and requests outside the caller's authority. Inspect what each client does when it should ask for clarification or stop.

The objective is not identical wording. It is consistent business behaviour: no invented stock promise, no unauthorised reservation, no duplicate hold and an understandable explanation of uncertainty. A different model may need different instructions or validation even when the service contract is unchanged.

Measure the effort needed to introduce the second client. Separate reusable service work from new authentication configuration, evaluation, user experience and operating support. That evidence tells you whether the architecture actually reduced duplication. Counting connected clients alone does not.

Provider exit is broader still. Prompts, evaluation cases, execution state, identity configuration, logs and commercial contracts may remain dependent on a vendor. Record what can move, what must be rebuilt and what access fees remain. An open connection reduces one kind of friction; it does not make the entire operating environment portable.

Buy, build or combine according to the work

A packaged connector can be the sensible choice when it covers the required operations, applies the right permissions and comes with support the team needs. Evaluate it against the actual workflow and commercial terms. Owning more code is not an outcome in itself.

A specialist solution may be stronger for a bounded process where its workflow design, evaluation and operating support remove substantial work. Ask whether its integration and decision records can be reused elsewhere, but do not reject a useful solution solely because the implementation is not entirely under your control.

An internally operated service becomes more attractive when several channels need the same business capability, the rules matter to differentiation and the company can maintain the service. That requires capacity for changes, monitoring, incident response and evaluation. A successful prototype does not establish that capacity.

A hybrid approach is often worth testing. Retain the authoritative platform and its APIs, own a narrow business service where company-specific rules belong, and expose it through MCP where compatible assistants need access. Buy commodity hosting or monitoring where doing so removes work at an acceptable cost.

The executive question is which decisions justify ownership and which responsibilities the organisation can reliably carry. Platform charges, API limits and contractual restrictions may remain whichever orchestration layer is chosen. Confirm them before presenting custom development as a route to lower operating costs.

Measure the economics now

You do not need to wait several years to evaluate the case. Choose a bounded workflow, record how it works today and compare alternatives against the same acceptance criteria. Start with an agreed budget, representative cases and a business owner able to change the process.

For pickup eligibility, count correct answers that remain valid when checked, reservations actually recorded, customer promises that need correction and cases requiring staff intervention. Track completion time alongside quality. A fast answer that causes a failed store visit transfers work and cost to someone else.

Calculate cost per accepted outcome using all relevant operating costs divided by correctly completed eligible cases. Include model usage, platform and API charges, infrastructure, human review, rework and support. Keep initial implementation costs visible separately so that a cheap trial is not confused with an inexpensive service.

Then estimate costs at plausible volumes using observed task patterns and quoted commercial terms. Include uncertainty: the difficult-case mix can change, review effort may grow and shared infrastructure may need additional capacity. A cheaper model is an opportunity to retest quality and unit cost, not an automatic saving.

The reuse claim needs its own measure. Record the work required to connect and approve the second consumer compared with the first. If the business service stays intact while most effort moves to client configuration and evaluation, you have evidence of reuse. If business logic must be recreated, revisit the boundary.

A practical pilot that can produce a decision

For a team with accessible APIs and an accountable owner, I would propose a four-week initial evaluation. It is a planning example, not a guaranteed delivery duration. Access procurement, data remediation or security review can extend the work. Surface those dependencies before committing to a date.

In the first week, define one capability, its authoritative sources and the baseline. Agree what is excluded and what counts as a correct result. Record an initial set of normal and difficult cases, including expected refusals. Identify who can approve a commitment and who receives an unresolved exception.

In the second week, expose the read operation in a controlled environment and exercise it through the first client. Inspect structured outputs and compare answers with known business facts. Fix the meaning of ambiguous states before adding write access. A connector that works technically may still expose an unusable business contract.

In the third week, introduce a second compatible client and compare behaviour. Where justified and authorised, test a narrowly scoped reservation operation with confirmation, duplicate protection and recovery. Deliberately interrupt the response after commitment to establish whether the system can recover without another hold.

In the fourth week, review outcome quality, total effort, observed costs and integration reuse. Expand only when agreed requirements pass. Keep a read-only service if that is where value is proven. Redesign a weak capability boundary, choose the conventional integration or stop if the business case does not hold. A useful pilot must be allowed to produce any of those decisions.

The questions I would bring to the investment discussion

• What survives a change of assistant? Name the reusable service, its rules and the assets that remain useful. Separate that answer from the vendor's general interoperability claim.
• Who owns the business promise? Identify the person accountable for eligibility, freshness, exceptions and the effect of policy changes across consumers.
• What happens after an uncertain write? Require evidence that the team can establish the recorded outcome, prevent duplicates and route unresolved work.
• What is the second-client evidence? Demonstrate compatibility, acceptable behaviour and measured integration effort through another intended consumer.
• Which costs and dependencies remain? Include upstream licences, access charges, operating support and the work required to change providers.
• What result would stop expansion? Agree unacceptable errors and minimum outcome quality before the pilot becomes an organisational commitment.

These questions move the discussion from technical enthusiasm to an investment that can be defended. The answer may still be to buy a product. It may be to improve the underlying service before introducing an assistant. The architecture should make those choices visible instead of assuming that a new protocol requires a new programme.

My position is that MCP deserves attention because it offers a practical route to reuse across AI applications. Its value becomes real when the capability behind the connection is dependable and the organisation can show what effort has disappeared. I want the business capability we build today to survive the model we replace tomorrow.

MCP questions for enterprise leaders