The Layer We've Been Missing

There is a quiet pattern in software that doesn't get talked about enough.

Every system we build has layers. Not in the abstract, "clean architecture" sense — in the very real, operational sense. There's the interface layer: dashboards, admin panels, forms, tables, buttons — the frontstage where users read and mutate data. Behind it sits the application logic: APIs, WebSockets, queues, background workers, the things that actually move data around and trigger business events. Go deeper and you hit the CLI layer — the backstage tools for aggregations, maintenance jobs, migrations, the logic that runs quietly "behind the curtain."

These three layers have coexisted for decades. They're well-understood. Frameworks, patterns like CQRS, infrastructure like message queues — all of it exists to organize and operate these layers reliably.

But there's always been a problem baked into this architecture.

The frontstage layer — the UI — was designed for the average use case. Forms cover the 80% of interactions that happen regularly. But the remaining 20% either doesn't exist in the UI, requires a developer to build a new screen, or forces the user to export data into Excel and figure it out manually.

That gap has always been there. We've just accepted it.

Enter MCP

MCP — Model Context Protocol — isn't new anymore. The hype cycle has moved on, which honestly makes this a better moment to write about it, because we can talk about what it actually does rather than what people projected onto it.

The short version: MCP is a protocol that lets a language model communicate with tools your system exposes. The model knows what tools are available, understands their parameters, and can reason about which ones to call and in what sequence — based on a natural language request from a user.

What that means architecturally: you have a new layer.

Not a replacement for the UI layer. Not a replacement for the API layer. An addition. A layer that sits alongside the existing ones and gives users a fundamentally different way to interact with a system they already have.

If you squint at the stack now, it looks like this:

That fourth layer is what this article is about.

The CFO report problem

A CFO needs a report from the internal ERP. Not a standard report — something specific: the last two and a half months, filtered to a particular set of counterparties, showing only transactions involving a specific material category, broken down by sales manager, with a trend line comparing each manager's performance over the period.

The system doesn't have this exact view. Nobody built it, because nobody predicted this specific combination of filters when the reporting module was designed.

Options today:

• Ask developers. They add it to the backlog. It gets scheduled in the next sprint. Three weeks later, it's live.
• Export everything to Excel and build it manually. Takes hours. Error-prone.
• The CFO doesn't get the report and makes the decision on gut feel instead.

None of these are good. Option 1 is the most honest — it's how most teams handle it — but it's a three-week tax on a question that might take a person with the right database access thirty minutes to answer.

Now wire MCP into this system.

You expose a set of query tools: classes that can run structured database queries, parameterized and sandboxed, returning typed data. You expose a charting service — an existing one, already in the codebase. You expose a PDF generation tool built on top of your existing HTML-to-PDF renderer. You expose an email dispatch tool.

The CFO opens the AI assistant in the ERP. Describes what they need in plain language. The language model reads the request, finds the right tools in the available set, calls them in sequence — query → chart → PDF — and returns a finished report. If the CFO wants it emailed, they say so and it gets emailed.

The developer didn't write a new feature. The system didn't change. The CFO got exactly what they needed.

That's not a demo. That's a production use case that's buildable today with tools that exist today.

What you're actually doing

The important thing to understand here is that MCP doesn't require you to "add AI" in some vague, hand-wavy sense.

You're not replacing your backend logic. You're not rewriting your services. You're taking logic that already exists — queries, business services, aggregation functions, reporting utilities — and making them callable by a language model through a controlled protocol.

The model doesn't have access to everything. It has access to the tools you've defined and exposed. That's the "permissible, controllable, traceable" part that often gets glossed over in MCP conversations, but shouldn't. You define the surface. The model works within it. Every tool call is logged. Every action is attributable.

This matters in systems where auditability is not optional — and most serious business systems, whether ERP, compliance platforms, or CRM, fall into that category.

Beyond internal systems

The ERP example is a closed system — users are internal, the risk surface is bounded, and the data is yours. But the same pattern applies outward.

Think about an e-commerce marketplace. The standard UI pattern is: filters, search box, category navigation. Users who know what they want find it. Users who don't know exactly what they want — or who have a requirement that doesn't map cleanly to your filter taxonomy — struggle.

Wire MCP to your product catalog services. A user asks: "I'm looking for something waterproof, compact enough for carry-on, and under €80 — I'm going hiking in Norway in June." That's not a filter query. It's a reasoning task. The model parses the intent, calls the right tools, and returns a curated selection with a rationale.

Same architecture. Different context. The system capabilities you've already built become addressable in a completely different way.

One more piece: Graph RAG

MCP handles the "do things" part of the AI layer. Graph RAG handles the "know things" part.

If you wire up a Graph RAG knowledge base alongside MCP — one that understands the relationships in your business data, your domain concepts, your organizational knowledge — the system stops being reactive and becomes something closer to an informed colleague.

Not a chatbot that retrieves documents. A system that understands that this invoice relates to that supplier, which has this contract, which has these payment terms, which affects that cash flow projection. The graph structure gives the model context that flat retrieval doesn't.

Together, MCP and Graph RAG turn an existing system into something that can reason about your business, take actions within it, and do so in plain language.

When to build this

The right moment isn't when you're starting from scratch. It's when you have a working system with solid internals — good service boundaries, tested business logic, reliable data — and the users are hitting the ceiling of what the UI lets them do.

That's when MCP adds value without adding risk. The system already works. You're adding a new surface, not rebuilding the foundation.

If you're designing a new system, though, it's worth including MCP in the architecture from day one. Not as the primary interface — forms and tables still do most of the work — but as a designed layer, with tool boundaries and permissions thought through from the start, rather than bolted on later.