The Future of AI Software Factories- OpenCLAW, Agent Orchestration & The Intelligence Age with Mark Smith [MVP]

What happens when AI stops being just a tool and becomes the team that designs, builds, tests, secures, documents, deploys, and even maintains your software?In this episode of the M365 FM Podcast, Mirko Peters speaks with Mark Smith [MVP], widely known as NZ365Guy, about the transition from traditional Microsoft development toward AI-first software engineering. Mark brings decades of experience across Microsoft technologies, Dynamics 365, Power Platform, Copilot, AI platforms, consulting, training, podcasting, and software development.The conversation goes far beyond Microsoft Copilot. Mark explains how he is building his own AI software factory with specialized autonomous agents, why he uses OpenCLAW as an AI harness, how multiple AI models can work together, why context engineering is becoming more important than basic prompt engineering, and what developers and IT professionals should learn to prepare for the Intelligence Age.FROM MICROSOFT TRAINING TO THE AI ERAMark's journey into the Microsoft ecosystem started around 30 years ago. What began with an interest in learning web design eventually led him into IT training, Microsoft infrastructure, networking, management, Dynamics CRM, Power Platform, Copilot, and AI.He recalls the early days of the web, when technologies such as HTML and CSS were still relatively new to many organizations and Microsoft NT4 was becoming increasingly important. Over seven years, Mark progressed from selling technical training to delivering courses himself and eventually becoming general manager of the company.That experience created the foundation for a career that would continuously evolve alongside Microsoft's technology stack.FROM DYNAMICS CRM TO POWER PLATFORM AND AIMark describes how his Microsoft journey moved from early Microsoft CRM into Dynamics 365 and later Power Platform. He was attracted to CRM not simply as a sales system, but as a platform that could be used to create many different kinds of business applications.Power Platform continued that evolution through low-code development. But Mark believes the next transition is significantly larger.AI is changing the interface between humans and software development itself. Instead of spending hours navigating configuration screens and traditional user interfaces, developers increasingly have the ability to communicate their desired outcomes through prompts, APIs, MCP interfaces, command-line tools, and AI agents.For Mark, this represents a fundamental shift away from traditional low-code development toward AI-first software creation.THE MOMENT GENERATIVE AI CHANGED EVERYTHINGMark began exploring AI years before ChatGPT, particularly around machine learning and Microsoft's Cognitive Services. However, the arrival of ChatGPT in November 2022 made the scale of the coming transformation much clearer.Another important moment came when he experimented with early Copilot capabilities inside Power Platform. During a Microsoft MVP session, he was able to prompt an application into existence while the technology was being demonstrated.That experience reinforced an idea that would increasingly shape his work: software creation was becoming conversational.WHY MARK EXPANDED BEYOND THE MICROSOFT AI ECOSYSTEMAlthough Mark has spent decades working with Microsoft technology, his current AI environment is deliberately multi-model.He discusses his experience with OpenAI, Anthropic, Microsoft models, Chinese AI models, European models, and other providers. Rather than designing systems around one vendor, he wants the ability to select the best model for a particular task.This approach reduces dependency on any single AI provider and allows the underlying models to change without rebuilding the entire system.The model becomes a replaceable component rather than the center of the architecture.TRUST, DATA SOVEREIGNTY AND MICROSOFT AIThe discussion also explores why Microsoft's ecosystem remains important for enterprise AI.For regulated organizations, the location where AI inference happens can matter significantly. Data sovereignty, compliance requirements, infrastructure location, and third-party model providers can all affect whether an AI architecture is acceptable.Mark explains that he is developing software where Microsoft's own models and infrastructure can provide an important trust advantage. Organizations that already trust Microsoft's cloud environment may prefer AI workloads that remain within that ecosystem.This becomes particularly important in countries and industries where data cannot easily leave a specific jurisdiction.WHAT IS AN AI SOFTWARE FACTORY?One of the central topics of the episode is Mark's concept of an AI software factory.Traditionally, software projects require multiple specialized roles: requirements analysts, architects, developers, engineering managers, testers, security specialists, documentation teams, and release managers.Mark asked a different question:What happens if each of those roles becomes an AI agent?His current environment contains a team of specialized agents that represent different responsibilities within a DevOps-style software lifecycle.Instead of one general-purpose AI trying to perform every task, each agent operates within defined boundaries and responsibilities.SPECIALIZED AI AGENTS IN THE DEVELOPMENT PROCESSMark describes several agents within his software factory.A requirements-focused agent gathers and structures requirements. An architecture agent researches and designs the technical solution. Development agents write code. Other agents handle verification, security, documentation, releases, maintenance, and orchestration.The agents are intentionally restricted.A developer agent, for example, should not simply declare that its own work is correct. Verification is performed separately. This introduces checks and balances similar to those found in mature human software engineering organizations.The result is an agentic development pipeline where work moves between specialized AI roles rather than relying on one large prompt.RESEARCH BEFORE ARCHITECTUREAnother important principle is forcing agents to research before making architectural decisions.Mark does not want his agents relying on potentially outdated assumptions. His architecture processes therefore include awareness of the current date and research into current approaches before technical decisions are made.The objective is to answer a specific question:If we were building this system from scratch today, what would the architecture look like?This is particularly important in AI, where models, APIs, frameworks, security recommendations, and development patterns can change extremely quickly.RALPH LOOPS AND AUTONOMOUS DEVELOPMENTAutonomy becomes much more powerful when agents are capable of continuing work instead of stopping whenever they encounter a problem.Mark discusses his use of Ralph Loops, where agents continue working toward a defined goal until the issue has been resolved.This allows development activity to continue overnight.An agent can write code, encounter a verification failure, receive feedback, correct the implementation, run through the process again, and continue progressing without requiring Mark to manually intervene at every step.However, safeguards are necessary. Mark also implements mechanisms that stop agents when they repeatedly fail, preventing uncontrolled loops from consuming infrastructure resources indefinitely.AN AI ENGINEERING MANAGERThe individual agents are coordinated through an orchestration layer.Mark describes Tara, his engineering manager agent, as the interface into the DevOps team. Tara coordinates the work between agents and ensures that tasks move through the appropriate stages.Rather than manually communicating with every development agent, Mark can interact with the orchestrator.This creates an architecture that resembles a real engineering organization: specialists perform defined tasks while an engineering manager coordinates the overall workflow.SELF-HEALING AND SELF-IMPROVING SOFTWARE SYSTEMSThe software factory does not only build software. Mark is also experimenting with systems that monitor and improve themselves.He describes Ruru, an observer that operates outside the primary OpenCLAW environment.Ruru monitors infrastructure health, API availability, resource consumption, and other operational signals. When an issue is detected and verified, it can create a ticket automatically.The development orchestration system then discovers that ticket and moves it through the development lifecycle.In some situations, this means a problem can occur overnight, be detected automatically, enter the engineering workflow, and potentially be resolved before Mark starts work the following morning.This leads toward an important AI engineering concept: recursive self-improvement.WHY MEMORY MATTERS FOR AUTONOMOUS AGENTSAgent autonomy is not simply about giving an AI permission to execute tasks.Memory becomes critical.Mark discusses the need to distinguish between short-term, medium-term, and long-term memory. Agents need enough persistent context to understand what was created months earlier and why particular decisions were made.Documentation therefore serves a different purpose in an AI software factory.The wiki is not only written for humans. It becomes institutional memory for the AI development organization.Agents can refer back to previous architectural decisions, implementations, and documentation when making future changes.Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.