Embedded AI or a central assistant? Stop choosing. You need both.

For a long time, I felt a constant tension between two ways of bringing AI into a business.

The first approach is to put AI directly inside the applications and websites people already use. The second is to expose those systems through the **Model Context Protocol (MCP)** so they can be reached from a central assistant such as ChatGPT or Claude.

Vendors tend to make this sound like a contest. One group says the future is embedded AI: intelligence should sit inside every application. Another says the future is a single assistant above the software stack: one conversation that replaces the need to visit individual systems.

Having built and used both approaches, I have reached a different conclusion. **This is a false choice. A capable business needs both.**

The two models solve different problems

**Embedded AI** places the intelligence in the operational system. It appears in the email client, CRM, analytics portal, document tool or line-of-business application where the work already happens.

**Central AI through MCP** puts the conversational and reasoning layer in a broader assistant, then gives that assistant controlled access to business applications and tools.

The difference is not simply where the chat box appears. It is where the task is being understood, coordinated and executed.

Why I was—and remain—a strong supporter of embedded AI

I have AI embedded inside our HCL Domino environment. That matters because Domino is not merely an email client for us. Email, CRM, documents, tasks and business processes already sit together inside the platform.

The embedded assistant can inspect the current working context, answer questions, draft a reply, update an opportunity, create a task and perform an end-to-end workflow without making the user leave the workspace.

That is a genuine solution, not a limited version of a central assistant. The person is already in the right place. The system already knows the relevant record, identity, permissions and available actions. There is no unnecessary context switch and no need to teach the user a completely new way of working.

The same principle applies to an analytics portal. If the user is examining a particular chart, customer or reporting period, the embedded AI can understand that screen and explain or act on what is already in front of them.

This is one of the central ideas behind an AI-embedded company: intelligence should become part of the workflow rather than another disconnected destination.

What changed when I exposed the same systems through MCP

I then added MCP access to Domino and other applications. At first, it appeared that I had created a second route to the same capabilities. ChatGPT could now ask Domino to search email, inspect CRM information, prepare documents or execute actions that the embedded assistant could already perform.

But that is not the important difference.

The important difference is that the central assistant can combine those internal capabilities with things that sit outside the application: broader reasoning, internet research, other connected systems and a longer cross-functional conversation.

A task can begin with public research, move into the CRM, inspect relevant correspondence, create a document, schedule a follow-up and prepare a management summary—without the user manually carrying context between tools.

The value of MCP is therefore not that it moves a Domino task into ChatGPT. The value is that it allows Domino to participate in a workflow that extends beyond Domino.

That is why connecting ChatGPT to company tools becomes strategically useful. It creates an orchestration layer above the individual systems without pretending those systems no longer matter.

Embedded AI: the practical advantages

• **Native context.** The AI can understand the record, page, email, document or process currently open.
• **Low-friction adoption.** People do not need to leave the application or change their normal working habits.
• **Familiar interface.** The assistant can appear alongside the controls, language and navigation users already understand.
• **Precise permissions.** Access can follow the application’s existing security model and current-user identity.
• **Application-specific actions.** The assistant can use tightly defined business functions rather than generic tool calls.
• **Operational automation.** The platform can trigger AI-supported work from events, schedules and business-process states.

The limitations of embedded AI

• It is often bounded by the application’s own data, tools and worldview.
• Each product team may duplicate prompts, orchestration, model integration and user-interface work.
• Every embedded interaction may create direct API usage and token cost.
• The conversation can become narrow when the user needs research or context outside the application.
• Model upgrades and advanced capabilities may need to be integrated separately into every product.

A central assistant through MCP: the practical advantages

• **One interface across systems.** The user can describe the outcome rather than navigate each application separately.
• **Compound workflows.** A single request can coordinate research, CRM, email, documents, calendars and specialist tools.
• **Broader reasoning.** The central model can analyse ambiguity, compare options and maintain a larger cross-system objective.
• **Reuse of a subscription workspace.** For human-driven work, the marginal business cost may be lower than funding every interaction through an embedded API.
• **Shared improvement.** As the central model and workspace capabilities improve, every connected system can benefit without rebuilding the entire front end.

The limitations of a central assistant

• Subscription products still have usage and plan limits; they are not literally free or unlimited.
• The experience depends on connector reliability, authentication and careful permission design.
• Multiple tool calls may introduce latency and more points of failure.
• A central assistant can become a bottleneck if every small task is forced through it.
• Users may resist leaving the application in which they naturally think and work.
• Poorly designed connectors can expose too much context or make actions less predictable than native workflows.

The cost question is more subtle than it first appears

Cost was one reason I initially reconsidered the balance between the two approaches.

When a user performs a human-led task through a subscription product such as ChatGPT, the business may see little or no incremental charge for that individual interaction beyond the subscription. By contrast, an embedded assistant normally calls a model API, so each prompt, response and tool-planning step contributes directly to usage cost.

That can make MCP through a central subscription workspace commercially attractive for interactive work. But the distinction must not be overstated. Subscription plans have limits, and the economics depend on the product, model and usage pattern.

More importantly, background work does not disappear. If an agent must monitor an inbox overnight, process a document when it arrives or run a workflow without a person present, the execution still belongs in the application or API layer and will normally carry a metered cost.

The commercial design should therefore follow the operating model: use the subscription interface where a person is actively directing valuable work, and use API-funded automation where the business needs reliable unattended execution.

A four-part decision framework

1. The work begins and ends in one application

Default to embedded AI. Keep the user in context and let the application’s native assistant handle the record, permissions and actions.

2. The work crosses systems or needs open-ended research

Use a central assistant through MCP. This is where one conversation, broader reasoning and cross-tool orchestration produce the largest gain.

3. The work is repetitive, unattended or event-driven

Run it inside the operational platform or API layer. A scheduled or event-triggered process should not depend on a person opening a central chat window.

4. The work is complex and high value

Combine the approaches. Let the central assistant interpret the goal, research, plan and coordinate. Let embedded agents and application services perform the domain-specific actions with their own controls.

The architecture I now recommend

I would design business AI as two complementary layers.

Layer 1: intelligent applications

Put AI where the work happens. Email, CRM, analytics, document systems and operational platforms should understand their own context and provide useful, controlled assistance. They should also be able to run reliable internal automations.

Layer 2: central orchestration

Provide a capable central assistant that can securely reach those applications through MCP. It should coordinate work, combine internal and external information and allow the user to pursue an outcome that does not fit neatly inside one product.

MCP does not make embedded AI obsolete. Embedded AI does not remove the need for orchestration. The two layers improve one another.

The embedded application gives the central assistant dependable specialist capabilities. The central assistant makes the embedded application useful in a much wider set of business problems.

Stop listening to vendors who insist there must be one winner

Technology vendors naturally frame the market around the architecture that favours their product. An application vendor will tell you intelligence belongs inside the application. An assistant vendor will tell you the assistant will become the operating system for all work.

Both claims contain part of the truth, but neither is a complete business architecture.

The right question is not **“Which approach wins?”** It is **“Where should the intelligence live for this task?”**

The most capable organisations will have smart applications and a smart conductor above them. They will let people work naturally inside the systems they know, while giving them a central place to reason and coordinate when the work crosses boundaries.

So stop choosing between embedded AI and a central assistant. **You need both.**

Build the operating model around the work

AI Build Group helps organisations identify where embedded AI, MCP connections and central assistants fit within a practical operating model. We can support ChatGPT Business rollout, company-tool connections and the redesign of repeatable workflows.

The aim is not to add more chat boxes. It is to place intelligence at the right layer, preserve accountability and make the whole business system more capable. The next step is often to select one real workflow and redesign it deliberately—an approach I describe in I Make Myself Redundant Every Week.