When AI Agents with MCP create real value: 3 concrete scenarios

Every six months, a new technology promises to "transform manufacturing as we know it."

I lived through the Industrial Internet of Things wave in 2013, Industry 4.0 in 2016, digital twins in 2019, the industrial metaverse in 2022.

Do you know what all those projects had in common? All those approved budgets, announced with fanfare? All those consultants charging premium day rates to explain the future to you?

Most factories ended up exactly where they started. The same legacy control systems. The same shift supervisor filling in spreadsheets at six in the morning because "at least I have the data the way I need it."

So when someone tells me that "AI will transform manufacturing," I understand the scepticism.

I have the same reflex. I hear "AI on the factory floor" and my first instinct is: heard this one before.

But this time, something is different.

Not because AI has somehow become magically superior to the promises that came before it. But because a technical standard has arrived that solves the exact problem that caused every previous project to fail: integration with real operational data.

It is called the Model Context Protocol. And it is concrete enough to warrant your full attention.

The point is not AI itself.

It is that there is now a standardised way to connect a language model to your actual production systems: the control, manufacturing execution, and planning systems you already have, not the clean data lake you never got around to building.

The technology exists. The .NET libraries exist. The standard belongs to no one.

The problem is that most manufacturing companies do not know this yet.

And most .NET developers have not yet realised that this is the most concrete professional opportunity of the past several years.

If you are a .NET developer with even a passing familiarity with the industrial world, now is the time to read this to the end.

LLM integration with SCADA, MES and ERP: why AI is blind without real operational data

ChatGPT knows the world.

It knows what Overall Equipment Effectiveness is, understands best practices for predictive maintenance, and can explain the difference between a manufacturing execution system and an enterprise resource planning platform with textbook precision.

I spent half an hour testing it on manufacturing scenarios. It is impressive.

Then I asked it: "Why did production line 3 at my plant drop six per cent in efficiency last week?"

Answer: "I don't have access to your plant's data."

Exactly.

That is the problem, in a single sentence.

The data that actually matters is not in technical manuals or industry best-practice guides.

It lives in your internal systems.

In the control system that monitors process parameters. In the system that tracks every order and every batch. In the ERP that knows your real costs and your delivery delays.

And, let us be honest, in the spreadsheets the shift supervisor fills in every morning because "at least I have the data laid out the way I want it."

Without access to this data, AI is blind to your operational reality.

It can help you with generic procedures, documentation, theoretical explanations. But it cannot answer the question that matters: what is happening on line 2 right now?

I know of companies that spent tens of thousands of euros integrating language models with their own systems, back when no standard existed.

Do you know how that turned out?

Every system-and-model pair required a bespoke integration. Connect a control system to one model, build one integration. Connect a manufacturing execution system to another model, build another.

Then a new model version is released and everything needs rewriting. Maintenance costs spiral out of control, teams become dependent on specific consultants, and every time a vendor changes, you start from scratch.

I have seen talented developers waste months on exactly this kind of work. Not because they lacked skill, but because no standard yet existed to solve the problem at the root.

The Model Context Protocol arrived in November 2024 and solved exactly this.

It is an open standard that defines a universal interface for connecting any language model to any data source. The logic is that of the USB connector: before USB, every peripheral had its own proprietary plug.

After USB, one standard interface connects everything to everything.

Remember when printers came with a different cable for each manufacturer? That was the world of AI integrations, before this standard.

With this approach, you write a server that exposes your control system's data as tools accessible via a standard protocol. Any compatible AI agent, whether Claude, Microsoft Copilot, or a custom .NET agent, can use that data without knowing the specifics of your system.

You build the server once.

From that point on, any compatible AI tool can access your production data.

In industrial environments, where a control system installed today will still be running fifteen years from now, this is not merely an engineering nicety. It is the difference between a sustainable investment and a dead end.

If you want to understand whether your own systems are in this situation and how to connect them in a practical way, book a call now. We will assess the state of things together.

Why an AI agent does in seconds what the production manager does in hours

The word "agent" is overused.

Every software vendor today has an "AI agent" in their product. The vast majority of those I have encountered are glorified chatbots with more aggressive marketing.

The real distinction is simple. A chatbot answers questions. An agent executes tasks.

A chatbot takes text in, processes it, returns a response. Text in, text out. Even when sophisticated, it is fundamentally a transformation mechanism.

Useful, certainly. But limited.

An AI agent receives a goal, breaks it into steps, uses tools to gather information and act, verifies whether the goal has been reached, and corrects course if necessary.

It reasons and acts iteratively, much as a skilled colleague would if you had delegated an analysis to them.

Let us take a concrete example from a real manufacturing scenario.

The production manager asks: "Why has line 3's efficiency dropped below 75% this week?"

The agent does not answer immediately.

First it gathers context: it queries the manufacturing execution system for the week's data, analyses it, and identifies that efficiency has dropped 6% compared to the previous week.

That is not enough: the causes are still missing.

It queries the process control alarm management system and retrieves the logs from the past seven days. It finds four unplanned stoppages on line 3 due to temperature alarms. It cross-references this with maintenance data to verify whether the furnace air filter was due for replacement.

It then presents a complete diagnosis with the probable root cause and a proposed corrective action.

All of this in response to a single question. Without the manager needing to open three different systems, export data to a spreadsheet, and analyse it manually.

For manufacturers where production managers spend hours each day collecting data from disparate systems to prepare reports already out of date by the time they are printed, this changes the nature of the job in a meaningful way.

The fundamental point is this: it is not about replacing the operator. It is about giving them immediate access to relevant, already-processed information, instead of forcing them to collect and aggregate it by hand.

AI does not replace experience. It amplifies it.

A production manager with twenty years of experience working alongside an AI agent is far more effective.

Not because the AI is doing the work, but because it removes the mechanical activities and leaves room for the work where human judgement makes the real difference.

And this is precisely where the gap opens between those who watch and those who act.

MCP on the factory floor: why the three-tier architecture scales where custom integrations fail

Understanding how this approach works at a practical level matters.

Not to impress consultants in meetings. But because if you do not understand the components, you build systems that work in demos and break in production. I have seen it too many times.

The system has three components.

• The server is the component that exposes data and capabilities to agents. In a manufacturing context, you write a server that connects to your control system via industrial standard protocols, to the control and manufacturing execution systems via their interfaces, and to the ERP via its web services. The server exposes this data as "tools" that agents can call: named functions with descriptions and parameters. The agent reads the tool descriptions and autonomously decides which to call based on the goal it has been given.
  Descriptions are everything. Write precise, domain-specific descriptions grounded in manufacturing terminology and the agent will make correct choices. Write them vaguely and the agent will call the wrong tools in the wrong sequence. Some prototypes have failed for exactly this reason, not because of deep technical problems, but because whoever wrote the server had not understood that each tool description is the contract between the server and the agent. It sounds obvious, but it is one of the most common mistakes.
• The client is embedded in the AI agent. Claude has a native client. Microsoft Copilot supports it via connectors. A custom .NET agent uses the official SDK to implement the client.
• The host is the application that runs the agent. It can be a web app, a REST interface, a background service for automated monitoring, or a desktop app for line operators.

The architectural advantage becomes clear when you consider the reality of a typical plant.

A production control system, an order management and traceability system, an ERP for planning, perhaps a separate maintenance system, historical data in databases or files, and a handful of spreadsheets that no one has ever had the courage to replace.

This is the norm, not the exception.

With the traditional approach, connecting an AI agent to all these systems means writing and maintaining as many separate integrations as there are systems. Change the AI model, rewrite everything. Change a system, update the integration.

With this standard, each system exposes a standardised server. The agent talks to all of them through the same protocol. Change the model: the server does not change. Add a system: write a new server, the agent discovers it automatically.

There is one more aspect that often gets overlooked: this approach supports dynamic tool discovery. An agent can ask the server in real time which tools are available.

For developers building solutions to sell across multiple manufacturing clients, each with their own variant of legacy systems, this is not a technical detail: it is the difference between a scalable product and a bespoke project that dies after the first customer.

Building AI agents in .NET with MCP and Semantic Kernel (without breaking in production)

Let us get to the practical part.

What tools do you use in .NET to build an AI agent that communicates with industrial systems?

Microsoft.Extensions.AI is the library for abstracting language models in .NET. It defines a standard way to communicate with different AI services.

The real advantage is that you can switch provider without modifying your application's code, exactly as you already do with logging frameworks. This way, you avoid rewriting everything each time conditions or commercial arrangements change.

Semantic Kernel is Microsoft's framework for managing agent behaviour. It handles how the system makes decisions and acts: it decides which tools to use, executes them, and maintains the conversational context.

In practice it follows a straightforward loop: plan, execute, verify. And you do not need to build this from scratch.

Error handling, retries, and state management are already solved problems, so there is no point reinventing them.

At this point, the official SDK, available as an installable NuGet package, comes into play. It is what allows you to connect the agent to real systems using a standard communication protocol.

On the server side, you expose your system's capabilities by annotating certain methods in your code, and the framework handles the data exchange.

On the client side, the agent automatically discovers which capabilities are available and uses them when needed.

The server knows nothing about AI: it only knows how to expose data. The agent knows nothing about the details of your system: it only knows how to use the available tools.

This separation is clean. And it is exactly what you want in a system that needs to last for years.

How does it all fit together? The typical structure is three-tier:

• The server connects to industrial and business systems: machinery, production systems, databases.
  Its job is to expose certain capabilities as tools, with clear and descriptive names, such as "GetLineEfficiency" or "GetUnplannedStoppages".
• The Semantic Kernel orchestration layer: receives requests, manages the reasoning cycle, collects results. It can be a web service or a background service for monitoring.
• The user-facing interface: a web chat, a Microsoft Teams integration, or REST endpoints consumed by existing systems.

One critical aspect often ignored in prototypes but which will cause serious problems in production: error handling and timeout management.

Control systems can have variable latency. Industrial servers can be temporarily unreachable.

Management systems have maintenance windows. The server must handle these cases gracefully, returning structured errors that the agent can interpret and communicate to the user, instead of propagating raw exceptions.

If you do not handle this from the outset, you will find yourself debugging a production line stoppage at three in the morning.

It has happened. I can assure you it is not enjoyable.

And this is precisely where the difference between improvisation and method becomes apparent.

AI agents in manufacturing: three concrete use cases with immediate impact on production and costs

Enough theory.

Three concrete scenarios, with the practical considerations for each.

The morning briefing without opening three different systems

The shift manager starts their day by asking the agent: "Give me a briefing on the current situation."

The agent queries the production management system for open orders and delays, the control system for line status and active alarms, and the maintenance system for planned interventions during the day.

It returns a natural-language summary with the critical points requiring attention.

During the shift, the manager asks specific questions. The agent analyses data from the previous two shifts, identifies the main stoppages, cross-references alarm data, and responds with a diagnosis.

The real value is not in answering the obvious questions.

It is in eliminating the time the manager spends every morning opening different systems, exporting data, and comparing it manually.

One hour per day for a manager with a fully loaded employment cost of sixty thousand euros per year is worth approximately fifteen thousand euros annually in recovered productivity.

From this use case alone.

These are numbers worth bringing to a budget meeting.

Catching a problem before it becomes a line stoppage

This agent does not wait to be asked: it runs in the background, analysing control data periodically to detect anomalous patterns.

It does not simply replay alarms that already exist in the system. It does something more sophisticated: it analyses trends.

A temperature rising by 0.3 degrees every hour does not trigger an alarm today, but in eight hours it will exceed the critical threshold.

An agent that detects this trend can alert the maintenance technician in advance, allowing them to plan the intervention during the next available window rather than having to manage an unexpected stoppage at the worst possible moment, perhaps in the middle of the night, with overtime costs and a halted line directly affecting margins.

The notification the technician receives is not a generic alert. It reads something like this:

"Motor M-14 on line 3 is showing a temperature trend of 0.28 degrees per hour.

At the current rate, it will reach the alarm threshold in approximately seven hours.

This machine experienced a bearing failure fourteen months ago with a similar pattern. Check lubrication and bearing condition at the next scheduled stop at 14:00."

This is the difference between an alert and actionable information that points toward a potential remedy.

When production schedules itself (almost)

Production scheduling is a complex optimisation problem.

The planner must balance: customer priorities, material availability, machine capacity, changeover times, and delivery commitments.

Typically this is done by hand with spreadsheets and the substantial experience built up over the years.

This is the reality for thousands of small and mid-sized manufacturers worldwide.

An agent connected to the manufacturing execution system and the ERP can analyse the open order situation, actual line availability including planned maintenance stops, material stock levels, and propose an optimised sequence with an explanation of its reasoning.

The agent proposes, the planner reviews and approves.

Instead of starting from scratch every morning, the planner starts from a proposal already consistent with all known constraints, and applies their experience to adjust the edge cases that require human judgement.

This is the right place for AI: eliminating the mechanical work that consumes time without adding value.

Securing industrial systems with MCP: the architectural constraints that are non-negotiable

If you think industrial control system security is something to address in phase two, you already have one foot in a trap.

An industrial control system that behaves unexpectedly can cause physical damage, significant financial losses, and in the worst cases, risks to the safety of people.

This is not a remote possibility.

I know well what happens when interconnected systems are introduced into industrial environments without careful security design.

The fundamental and non-negotiable principle: no AI agent should ever be able to send direct control commands to programmable controllers or supervisory systems without the explicit oversight of a human operator.

This is not up for discussion.

It is an architectural constraint that must be built into the design from day one.

In practice, this means that read tools must be architecturally separate from write tools.

Read tools are used freely by the agent to gather data.

Write tools require an explicit approval workflow: the agent proposes the action, the operator approves it via a dedicated interface, and only after approval is the action executed.

A tool that reads valve states must never be able to change those states.

It sounds obvious.

But it stops being obvious when you are working quickly and cutting corners to meet a deadline.

There are other concrete risks to address:

• Prompt injection: a malicious or simply careless operator could modify data, embedding instructions for the AI agent, for example in a notes field of a production record or in a batch name.
  Tools must never pass raw data directly to the language model without first sanitising and validating it, as this could cause the model to behave unexpectedly.
• Decision latency: in environments where conditions change rapidly, an agent that takes thirty seconds to produce a response risks suggesting actions that are already obsolete.
  It is therefore necessary to define clearly, in the architecture, which decisions belong to the agent, such as diagnostic analysis or report generation, and which must remain with real-time control systems, such as automatic regulation loops and safety interlocks.
• Audit trail: every action proposed by the agent, every operator approval, every tool call must be logged with timestamp, user, and complete data.
  In regulated industries such as pharmaceuticals and food production, this is a regulatory requirement. In others, it is an indispensable practice for diagnosing problems and demonstrating compliance.
  If you do not build this in from day one, you will regret it.

These requirements are not obstacles to adoption. They are the foundation that makes adoption sustainable.

An organisation that implements this approach while respecting these principles builds something it can rely on for years.

One that ignores them creates vulnerabilities it will not see until it is too late.

From Copilot Studio to custom .NET code: how to choose the right path for AI in production

Not every manufacturing company has an in-house .NET development team capable of building an AI agent system from scratch.

For many small and mid-sized manufacturers, this is the norm, not the exception.

Microsoft Copilot Studio is the low-code platform for creating custom AI agents within the Microsoft 365 ecosystem.

Since 2025, this tool can connect directly, without additional components, to systems that expose data via a shared standard.

In practice it works like this: you have a .NET service that makes data from your control system available, such as production figures, machine states, or stoppages.

You connect it to the platform as if it were a data source, without having to build complex integrations.

You can then create an agent that uses that data without writing any orchestration code.

The agent already knows how to retrieve and use it in its responses.

The result is very concrete.

The plant manager can ask questions about production data directly inside Microsoft Teams, as if talking to a colleague.

No new application to build, and no need to train people on tools other than those they use every day.

The limitations are real and worth acknowledging: it handles structured conversational flows well, but has constraints around complex orchestration logic, multi-step reasoning, and integration with non-Microsoft systems.

Azure AI Foundry is Microsoft's platform for building custom AI agents using models hosted in Azure's cloud.

In plain terms, it lets you build intelligent applications that do not merely respond but can analyse a request, make decisions, and use data from different systems.

You can connect these agents to your data sources, define which operations they can perform, and specify how they should behave in various situations.

All while keeping control through code, without sacrificing the simplicity of a ready-made infrastructure.

Once created, agents are published as cloud services. This means they are accessible from other applications and scale automatically with load.

It is the most suitable option if you want development flexibility without the overhead of managing servers, security, and availability yourself.

It also offers guaranteed service levels and the option to keep data within specific geographic regions.

Copilot Studio makes sense if you are already in the Microsoft 365 ecosystem, want a first tangible result within two or three weeks, and the use case is primarily conversational.

Azure AI Foundry makes sense if you need models with enterprise support and regulatory compliance.

Custom .NET development using Semantic Kernel, a library that connects AI to your code and lets it use real functions and data, is the right choice when you have highly specific requirements: for instance, you need to connect to legacy systems with unusual interfaces, or you need full control over security and architecture.

In practice, many projects do not follow a single path but combine several solutions.

A typical approach looks like this: you use a .NET service to access the existing industrial systems. For the orchestration and logic layer, you rely on ready-made platforms such as Azure AI Foundry or Microsoft Copilot Studio.

Finally, you provide users with a simple interface, for example inside Microsoft Teams.

The principle is straightforward.

Write code only where necessary, that is, at the points where you need to integrate or control something critical. For everything else, use ready-made tools that save time and reduce complexity.

For a small manufacturer with a limited budget, this approach makes it possible to have a first working agent in four to six weeks, and then decide whether to invest in custom development based on the real results of the pilot, not on vendor promises.

ROI of AI agents in manufacturing: how to measure machine downtime and OEE before you invest

Decision-makers in manufacturing are pragmatic. They do not invest in visions of the future: they invest in demonstrable returns.

And rightly so.

The challenge with AI agents is that their value is often difficult to quantify in advance. You have to start by measuring the current problem, not by reading vendor marketing material.

How much time does the production manager spend every morning collecting overnight data and preparing the situation report?

In many mid-sized manufacturing facilities, this activity takes between forty-five and ninety minutes per day.

An AI agent that performs this collection automatically recovers that hour every single day.

For a line generating ten million euros of annual revenue across two shifts, the hourly cost of a stoppage runs to roughly four to six thousand euros in lost value alone, before any overtime costs for recovery.

A monitoring agent that detects anomalies early and reduces unplanned stoppages by 20% on a line with fifty unplanned downtime hours per year is worth forty to sixty thousand euros.

This is a measurable figure, comparable before and after implementation.

On the same line, each percentage point of OEE is worth approximately one hundred thousand euros.

An agent that optimises order scheduling by reducing unnecessary changeovers can reasonably contribute between half and one and a half percentage points of additional efficiency over twelve months. That is fifty to one hundred and fifty thousand euros.

How do you present this to management?

Three steps, none of which involve slides containing the words "digital transformation":

• Quantify the cost of the current problem, not the theoretical value of the solution.
• Propose a pilot project with measurable, specific objectives: not "implement AI on the factory floor" but "reduce the time needed to prepare the morning briefing from sixty minutes to ten".
• Size the pilot so that the return on investment is demonstrable even with partial results.
  The numbers must hold up in the conservative scenario as well.

If they only work in the optimistic scenario, you are not building a business case: you are doing internal marketing.

If you want to estimate the return in your specific situation, leave your details. We will schedule a call to calculate the impact on your business.

A 90-day AI pilot: the method for demonstrating real value without endless projects

Ninety days to demonstrate real value.

No endless projects that produce nothing but presentations. No experiments disconnected from operational reality.

What is needed is something concrete: an agent running in production, used by real people, answering real questions about company data.

The principle is simple: if measurable value does not emerge within 90 days, the project stops.

The first four weeks are for understanding what exists and building the technical foundations. The primary activity is a systems inventory: which systems exist, what data they expose, how to access them, and who is the technical owner of each.

This step seems straightforward. It is not.

Most projects stall around week six because nobody had noticed that the manufacturing execution system had a documented API from 2018 that nobody knew existed.

In parallel, you identify the three to five pilot users: the production manager, the shift supervisor most comfortable with digital tools, the maintenance manager.

Real interviews are conducted to understand the three questions they most frequently need to ask their systems, and for which finding the answer takes most of their time.

These become the use cases for the pilot.

Not the ones that seem most interesting technically, but the ones that solve the problem users feel most acutely.

From week five to week eight, you build the first agent.

Not the most sophisticated: the most useful.

Typically a question-and-answer assistant that responds to the three questions identified in the preceding weeks, using data from the server.

The interface must be as simple as possible: a web chat accessible from any browser, preferably integrated into Teams.

The objective is not to impress anyone with the technology. It is to get people to actually use the tool.

In the final four weeks, you measure the results and make a decision. The decision has three legitimate options:

• Extend the pilot if it has demonstrated value.
• Restructure it if the use case was not the right one.
• Stop it if the value cannot be demonstrated.

The third option must be stated from the outset as a genuine possibility.

Not every organisation is ready.

The reasons can include: data quality, IT team maturity, and cultural resistance to change.

Better to discover this after ninety days with a contained investment than after two years and a significant budget spent.

The market: high demand, missing skills

Manufacturing accounts for a substantial and strategically critical share of GDP in most developed economies.

Small and mid-sized manufacturers form the backbone of many industrial ecosystems: precision engineering, automotive components, pharmaceuticals, packaging, food production.

All of these companies have control systems, manufacturing execution systems, and enterprise resource planning platforms. All of them feel the competitive pressure from international markets.

Almost none of them have a team capable of building AI agents.

The professional profile that is needed is hybrid: someone who knows .NET, understands at least the principles of industrial systems, and can build AI applications with this stack.

In 2026, this profile is practically absent from the market. Whoever builds it in the next twelve months positions themselves in a market with high demand and nearly zero supply.

For years I have heard that "the .NET developer market is saturated."

This is the niche where it is not.

And it is a niche where companies pay for real solutions, not startups offering you equity you will never see.

The skills to acquire follow a logical sequence, so you avoid studying advanced topics without having the foundations in place.

You start with the tools for using artificial intelligence inside .NET applications, such as Semantic Kernel.

These form the most solid and well-documented foundation to build on.

The next step is learning to use the SDK that lets you connect AI to your systems via a shared standard.

In most cases, a couple of weeks is enough to start using it in a practical context.

At this point it makes sense to understand how industrial systems work. You do not need to become an automation engineer, but you need to know enough about them to read data from machines, production lines, and control systems.

Finally, you move to the cloud layer, using services such as Azure OpenAI Service and Azure AI Foundry.

These are the most realistic platforms to adopt for a small or mid-sized manufacturer.

The stack is mature enough to be reliable in production, but new enough that there is not yet a critical mass of specialised developers.

This window will not stay open indefinitely.

Manufacturing companies are beginning to ask the first questions about these topics.

Not in two years. Now.

Whoever arrives at these conversations already prepared, with a working prototype and the skills to build a pilot, will find fertile ground. The others will arrive when it has become "normal."

And therefore far less well paid.

You are not learning a new technology from zero. You are adding a high-value layer to skills you already have.

The gap between a generic .NET developer and one who can build AI agents for manufacturing is not years of study.

It is months of focused work.

And the market notices. Far more quickly than you might expect.

If you want to build these skills in a structured way, without wasting time between trial and error and scattered information, the AI Programming Course was built precisely for this: to take you from what you already know to what the market is beginning to pay for in earnest.

At this point, the question is no longer whether this opportunity exists.

The question is whether you want to be among those who capitalise on it, or among those who chase it when it is already too late.

Because the truth is simple, even if not comfortable: companies are not just looking for people who can write code.

They are looking for people who can solve real problems with new tools.

And that is precisely what makes the difference.