Architecting for Agents: How We Rebuilt Our Stack for the AI Era

When we initially scoped the project to split our massive client-side monolith, the manual estimate was terrifying: 8 person-years of effort. In the world of enterprise software, that is often a polite way of saying the project will never actually finish. It is a death sentence for innovation. However, by architecting our own AI migration system, we compressed that roadmap into just 6 months. This success proved a fundamental thesis that now guides our entire R&D organization: to build truly "agentic" products for our customers, we first had to become managers of agents ourselves.

The industry is currently obsessed with AI wrappers—thin layers of chat interfaces sitting atop legacy systems. I believe this approach is a dead end. To survive the next decade of software development, engineering teams must stop treating AI as a feature and start treating it as a primary user of their architecture. This requires a complete overhaul of how we think about data structures, protocols, and the very nature of the developer experience.

AI is not a wrapper; it is an architectural overhaul

True AI integration requires more than slapping a chatbot on top of a legacy codebase. Most organizations are currently failing at AI implementation because they are trying to force non-deterministic models to navigate deterministic, tangled monoliths. When we faced our own monolith—a vast, distributed client-side architecture with overwhelming internal complexity—we realized that a human developer barely knew where to start, let alone a standard LLM.

To move from an 8-year timeline to a 6-month delivery, we built Morphex. Morphex was not just a prompt; it was a hybrid migration system that combined generative AI with deterministic orchestration and validation loops. This is the first pillar of our architectural philosophy: AI needs a framework to operate within.

Morphex worked by extracting logic, modernizing files, and then immediately subjecting that code to automated testing and validation. If the AI failed, the system caught it, provided the error context back to the model, and requested a fix. By the time a human developer saw the code, it had already passed through multiple layers of automated scrutiny. We did not just use AI to write code; we built a factory where AI was the worker and the architecture was the assembly line. If your architecture is too messy for an agent to navigate, it is too messy for your future growth.

Betting on the Model Context Protocol (MCP)

One of the biggest hurdles in the AI era is the fragmentation of data. Proprietary connectors create silos that agents struggle to bridge. We realized early on that if we wanted AI to be a reliable team member on the monday.com platform, it needed structured, secure access to data that did not rely on fragile, custom-built bridges for every single use case.

This is why we bet big on the Model Context Protocol (MCP). By adopting this open standard, we moved away from the "siloed connector" model. Our mondaycom/mcp repository serves as the connective tissue, allowing agents—whether they are Claude, custom internal bots, or third-party tools—to securely read board data and execute changes without the risk of context hallucination.

When agents speak the same language as the host system through a standardized protocol, reliability skyrockets. In our internal testing, agents using MCP were significantly more likely to execute complex multi-step tasks correctly because the "boundaries" of what they could and could not do were defined by the protocol, not just a vague system prompt. For engineers, this means less time spent debugging why an agent "forgot" a board ID and more time building high-value logic.

The shift to Prompt-to-App scaffolding

We are currently witnessing the end of boilerplate code. Historically, building a new feature or app on a platform like ours involved a significant amount of "setup tax." You had to jump into a developer center, configure versions, manually scaffold files, and manage deployments. This friction is where innovation goes to die.

By exposing the monday apps framework to AI coding agents via MCP, we have fundamentally changed how apps are built. We call this "Prompt-to-App" scaffolding. Developers now converse with the framework through their IDEs—using tools like Cursor or Copilot—to scaffold new apps, add board views, and manage deployments entirely through natural language.

This is not about replacing developers; it is about elevating them. When the "how" of building is handled by an agent that understands the underlying framework's constraints, the developer can focus entirely on the "what" and the "why." We have seen developers go from an idea to a functioning board view in minutes rather than hours, validating that the future of development is conversational rather than manual.

Beyond text: Moving to interactive UI resources

Perhaps the most visible shift in our architecture is the transition from text-based chat responses to what we call "MCP Apps." A chat interface that only provides text is just a more sophisticated search engine. A chat interface that provides tools is a workspace.

In our recent collaborations, including our work with Anthropic’s Claude, we have pushed the boundaries of what an agent can return to a user. If a user asks about project status, the agent should not respond with a paragraph of text explaining which tasks are stuck. Instead, our architecture allows the agent to return a native UI component—like the monday.com status battery widget—directly inside the conversation.

This is the concept of the "UI Resource." The agent does not just retrieve data; it retrieves a renderable, interactive component. The user can click on a segment of that battery widget, see the filtered table of "Stuck" items, and take action without ever switching tabs. This eliminates context-switching, which is the single greatest productivity killer in the modern enterprise. We are moving toward a world where the UI is dynamic and generated based on the specific needs of the moment, rather than being a static page a user must navigate.

Acknowledging the complexity: The Manager of Agents

I want to be clear: this transition is not easy. Adopting an agentic architecture requires a high degree of technical maturity. There are legitimate concerns regarding hallucination, data privacy, and the sheer complexity of managing non-deterministic outputs. Our "Moonshot" initiative was called that for a reason—it was a high-risk, high-reward endeavor that required our entire R&D team to rethink their roles.

Engineers must transition from being "code writers" to "managers of agents." This means your job is no longer just writing the function; it is writing the validation loops, the tests, and the protocol definitions that ensure an agent can write the function safely. It is a shift toward systems thinking at a much higher level of abstraction.

The implications for the industry

If we are right—and the success of Morphex suggests we are—the implications for the software industry are profound. Companies that continue to build monolithic, inaccessible stacks will find themselves unable to compete with the speed of AI-driven development. Those who embrace modularity, open protocols like MCP, and UI-as-a-resource will find their development cycles shrinking from years to months, and from months to days.

We are no longer building tools that people use; we are building environments where agents and humans collaborate. That requires a different kind of blueprint.

Don't just build for AI—build with it. I encourage every lead architect and CTO to look at their current stack and ask: "If an agent were to join my team tomorrow, could it actually get any work done?" If the answer is no, it is time to start rebuilding. You can start by exploring our open MCP repository on GitHub and seeing how we are standardizing agent reliability today. The era of the agent is here, and it’s time our architecture reflected that.