Forem: David Golverdingen

Enterprise AI Without an Enterprise Budget

David Golverdingen — Tue, 26 May 2026 07:27:06 +0000

Most mid-market companies trying to ship AI are doing it the expensive way: build a custom chat UI, run on per-token API billing, freeze on a specific model version, hire a platform team. At Warmtebouw — a mid-sized engineering and installations firm, not a software company — we did the opposite. The result is the same business capability at a fraction of the cost, with every frontier model upgrade arriving for free on the day it ships.

This piece is about the architecture that made that reachable, and why it's reachable for small and mid-sized companies that have been told enterprise AI is out of their league.

The standard path is expensive

When a mid-market or smaller company decides to bring AI in, the path they're usually pointed toward looks the same: build a branded chat UI on the API, wire it to internal auth, manage prompts in-house, maybe add a RAG pipeline against company documents, optionally an orchestration framework for "agent workflows," and increasingly an observability platform to monitor it all. That path is real, and at sufficient scale it may be the right call. I haven't run this architecture at the scale of a large multinational with hundreds of heterogeneous systems and complex tenancy requirements, so I can't tell you whether the same posture holds there. My guess is that the MCP layer itself stretches further than the framework industry assumes (more servers, deeper hierarchies of tools, more careful schemas) rather than needing a different architecture entirely. But that's a hypothesis from one scale, not a report from another.

For a company with twenty important systems and a few hundred employees, the standard path doesn't pay back. It's expensive in three coupled ways, and pulling the three apart reveals a simpler architecture underneath.

The chat client. A branded chat UI is a frontend team, a design effort, conversation history infrastructure, attachment handling, multi-modal input support, an admin panel, model routing, prompt management. The vendor (Anthropic, OpenAI, Google) ships all of this as part of the subscription and continues to ship new affordances every quarter. Building it in-house means investing engineering hours into a commodity layer where the vendor has structural advantages no internal team can match.

The model. A custom chat UI almost always pins to a specific model version for stability. Six months later the frontier moves, and the pinned model is now a generation behind. Upgrading means re-validating every prompt and every tool, so most teams don't. Meanwhile every Claude Team subscriber got Opus 4.7 the morning it shipped, with zero engineering work.

The billing. API billing is per-token, which means the cost is a function of user behaviour that hasn't happened yet. In a workforce of 50-500 people, roughly 20% of users drive 80% of consumption once adoption stabilises. Published analyses of heavy usage put the API-vs-subscription cost ratio at 15-30x; for average users the multiple is smaller (3-10x), and for light users API can come out ahead. The relevant number isn't the average. It's the variance.

These three costs aren't independent. They flow from the same root decision: build our own chat UI, or use the vendor's. Building locks all three together. The standard path commits a smaller company to a build budget, a maintenance team, an aging model, and an unpredictable bill, all at once.

The simpler path

Use the vendor's chat client. Pay per seat. Connect your existing identity provider. Then put your engineering hours where the value compounds: in MCP servers that encode your domain.

This is the architecture in production. Employees use Claude through the standard client (web, desktop, mobile). The client authenticates against the corporate identity provider, same as every other corporate system. Through that client, employees have access to nine MCP servers covering the full operational chain. Each MCP tool is RBAC-gated against the same IdP roles that govern every other system. A field engineer sees their own time bookings; a controller sees aggregated financials; a guest user sees nothing.

What I didn't build: a chat UI. A model gateway. A prompt management platform. A vector database. A retrieval pipeline. An agent observability stack. An "AI platform" of any kind. None of those layers exist in the stack, because the subscription client provides everything above the MCP layer, and the IdP provides everything around it.

A concrete example. The most common AI project a mid-sized company is pitched is "RAG over our documents": chunk all the SharePoint or Google Drive content, embed it, build a vector store, wire it to a retrieval layer, host and maintain the whole pipeline. Even when that pipeline is cheap to build, it's a layer you have to keep alive. Re-index when documents change, re-tune when retrieval quality drops, re-permission when access rules shift, re-host when the embedding model is deprecated. Meanwhile, the Microsoft 365 and Google Workspace integrations that ship with Claude, ChatGPT, and Gemini are themselves MCP servers, published by the vendors, maintained by the vendors, with permissions inherited from the existing IdP and freshness handled upstream. The "document search" capability that makes a custom RAG pipeline sound necessary is already an MCP server you can turn on in your admin console. The choice isn't cheap vs. expensive. It's an extra layer you maintain vs. no extra layer at all. And once you stop blaming the data and start fixing the meaning layer, the case for a custom RAG pipeline gets thinner still.

That sharpens the architectural rule. MCP isn't a category that lives only inside your perimeter; it's the protocol the entire ecosystem speaks, and vendors are already publishing servers for the commodity layer: productivity suites, code hosts, ticketing systems, design tools. Your engineering investment goes into the MCP servers that only you can write: your ERP, your BIM data, your operational logs, your calculation history. The systems unique to your business that no vendor has, or will ever have, a connector for. Everything else, you consume. That's where the investment compounds, and where it doesn't.

The cost picture inverts. Claude Team is about €19/seat/month on the annual plan; ChatGPT Enterprise and Gemini for Workspace are in similar territory. The vendor eats the billing variance. Every seat gets the latest frontier model the day it ships. No frontend to maintain, no platform team to staff, no orchestration platform to buy.

What this opens up

The interesting part of this architecture, and the part that makes it reachable for small companies, is the shape of the MCP layer.

The domain layer is model-agnostic. MCP servers are typed interfaces with tool descriptions and schemas. The same servers work with Claude today, Gemini tomorrow, GPT next quarter. None of the domain logic is locked to a model vendor. The engineering investment is portable across the entire frontier-model market.

Identity lives at the tool boundary. RBAC is enforced inside the MCP server, against your existing IdP. A model that's been prompt-injected can only call tools the authenticated user is already authorised to call. The security model is the same one your company already runs for every other system. No AI-specific identity layer, no prompt firewall, no model gateway. The tool boundary is the trust boundary.

The engineering shape is small. An MCP server, in my experience, is one engineer working with one domain expert for a few weeks per domain. That's the whole staffing model. Nine production servers over three months, no platform team, no specialists. The people who own the underlying business systems can do most of the work themselves, with engineering support.

This is what makes the approach reachable. A small or mid-sized company doesn't need to hire an AI platform team to run this stack. The chat client is rented from a vendor at a price comparable to a productivity-suite seat. The MCP layer is built incrementally by the engineers and domain experts already on the payroll. There's no procurement cycle for an "AI platform," no consulting engagement to size the rollout, no infrastructure to provision.

What you rent, what you own

What you rent	What you own
The chat client (Claude, ChatGPT, Gemini, your choice)	The MCP servers that encode your domain
Conversation history, attachments, multi-modal UI	Tool descriptions, query strategies, business logic
Enterprise SSO, audit logs, retention policies	Identity-gated tool access through your existing IdP
Frontend updates, model upgrades, security patches	Domain knowledge written into schemas
The model itself, latest version on day one	The integration with ERP, BIM, fleet, energy, calc
Predictable per-seat billing	One engineer, one domain expert, per server

What you rent is the commodity layer: the stuff vendors compete on and ship continuously. What you own is the part no vendor can build for you, because no vendor knows what your data means.

The same pattern, one floor down

The reason this is reachable goes one layer deeper than the chat client. The same logic applies to the framework layer underneath: LangChain, LangGraph, CrewAI, RAG pipelines, vector DBs, agent observability stacks. Building on top of those is one shape of architecture; building MCP servers directly against a frontier model is the same architectural posture without the additional layer.

Each MCP spec release closes another category of problem that previously required a framework layer. Tool calling, resource management, prompts, sampling, elicitation, UI primitives via MCP Apps, and enterprise identity integration on the 2026 roadmap. Each one used to live in a framework above MCP, and each one is now in the protocol itself. The framework layer isn't being argued against; it's being absorbed. Companies building on top of frameworks today are building on top of a layer the protocol is in the process of swallowing.

Both layers reward the same answer: rent the surface, own the domain. Use the vendor's client. Use the vendor's identity integrations. Use the vendor's model upgrades. Skip the framework layer. Spend your engineering on the part that's actually yours: the MCP servers that turn your operational data into something an agent can reason about.

That's what "MCP is the platform" actually looks like in practice. Not a stack you build, a perimeter you draw. Inside the perimeter: your domain, your tools, your IdP, your data. Outside: the model, the client, the vendor. The line between them is MCP.

If you're starting

Subscribe to Claude Team, ChatGPT Enterprise, or Gemini for Workspace. Connect your existing identity provider. Then pick the one system whose data your colleagues most want to query in natural language, and write one MCP server against it. Ship that. Watch them use it. Build the next one. The practitioner's guide walks the full seven-step recipe.

That's the entire starting move. No vendor selection process for an AI platform. No headcount plan for a platform team. No procurement cycle for orchestration software. A subscription, an identity wire-up, and one MCP server is enough to be in production with real users by the end of a month.

Three months of that across a real business produces what I have now: nine production servers, no framework dependencies, no custom chat UI, no API bill, no platform team, and a company that gets every frontier model upgrade for free the day it ships.

This architecture isn't a clever workaround for the moment. It's an early version of what enterprise AI is going to look like once the protocol layer finishes absorbing the platform layer above it. The companies that build this way now are getting a head start on a stack that won't look unusual in two years. It will look obvious.

This piece is part of a series on shipping MCP to production in mid-market companies. The maturity ladder I see across MCP servers is in Six Levels of MCP Servers, and the architectural argument for why MCP replaces the rest of the AI platform stack is in MCP Is the AI Platform.

Originally published on davidgolverdingen.nl. I write about MCP architecture, agent design, and what it takes to ship AI to non-technical users in mid-market companies.

MCP Is the AI Platform

David Golverdingen — Tue, 26 May 2026 07:11:26 +0000

Most teams shipping AI to production are still building on a stack designed for 2023. Custom chat UIs. Orchestration frameworks. RAG pipelines. Vector databases. Agent observability layers. An AI platform team to keep it all running. At Warmtebouw we skipped all of it and shipped nine MCP servers in three months for non-technical business users across ERP, BIM, fleet, energy, and operational systems.

This is the case that MCP isn't a piece of your AI platform — it is your AI platform, and most of the layers above it are overhead you don't need at mid-market scale.

The model is the agent. The framework is overhead.

The framing "you need an agent framework" obscures a simpler truth: the model is the agent. It reads tool descriptions. It chooses which tool to call. It sequences the calls. It interprets the results. That's textbook agentic behaviour, built into every frontier model that speaks MCP.

What companies sell you on top of that is framework around the agent: orchestration logic, retrieval pipelines, prompt managers, observability layers. Each of those products is solving a real problem in some context. But in a mid-sized business with a knowable set of important data sources, those contexts mostly don't apply.

What I use	What I skip
A frontier model (Claude in my case; swap as needed)	LangChain + LangGraph + LangSmith stack
MCP servers (custom, well-typed)	Multi-agent orchestration (CrewAI, Microsoft Agent Framework, OpenAI Agents SDK)
Tool descriptions as the interface	Vector DBs, embedding pipelines, agentic-retrieval frameworks (LlamaIndex)
Domain knowledge written into schemas	Hand-curated knowledge graphs sitting next to the tool
Cross-source composition through tool design	Workflow orchestration platforms
Production telemetry as the feedback loop	Agent observability stacks (LangSmith, LangFuse, Arize Phoenix)

Each row on the right is a paid product category. Each row on the left is the model, the protocol, or work I did once and reuse.

What "build for MCP" looks like in practice

A well-designed MCP server doesn't ask the model to figure out what the data means. It tells the model what the data means in the tool description itself.

The contrast plays out at every level. A bad tool says: "query data from the ERP." A good tool says: "always start with summaryOnly=true. Active projects accumulate thousands of records. Type codes determine which fields are populated. Use get_budget for planned costs, this tool for actuals."

The first version forces the model to invent a query strategy on every call. The second hands the model a query strategy on every call. The difference between those two servers, in production, is whether business users actually use the result.

This is the work teams skip when they reach for frameworks. The complexity is mostly self-inflicted. It exists because nobody wrote down what the tools mean. The same gap is why 97% of MCP tool descriptions analysed in production contain at least one critical smell.

One server can compose many sources

The most common objection ("but you need orchestration to combine data from multiple systems") assumes orchestration has to live in a separate framework. It doesn't.

One of my MCP servers combines five heterogeneous sources behind one interface: a third-party meter-data aggregator, a public weather API, a government building registry, the company ERP, and an IoT building-automation platform. No agent dance. No retrieval pipeline. Just typed tools with descriptions explaining when each source applies and how they relate.

The model figures out the composition because the tool descriptions tell it the relationships. The pattern works across nine production servers covering ERP, BIM, fleet, calculations, building automation, energy, and operational logs. Effectively the entire operational surface of one business, addressable through tool descriptions, consumable by any MCP-speaking model.

Tools abstract everything below them

The model never sees how the data is fetched. Inside one MCP server, individual tools call whatever the underlying system speaks: REST for SaaS products, GraphQL for internal APIs, direct SQL against the data warehouse, JSON files on disk, SOAP envelopes for legacy systems. The tool returns typed records; the protocol heterogeneity stays inside the tool.

That's the abstraction layer the data-fabric and iPaaS industries charge premium prices to build. MCP tools already do it, one tool at a time, in whatever language the data actually lives in, with no central pipeline. The choice of backend doesn't propagate; pick whatever fits the underlying system, and the model interface stays identical.

Even SQL becomes tractable. Direct SQL from an LLM is dangerous because the model can be tricked into destructive queries. But SQL inside a typed MCP tool (where the server builds SQL from schema-validated parameters, the connection runs as a read-only role, and the corporate IdP gates who can call it) is just a regular function call. Any value that doesn't match the tool's JSON schema is rejected at the protocol boundary before the tool's code runs at all.

This isn't theoretical. One of my servers is 100% SQL behind a query endpoint, covering calculation data. Every tool translates a typed agent request into a SQL query: the model passes schema-validated parameters in, the server constructs and runs the query, typed records come back out. The model never sees SQL. The connection runs as a read-only role, and access is gated by the same IdP roles that govern every other system.

I built it in one day. The calculation expert who owns the underlying data validated it, and it already exposes every dataset that team needs. Once you've internalised the pattern, applying it to a new domain is a day's work, not a quarter's project.

Why mid-market is the sweet spot

This argument has bounds. At Fortune 500 scale (hundreds of heterogeneous systems, multi-tenant SaaS, mountains of unstructured documents) you might need retrieval pipelines and orchestration. The complexity is real because the scope is real.

But mid-sized businesses have something Fortune 500 doesn't: a knowable set of important data sources. Five to twenty key systems. A handful of domain experts who can sit with you for an afternoon and tell you what the data actually means. That's the entire prerequisite for a well-built MCP server.

If your company fits in one office building and has fewer than twenty important systems, you're who this is for. You almost certainly don't need most of what the AI industry is trying to sell you.

What "the platform" actually is

Notice what's missing from the table above: a platform. There's no "AI platform" in the stack. Just a frontier model, MCP servers, and the corporate identity layer the business already pays for. Swap the model (Claude today, Gemini tomorrow, GPT next quarter) and the rest of the stack stays identical.

That last piece is what turns nine MCP servers into something an enterprise can run. Not an AI-specific identity layer. The one the company already operates. In a Microsoft shop, that's Entra ID with RBAC. In other shops, Okta, Google Cloud Identity, or any OAuth 2.1 provider. MCP servers authenticate against the existing IdP, scope tool access by role, and log every call to the same audit trail every other corporate system already uses.

The implications:

A field engineer sees only their own time bookings and assigned projects.
A controller sees aggregated financials, not raw payroll.
A guest user sees nothing.

Every action is attributable to a named identity in the same audit log as every other system. That's the entire enterprise AI security model. No prompt-firewall vendor. No AI-specific governance platform. No model gateway. Just the access-control infrastructure the company already runs, enforced at the MCP-tool boundary. Even prompt injection becomes bounded. A tricked model can only call tools the authenticated user is already authorised to call.

Anthropic's 2026 MCP roadmap leads with enterprise authentication and identity-provider integration. The protocol is moving in this direction because the pattern works: tool-level RBAC against the corporate IdP turns "the AI security problem" into a solved authentication problem. Which it always was.

Wire MCP servers through enterprise identity and MCP isn't connected to the platform. MCP is the platform.

The work that matters

What the framework industry sells is scaffolding. What actually moves outcomes is the specific, domain-bound work of writing good tool descriptions: choosing the right granularity, documenting which tool fits which question, adding query strategies, capturing failure modes from production usage and feeding them back.

None of that can be outsourced to a vendor, because nobody outside your business knows what your data means. But all of it is reachable in a few weeks per domain, with one engineer and one domain expert. That's the trade you're being told doesn't exist.

The question that replaces "which framework should I pick?"

If you're starting MCP work today, the most useful question isn't "which framework do I need?" It's "what's the smallest useful tool I can write for the one person whose week would get better tomorrow if it worked?"

Build that. Watch them use it. Write down what they tried that didn't work. Update the tool description. Ship the next one.

Three months of that across a real business produces nine production servers and zero framework dependencies. That's the story: not that frameworks are bad, but that for most mid-sized companies, they're the wrong problem to be solving first.

The model is the agent. The IdP is the security boundary. MCP is the platform. Build for the platform, not around it.

This piece is part of a series on shipping MCP to production in mid-market companies. If you want the practical case for why this architecture is reachable for smaller companies, see Enterprise AI Without an Enterprise Budget. For the maturity ladder I see across MCP servers in production, see Six Levels of MCP Servers.

Originally published on davidgolverdingen.nl. I write about MCP architecture, agent design, and what it takes to ship AI to non-technical users in mid-market companies.

Six Levels of MCP Servers

David Golverdingen — Mon, 25 May 2026 20:25:32 +0000

Most MCP servers I see in production are stuck at Level 1 or 2. They wrap an API, expose some tools, and stop there. The result: an agent that can technically call your systems but doesn't actually understand your domain.

After shipping nine MCP servers across ERP, BIM, fleet, energy, and operational systems at a mid-sized engineering firm, a pattern emerged. There are six distinct levels of sophistication an MCP server can reach, and the gap between Level 2 (the default most teams ship) and Level 4 (where the agent actually understands your domain) is where most of the value lives.

Here's the ladder.

The Six Levels of MCP Servers

Most MCP servers do the same thing: wrap an API, expose tools with one-sentence descriptions, and hope the model figures out the rest. In a previous post I described why this fails for enterprise data. Here's the maturity ladder that emerged after building nine production servers with 52 tools across nine APIs.

Level 1: API Mapper (~70% of servers)

One tool per endpoint. One-sentence descriptions. No domain context. The model figures everything out alone from the tool name. Ask "which projects are running over budget?" and it will happily invent a filter, hit an empty endpoint, and tell you everything is fine.

Level 2: Functional (~20%)

Tools are grouped sensibly. Descriptions are longer. Someone thought about how a human would use this. Still no domain knowledge, no cross-tool references, no query strategies. This is the ceiling most commercial MCP implementations aim for today.

Level 3: Metadata-Rich (~8%)

Knowledge graphs, glossaries, data catalogs. The metadata is real, but it lives next to the tool rather than inside it, and it was typically curated by hand over weeks or months. In practice, manual curation doesn't scale, and the agent only reads it if it happens to call the right meta-tool. I built two of these layers (MCP Resources and a parameterless "guide" tool) and removed both after testing. No Claude client ever requested them unprompted.

Level 4: Self-Teaching (<2%)

The domain knowledge is in the tool description and the input/output schemas, the only channels the agent reads reliably on every call. And that knowledge wasn't written by humans scanning documentation; it was discovered by an AI examining real data, flagged with confidence levels, then validated by domain experts. I called the pattern Introspective Context Engineering.

The difference is not subtle. A Level 1 server says "query data from the ERP." A Level 4 server says "always start with summaryOnly=true, active projects accumulate thousands of records. Type codes determine which fields are populated. Use get_budget for planned costs, this tool for actuals. Report friction via report_problem." Not the same product. Not the same category.

Level 5: Interactive App (emerging)

The server doesn't just return data. It returns rendered UI. Interactive charts, sortable tables, clickable maps, typed forms, all drawn by the server and displayed inline in the conversation. The agent coordinates; the server controls presentation.

A table of 400 rows in a markdown code block is unreadable. A rendered, sortable, filterable table is a tool a business user can actually use. Level 5 is where the interface meets the user where they are.

Level 6: Secure Write App (frontier)

The server doesn't just read, it writes. Carefully. Two patterns: agent-initiated bounded writes for low-risk mutations (feedback, scores) through standard tools, and user-initiated secure writes for business-critical data through validated MCP App interactions. I call this the WriteIntent pattern: agent opens the door, user walks through it, server checks every step.

Almost nobody is here yet. Most builders are still nervous about giving MCP servers write access at all, and until Level 6 patterns exist, they should be.

The progression

Expose data (1) → organize tools (2) → understand the domain (3) → learn from data and feedback (4) → present through interactive apps (5) → act through secure writes (6).

Most of the public MCP ecosystem is stuck between 1 and 2. MCP isn't dead. Most MCP servers are empty. A different transport doesn't fix that; filling the tool interface with real domain knowledge does.

If you're building an MCP server today, the most useful question isn't "which framework should I pick?" It's "what level is mine, and what does Level N+1 look like?"

This piece was originally published on davidgolverdingen.nl. I write about MCP architecture, agent design, and what it takes to ship AI to non-technical users in mid-market companies. If you're hitting similar patterns, I'd love to hear from you.