Essential Reading for FDEs: Learn How to Transform Traditional Industries with AI Technology in One Article

1. Background

Many business owners in traditional industries think that upgrading their operations with AI is as simple as hiring an instructor for a few days of training. After those few days, however, all they know are the examples the instructor taught. What they did not understand before, they still do not understand. Why? Beyond the absence of an FDE, a bigger issue is that the enterprise’s internal FDEs face the following problems:

• Unclear understanding: Concepts such as Agent, Skill, MCP, CLI, and Model appear in rapid succession, without consistent definitions of engineering boundaries or invocation layers.

• Heavy legacy system burden: Heterogeneous systems such as OA, PLM, and MES, which have been running for years on outdated architectures, lack standardized modernization paths and entry points that balance security and stability.

This article systematically explains the layers of this technology stack, its invocation chains, and feasible engineering approaches for integrating legacy systems.

2. Architecture and Responsibilities of the Five Core Concepts

The overall system is not a standalone tool, but a layered, coordinated chain of control and execution:

Conceptual boundaries and core responsibilities

• Model (reasoning foundation): Essentially a stateless engine for computation and probabilistic inference, responsible for semantic interpretation, logical reasoning, and generation. A Model cannot directly observe or operate an enterprise’s internal network or databases.

• Agent (orchestration hub): A goal-driven autonomous control system that maintains conversation context and execution memory, using ReAct or planning-and-reflection loops to break down tasks, select tools, and integrate results.

• Skill (process asset): A domain-specific engineering asset and business SOP that includes trigger conditions, operating rules, parameter validation, and a controlled list of tools. It is equivalent to a standardized work instruction built into the system.

• MCP (standard interoperability protocol): The Model Context Protocol uses an open Client/Server specification to decouple Agent orchestration from external system interfaces, standardizing input/output formats and metadata definitions.

• CLI (execution tool): A command-line execution interface characterized by highly deterministic inputs and outputs that are easy to structure. It serves as a lightweight, direct execution channel at the Agent’s lowest layer.

A key engineering relationship: Nesting MCP and CLI

MCP and CLI are not mutually exclusive competitors. In practical implementations, MCP often acts as a protocol wrapper around a CLI. For example, operations scripts or underlying programs can be wrapped as an MCP Server: the CLI executes deterministic commands in an isolated environment and outputs structured JSON, while MCP exposes them as standard tool schemas.

3. The Complete Handoff Process for a Tool Invocation

Consider an employee submitting the following request through an interactive interface: “Help me check the approval status of last week’s leave requests and calculate my remaining annual leave.” The complete runtime flow across the modules is as follows:

• Goal reception: The user sends a natural-language request to the terminal;

• Intent decomposition: The Agent feeds the conversation context to the Model, which determines that the task requires attendance data but lacks real-time business data;

• Loading operating rules: The Agent retrieves and loads the “HR Attendance Skill,” reading the list of permitted tools and field constraints;

• Protocol invocation: The Agent constructs a JSON-RPC message using the MCP protocol and initiates a tool invocation against the corresponding MCP Server;

• Accessing the underlying system: The MCP Server converts the request into a REST API call to the underlying legacy system and injects authentication credentials;

• Returning and assembling results: The business system returns raw data, which the MCP Server filters, packages into a structured format, and returns to the Agent;

• Generating a response: The Agent combines the returned data with the original task objective and asks the Model to generate a natural-language response for the user.

4. Three Levels of Legacy System Modernization and Decision-Making

There is no universal template for adapting and modernizing legacy systems. Work must proceed in tiers based on the results of a technical assessment:

Modernization path selection and principles

• Path 1: API wrapping (preferred approach) applies to systems with complete or usable REST/SOAP/RPC interfaces. Deploy a lightweight MCP Server outside the original system to handle protocol conversion. The principle is to keep the wrapper layer stateless and strictly prohibit rewriting business logic within it.

• Path 2: CLI wrapping (second-choice approach) applies to systems without externally accessible network interfaces but with local SDKs, Shell scripts, or command-line tools. First convert their output to structured JSON, then connect execution through an MCP Server.

• Path 3: RPA fallback (transitional approach) applies only to closed systems that offer Web/desktop UIs without any interfaces. Use a headless browser or simulated UI interactions. This approach has high maintenance costs and is fragile when interfaces change, so it should serve only as a short-term transition.

Enterprise security and authentication mechanisms

• Credential forwarding (On-Behalf-Of): Systems that support OAuth 2.0 should forward the user’s Token to maintain the principle of least privilege.

• Service bot accounts + audit records: If the underlying system supports only static credentials, use a virtual service account to perform operations on users’ behalf, but MCP must rigorously record the initiator’s ID, original Prompt, and invocation chain.

• Human confirmation (Human-in-the-Loop): Establish hard stops for high-risk operations such as writes, approvals, and deletions, requiring an explicit confirmation interaction and strictly prohibiting fully autonomous Agent execution.

5. MCP Implementation Options and Technology Selection

Technology selection must clearly distinguish between transport mechanisms and architectural topology:

1. Transport protocol selection

• stdio (standard input/output): The Host process launches the MCP Server as a subprocess and communicates through standard pipes. Suitable for local desktop clients, such as Cursor and local analysis Agents, with a high degree of security isolation.

• Streamable HTTP (officially recommended remote approach): A single HTTP endpoint supports POST requests and GET streaming listeners, with native support for session persistence and state recovery. The preferred approach for centralized enterprise deployments shared across multiple systems, used with OAuth 2.0.

• HTTP + SSE (deprecated legacy approach): An early two-endpoint design. Existing projects may retain it, while new projects should migrate to Streamable HTTP.

• WebSocket (ecosystem extension approach): Suitable for full-duplex communication and browser extension bridging, but network load balancing and long-lived connection keepalives must be handled properly.

2. Architectural topology

• Point-to-Point direct connections: The Agent connects directly to each system’s MCP Server, suitable for lightweight testing scenarios.

• Unified gateway proxy (MCP Gateway / Proxy): A gateway sits between the core Agent and business systems, centrally handling access control, Token quotas, audit tracing, and service discovery.

6. Analysis of Typical Implementation Cases

Case 1: Integrating a vehicle manufacturer’s leave system (B/S architecture, Path 1)

• Current state: A Java Web system with internal REST APIs. Employees previously had to navigate multiple layers of webpages, and manual reconciliation at the end of each month was cumbersome;

• Solution: Keep the underlying business code unchanged, independently build an MCP Server microservice using Streamable HTTP, and integrate enterprise SSO;

• Results: Enable natural-language leave requests and leave balance queries, substantially shorten the operational flow, and fully preserve underlying data permissions and audit trails.

Case 2: Integrating a commercial vehicle manufacturer’s R&D PLM client (C/S architecture, Path 2)

• Current state: A closed Windows desktop client with no externally available HTTP interfaces, but with an SDK and scripting tools in its local installation directory. Engineers frequently had to manually compare BOMs and drawings across systems;

• Solution: Deploy an adapter service locally on engineers’ workstations, wrap SDK data extraction capabilities as structured CLI commands, and connect them to the Agent through a local stdio MCP Server;

• Results: Reuse the client’s existing login session and permissions, automate checks between drawing data and material status, and avoid high-risk modifications through direct database connections.

7. Implementation Steps

• Asset inventory and classification: Map systems into quadrants based on “invocation frequency” and “modernization difficulty,” prioritizing peripheral business processes that are frequently used, low risk, and have relatively complete interfaces.

• Protocol standardization first: Strictly follow the principle that the wrapper layer performs only schema mapping and data forwarding, reducing coupling.

• End-to-end auditing and security: Introduce end-to-end invocation chain monitoring when the first pilot system goes live, and enforce a second round of human authorization for operations that make changes.

Of course, this article is only an initial exploration of technical architecture and an explanation of various technical concepts and terms. We will discuss more topics step by step in future articles, taking our time to talk them through. Feel free to follow along.