How MCP and AI Agents Are Reshaping Software

There's a quiet frustration that lives inside every design team at a large organization. They spent months — sometimes years — building a design system: a comprehensive rulebook for how every button, font, spacing unit, and color should behave across every product. Then a developer who's new, or rushed, or just a little cavalier, builds something that looks like it belongs to a completely different company. The design system existed. It just wasn't followed.

AI agents are being pitched as the fix for that gap. The question worth sitting with is: why would an AI agent do any better?

In a recent IBM Technology video, Will Scott walks through how design systems, context engineering, and the Model Context Protocol (MCP) fit together — and his explanation gets at something genuinely interesting about how agentic AI (AI that can make decisions, pick tools, and get real work done autonomously) differs from a plain language model you prompt at a chat interface.

The LEGO analogy that actually works

Scott opens with the obvious question: what even is a design system? His answer is a LEGO analogy that I'm going to repeat here because it's unusually clean.

"A design system is like a LEGO set with instructions. The instructions are the design system and the set of rules that comprise the design system. The building blocks, the LEGO blocks, are actually the design system components, like the fonts, UI components, colors, and rules of spacing."

The finished LEGO build is your app or website. The point of the analogy isn't just that design systems have parts — it's that they have instructions. Rules. A defined way the parts are supposed to fit together. That distinction matters a lot when you get to the AI part.

Design systems exist specifically because software teams are large and distributed. Without a shared rulebook, you get visual and functional drift — the same product feeling different depending on which team built which screen. IBM has its own Carbon Design System; Google has Material Design; Apple has Human Interface Guidelines. These aren't just style guides. They encode decisions about accessibility, interaction patterns, and information hierarchy that took enormous effort to develop. Inconsistency isn't just aesthetically unpleasant; it erodes trust and usability.

Context engineering: what you tell the agent before it starts

Here's where Scott introduces the concept that makes the whole thing work differently than standard AI prompting.

"In its purest form, context engineering is the way we teach an AI agent what it needs to know before it starts working on something. It's a way to provide the AI with the information it needs to be successful."

Context engineering is distinct from prompt engineering — though the two are related. Prompt engineering is about crafting the right question. Context engineering is about loading the agent's environment with the right knowledge before it ever sees your question. Think of it as the difference between asking a contractor "can you build me a deck?" versus handing them the building code, your HOA restrictions, the approved materials list, and the site survey before the conversation even starts.

This framing matters because agentic AI — the kind that can autonomously decide how to accomplish a goal — is only as good as the information it's operating with. An agent that knows how to write HTML but doesn't know your company's design system will produce technically functional but brand-inconsistent output. It'll build you something. Just not the right something.

MCP: the delivery mechanism

So how do you actually get that context to the agent reliably? That's where Model Context Protocol enters. Scott describes MCP as "an industry standard way of sharing that information to an AI, formatted in such a way that the information is easily consumed by the AI."

MCP is an open protocol — originally developed by Anthropic and increasingly adopted across the industry — that standardizes how external tools, data sources, and knowledge bases connect to AI models. Think of it as a common connector format, like USB-C but for AI context. Instead of every tool having its own bespoke integration, MCP creates a shared interface.

In the design system scenario Scott describes, an MCP server can serve up the design system's actual rules and components to the AI agent in real time. The agent doesn't have to rely on whatever it might have absorbed during training — it queries the living, current version of the design system as it works.

"Without the use of MCP, it's like the AI agent is building the LEGO set from memorized instructions. MCP gives the actual instructions, so that the AI agent can check its work."

That distinction — memorized instructions versus actual instructions — is where I'd push back a little on the framing, not to disagree but to complicate it. A language model's training data can become outdated the moment the design system gets updated. If the MCP connection breaks or isn't configured, you're back to the agent hallucinating components that no longer exist or applying rules that were deprecated in the last release. The architecture Scott describes is more robust than a pure prompt-based approach, but it introduces its own dependency: the MCP server has to be current, correctly scoped, and available. None of that is automatic — and the security architecture around what agents can access via MCP is a genuinely open problem worth attention.

Who this actually unlocks software development for

The scenario Scott walks through is worth taking seriously on its own terms. Someone needs to build a website. The website has to follow the design system. The person doesn't know the design system deeply. With an MCP-connected agent, they describe what they need in plain language and the agent handles compliance with the design system's rules — because it's actively referencing them, not guessing.

This is a meaningful shift. Right now, working effectively within a large company's design system requires real expertise. You need to know which components exist, which are deprecated, which have accessibility requirements attached, which violate brand guidelines if used a certain way. That knowledge lives in documentation that's either hard to find, hard to parse, or six months out of date. The agent-plus-MCP model turns that expertise into something more broadly accessible — at least in theory.

The "at least in theory" is doing some work there. Real design systems are often messier than their documentation suggests. Components exist in multiple versions. There are undocumented exceptions and tribal knowledge that doesn't live anywhere an MCP server can reach. Whether AI agents can navigate that fuzziness without producing something technically compliant but practically wrong is a question that only deployment at scale will answer.

There's also the deeper question of where design judgment lives in this workflow. Design systems encode decisions, but they don't make all decisions. When the rules don't specify — when the agent is operating in the space between guidelines — what does it reach for? Its training data? The most common pattern it's seen? That's a reasonable fallback, but it's not the same as a designer who understands the brand's intent.

The infrastructure layer nobody talks about

What Scott is describing, underneath the specifics of design systems, is a broader infrastructure argument: that the future of AI-assisted software development isn't just smarter models, it's better context delivery. The model capability is increasingly table stakes. What differentiates a useful AI agent from an unreliable one is the quality of the information environment it operates in.

Context engineering as a discipline — systematically designing what knowledge agents have access to and when — is still early. Most of the public conversation about AI in software development focuses on the generation layer: can the AI write good code? Less attention goes to the scaffolding question: does the AI have accurate, current, complete information about the constraints it's supposed to work within?

That scaffolding question is where MCP and design systems converge into something more general than either. It's a question about how organizations translate their institutional knowledge into a form that agents can actually use. Design systems are one of the clearest examples of that knowledge being well-structured and well-documented — which is probably why they're the natural test case for this approach.

The harder problem, the one this framing gestures toward without resolving, is what happens when the institutional knowledge isn't well-structured. When the rules live in people's heads, in old Slack threads, in the unwritten agreements that hold a product together. You can't MCP your way past that.

But for teams that have invested in rigorous design systems? The case Scott makes is coherent: structure plus protocol plus agent equals something meaningfully more consistent than what came before. Whether that holds up in production is what the next few years of engineering will actually tell us.

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent.