MCP Support Is a Checkbox. Agent Architecture Isn't.

Model Context Protocol is having a moment.

Over the past year, MCP has gone from Anthropic's open-source project to one of the most discussed standards in enterprise AI. Major ERP vendors, data platforms, and SaaS companies have all announced support. If you've been following the AI infrastructure space, you've watched the press releases stack up.

Here's the issue: "MCP support" is becoming the new "AI-powered." A checkbox that sounds like parity but obscures enormous differences in what agents can actually do once connected.

For anyone unfamiliar: MCP is an open protocol that creates a standard interface between AI agents and the systems they need to work with. It lets an agent interact with your ERP, your data platform, your SaaS tools, and your internal workflows through one consistent pattern instead of requiring custom integration for each. That's genuinely useful. It reduces integration friction and opens a path to agentic AI across finance, operations, procurement, and every other function that's been waiting for it.

But the protocol isn't the hard part. It never was.

A pattern with a track record

Every time enterprise software gets a new connectivity layer, the same story plays out.

ODBC gave applications a standard way to talk to databases. REST APIs gave software a standard way to connect services. iPaaS gave teams a way to wire systems together without custom code. In every case, the first wave was governed. IT set up the initial connections, controlled access, and maintained visibility. Then adoption outpaced governance. Teams started spinning up their own connections because the official process was too slow. Within 18 months, nobody had a complete picture of what was connected to what.

MCP's openness makes that cycle faster and easier to repeat. An agent that can discover and call tools across your enterprise is powerful. Dozens of ungoverned agents calling hundreds of unmanaged tools is Shadow ERP™ with a new protocol underneath it.

The question isn't whether to adopt MCP. It's whether you're building a governed agent strategy or the next generation of workarounds.

Connection is the easy part

Most MCP implementations in the market today share three limitations that rarely make it into the launch announcements.

They're one-directional. External AI tools reach into your business systems. That's useful for a narrow set of tasks, but it only covers half the problem. What about your platform's own agents reaching into your other systems? When an ops leader asks a question that requires data from outside the platform, a one-way MCP connection hits a dead end. The user has to leave, track down the data somewhere else, and come back. That's a workaround dressed up as a feature.

They rely on predefined tools. An MCP server exposes a fixed set of operations: fetch a record, run a report, check a status. The agent strings those operations together to answer questions. This works well in demos. It stalls in production, because every question nobody anticipated becomes a development request. The agent's capability is permanently capped at what someone thought to build ahead of time. In enterprise data models where the questions are unpredictable, that ceiling arrives fast.

They stop at access. Connecting an agent to your systems is one thing. Knowing what it did afterward is another. Permissions define what an agent can do. Traceability shows what it actually did: who it acted on behalf of, which data it touched, which records it changed, and which workflows it triggered. When agents are creating records and posting transactions, "we have logging" isn't a governance strategy. It's the bare minimum.

How we built it

We didn't adopt MCP as a feature announcement. We built our agent architecture around it because the protocol solves a real infrastructure problem, and we think most of the market is underselling what it can do when you commit to it fully.

Three decisions define our approach.

Bidirectional by design. Nextworld supports bidirectional MCP connectivity. External AI tools like Claude or ChatGPT can securely query your Nextworld data. And Ed, the platform's built-in AI assistant, can reach into your other systems to answer questions about data that lives outside Nextworld without the user leaving the conversation. That means an external analyst can ask questions about procurement data in Nextworld and get accurate, governed answers. And an ops manager working inside Nextworld can ask Ed about inventory levels in a warehouse management system or shipment statuses in a TMS without switching tools. Both directions governed by the same security and access controls that apply to everything else on the platform.

Dynamic agents over static tools. Our engineering team encountered what they call the "tool-call ceiling": the point where a growing catalog of predefined MCP tools stops scaling because the agent can't handle anything beyond what was anticipated in advance. Their response was to drop down a level of abstraction. Nextworld agents now compose their own logic at runtime, writing and executing code in a secure sandbox to answer questions nobody saw coming. Data processing stays server-side. Intermediate results never enter the model's context window, which means the agent computes answers instead of estimating them. We call this Dynamic Agents, and our engineering team has published detailed write-ups on how Code Mode breaks the tool-call ceiling and how progressive metadata disclosure supports it at scale.

Security as inheritance. Every agent on Nextworld inherits the platform's full security model. All actions execute as the authenticated user, with the same role-based access controls, field-level permissions, and audit logging that govern every other operation. Agents never exceed the permissions of the user they act on behalf of. Every step of every agent flow is traceable end to end. There's no separate security layer to build, because MCP runs on the same governed foundation as the rest of the platform.

Ask better questions

MCP will reshape how AI agents interact with enterprise systems. That's a given. What remains open is whether companies treat it as an architecture decision or a marketing milestone.

The vendors announcing "MCP support" today aren't all building the same thing. Some are exposing read-only access for developer tooling. Others are building governed, bidirectional runtimes where agents do real work across systems. The gap between those two is the difference between a checkbox and a strategy.

If your team is evaluating how AI agents will connect to your business systems, go deeper than "do you support MCP?" Ask whether agents can move in both directions. Ask what happens when a user asks a question nobody anticipated. Ask who's accountable when an agent takes action. And ask whether the answers hold up at the scale your operations actually run at.

‍