MCP Connects Tools, CDEvents Provides Meaning: Why Syntactic Message Passing Is Not Interoperability

Contributed by Dadisi Sanyika, Sol Duara | Originally posted on medium.com

If you have spent any time building or managing software delivery pipelines over the past year, you have likely witnessed an explosion in AI-driven automation. From IDE-integrated assistants generating pull requests to autonomous security scanners and deployment bots, the software development lifecycle (SDLC) is rapidly shifting from human-driven workflows to multi-agent engineering ecosystems.

To connect these intelligent agents to software tools, the industry has widely rallied around the Model Context Protocol (MCP) and similar agent communication interfaces. MCP has done wonders for point-to-point connectivity, allowing an AI agent to query a repository, trigger a build, or inspect a database using standardized request-response calls.

However, as engineering teams scale these AI agents across multi-vendor toolchains, a familiar architectural headache has re-emerged.

Agents are executing actions across specialized tools, but simply adding agents to the pipeline doesn’t solve the core communication problem. An AI agent acts as a hand on a trigger, not a source of tool-relationship understanding. A build agent might trigger a job in one system, a testing bot runs a suite in another, and a deployment agent attempts to promote an artifact in a third. While each individual tool accepts the trigger’s command, neither the agents nor the tools possess a holistic view of the system, leaving the overall pipeline without shared context, lineage, or semantic meaning.

We are repeating the integration mistakes of the past, replacing brittle custom scripts with point-to-point agent calls. To build resilient, autonomous software delivery systems, we must recognize a fundamental architectural truth: syntactic message passing is not true interoperability.

The Limits of Point-to-Point Agent Connectivity

In computer science and communication theory, there is a distinct difference between syntax and semantics.

• Syntax defines the structure and format of a message (e.g., “Here is a JSON payload formatted as an API request to trigger Job A”).
• Semantics defines the shared meaning and domain context of that message (e.g., “Artifact X has successfully passed security scan Y and satisfies the production release policy for Application Z”).

Comparing Software Architectures

Most agent connectivity protocols operate primarily at the syntactic layer. They function as standardized bridges that allow an AI agent to invoke a specific function or tool API. This is undeniably useful for local execution, but it leaves an architectural vacuum across the broader delivery pipeline.

When an AI agent uses an action protocol to trigger a build in a CI server, the target tool executes the request. But what happens next?

• How does the downstream security scanner know what was built and why it was triggered?
• How does an audit logging system trace the lineage of that deployment across heterogeneous environments without writing custom translation logic for every vendor?
• What happens when you swap out your CI engine or deployment controller for a different platform?

Without a shared semantic vocabulary, every tool interprets events through its own proprietary lens. The agent can talk to Tool A, and Tool A can talk to Tool B, but the system as a whole suffers from semantic drift. The data moves, but the meaning is lost in translation.

From Point-to-Point Messages to an Open Event Mesh

To achieve real interoperability across modern software delivery pipelines, systems cannot rely solely on point-to-point request-response calls. They require an open shared language that announces state changes across the entire SDLC in a standardized, vendor-neutral format.

That’s why the Continuous Delivery Foundation (CDF) community established CDEvents, an open-standard specification designed to provide a universal event vocabulary for software delivery.

Instead of wrapping proprietary tool APIs in individual point-to-point connectors, a CDEvents-native architecture establishes a common semantic model for the entire pipeline:

1. Universal Event Vocabulary: Standardized event definitions—such as change.created, build.finished, artifact.packaged, or service deployed—ensure that every tool and agent in the chain interprets pipeline state identically.
2. End-to-End Traceability: Contextual metadata and event lineage are built into the event schema itself, allowing engineering teams (and AI agents) to trace an artifact from initial commit all the way to production.
3. Vendor Neutrality: When tools communicate using an open event standard, you eliminate vendor lock-in. You can swap, upgrade, or add specialized tools and AI agents without re-plumbing your entire pipeline orchestration layer.

Bridging the Gap

Shared semantics become truly valuable when a platform team can use them to express how its software delivery process should behave. Every organization carries operational knowledge, its risk tiers, change windows, ownership boundaries, and compliance policies, that shapes how software moves to production. Yet much of this knowledge remains trapped in custom scripts, webhook handlers, wiki pages, or people’s heads. What’s needed is an execution layer that lets platform teams codify these local practices over the shared CDEvents vocabulary and execute them as work moves through the delivery lifecycle.

Instead of building individual integrations between tools, a platform team can declare its process once against meaningful events. When a security scan reports a high-severity finding on a regulated service, for example, the platform can create the appropriate system record, notify the owning team, and hold promotion until the required approval is logged. The rule exists as a single statement over the event model rather than a collection of vendor-specific connectors.

This allows platform teams to preserve their existing toolchain, express enterprise-specific practices alongside standard event definitions, and maintain context across handoffs. Because tools connect through a shared vocabulary rather than directly to one another, adding or replacing a tool no longer requires rebuilding the surrounding web of point-to-point integrations.

The same model closes an important contextual gap for AI assistants. MCP gives an agent the ability to act on a tool, but does not by itself provide the organization’s operational rules or constraints. When engineering practices are declared over a shared event model, the platform holds that meaning and those constraints, allowing agents to act within the platform’s defined practice rather than having to infer organizational context on their own.

Conduit is an early-stage, CDEvents-native orchestration and event layer designed to sit underneath the developer tools, CI/CD runners, and AI agents an organization already owns. It makes this declaration model executable across the existing toolchain without requiring teams to replace the systems they rely on. MCP gives agents the ability to interact with tools; CDEvents gives those interactions shared meaning; Conduit provides the orchestration layer that lets platform teams apply their engineering practices to that shared event model. The result is observable pipeline lineage, seamless tool interoperability, and auditability by construction.

Building the Future of Open Software Delivery

As agentic automation continues to reshape software engineering, the teams that thrive will not be those that lock themselves into a single vendor’s ecosystem, nor those that build fragile webs of custom agent scripts.

The future belongs to open, interoperable architectures built on shared standards.

By pairing action-oriented agent protocols with an evolving CDEvents-native event mesh like Conduit, platform engineering teams can build autonomous pipelines that are flexible, transparent, and built to scale.

Want to learn more about how open event standards are transforming software delivery orchestration? Explore the CDEvents Specification or reach out to the Conduit team in the #cdevents channel on the CDF Slack to see how we can bring vendor-neutral interoperability to your pipeline. We are in active development and welcome your feedback as we build the future of open software delivery.