On April 26, 2026, MathWorks Consulting Services published a blog post walking through an AI-native MBSE workflow built on Claude Code, the MATLAB MCP server, and System Composer. The post is generous and well-written. It describes a five-step interaction loop the agent uses for every architectural change: propose, approve, generate, run, confirm. The AI drafts a plan in plain language. The engineer reviews and requests changes. The AI then writes a script that creates the actual model artifact. The script executes against System Composer. The output is shown back to the engineer for confirmation before anything else happens.
That five-step loop is, structurally, the same pattern Cairn was being built around at the same time — under a different name, in a different stack, against a different data model. We call it the ChangeSet review pattern: the AI proposes a structured set of operations, a validator checks them, a human accepts or rejects each one, and only the accepted operations are applied. Different vocabulary. Same shape. When two teams arrive at the same workflow shape from opposite directions, that is not a coincidence. That is the architecture announcing itself.
What the Last Six Months Have Made Visible
In the second half of 2025 and the first half of 2026, three independent moves established that AI-MBSE is no longer speculative. Every one of these signals is real, well-resourced, and pointing in the right direction. Read in sequence, they tell a story about where the category is going and why the architecture matters.
Read those four together. The vendors are different. The stacks are different. The customer profiles are different — CoLab sells into hardware companies that already have CAD design review processes, MathWorks sells into engineering organizations already on Simulink and System Composer, ThunderGraph sells into defense and aerospace programs adopting v2. None of them are direct competitors. But every one of them is building toward the same architectural pattern: an AI agent that proposes structured changes to engineering artifacts, with a human-in-the-loop review gate before anything becomes part of the model.
When Convergence Is the Validation
The cleanest way to see what is happening is to put two of these workflows side by side. On the left, the loop MathWorks describes for their Claude Code + System Composer integration. On the right, the loop Cairn has been running since launch. They were designed independently, by different people, against different data models. The shape is identical because the shape is what works.
ThunderGraph's BFS-based incremental graph construction is a slightly different shape — they build a single element at a time and verify by graph traversal — but it lands in the same place. CoLab's AutoReview annotates and surfaces, leaving the human as the authority on what gets changed. SysON's emerging AI features follow the same "AI proposes, human disposes" pattern. Every serious entrant in this category has converged on a propose/review/apply governance loop, because anything else creates an AI that silently mutates engineering artifacts — and no engineering organization will accept that.
Bolt-On vs Built-In
If everyone is converging on the same loop, why does the architecture matter? Because the loop is the visible part. What sits underneath it — the data model, the validator, the audit trail, the way undo and redo work, the way partial acceptance is handled — is where bolt-on and built-in start to feel different.
A bolt-on architecture starts with an existing tool that was designed for a single human user — System Composer, Cameo, an existing CAD review platform — and grafts the AI workflow onto it. The propose step works because the AI can be prompted. The review step works because the human can be shown a draft. The apply step works because the underlying tool already has APIs for changing the model. But the seams underneath show up the moment you stretch the workflow — when a ChangeSet has fifteen operations and the user wants to accept ten, when a partial acceptance leaves the model in a state the original tool was never designed to validate, when the audit log needs to capture not just what changed but who proposed what and why, when the undo needs to roll back across multiple specialists.
A built-in architecture starts from the assumption that AI is a first-class author. The data model is shaped by it. ChangeSets are not a UI overlay — they are the canonical representation of every change, regardless of whether a human or an AI proposed it. The validator runs before any ChangeSet reaches the user, not as a wrapper around the apply call. Partial acceptance is a property of the data model, not a feature retrofitted into the modal. Audit is automatic because it is the same shape as the applied change. When AI is a substrate decision rather than a feature decision, the seams that bolt-on architectures keep stumbling over simply do not exist.
None of this is a knock on the bolt-on architectures. They are doing real work and they are shipping real value. MathWorks, in particular, is doing something subtle and important — they are showing their existing System Composer customers what an agentic workflow looks like, in a stack those customers already trust. That is exactly how you bring a conservative engineering audience along. The hedge in the post — "nobody is going to design an entire system with agentic AI in one session" — is honest, and it reflects the constraints of the bolt-on path. When AI is a layer on top of a tool designed for a different era, the demos are real but the depth has natural limits.
Why Day-Zero Architecture Wins the Long Game
The AI-MBSE category will not be won by whoever has the best agent prompt. The agents are converging on the same shape, and the foundation models underneath are commoditizing every quarter. What will differentiate winners from also-rans is the foundation underneath the agent — the parts that determine whether the workflow holds together when a real engineer uses it on a real program for a real year.
That foundation is harder to retrofit than to design. The data model that treats AI proposals as first-class citizens. The validator that runs before, not after. The audit that is structural, not bolted on. The partial acceptance, the cross-specialist coordination, the unified history of human and AI changes. Every one of these is solvable in a bolt-on architecture, but solving them later costs more than designing for them earlier — and the engineers who feel the seams first will be exactly the practitioners the category most needs to win over.
The good news for the category is that the right pattern has been found. The good news for engineers is that they will get to choose between several real implementations of it over the next few years. The architecture question — bolt-on or built-in — will be the one that decides which of those implementations age well, which start to feel like the right tool for the next decade, and which feel like the right tool only for the demo.
Cairn is making one bet on that question. The convergent pattern says the bet was a good one to make.