Why we at Studio Vi are building modules, while everyone else is talking about AI agents

Why we at Studio Vi are building modules, while everyone else is talking about AI agents

AI is making more and more possible. But what is technically feasible is not necessarily what an organisation needs. That is why we at Studio Vi have chosen a modular approach to intelligence.

Look at the major AI platforms. In a relatively short period, Microsoft has expanded Copilot from an Office assistant into Copilot Studio and a range of agentic applications. OpenAI and Anthropic are rapidly releasing new models, agents and business subscriptions through ChatGPT and Claude, each bringing new capabilities and, frequently, new terms and pricing. Organisations building on these platforms must continually reassess their applications in response to decisions made by someone else.

This makes the question facing organisations more complicated than simply, “What can we do with AI today?” The real question is how to invest in intelligence without becoming dependent on technology that changes every quarter.

Agents and Modules

We are optimistic about AI agents and expect them to play an increasingly important role within the modules we build. There is no contradiction between the two approaches. The difference lies in where you begin.

You can start by asking what the latest technology is capable of. Or you can start with the organisation and design the intelligence it needs to operate more effectively. Since 2019, we have consistently chosen the latter. Sometimes that means embracing a new development. At other times, it means deliberately taking a different direction from the rest of the market.

We Have Seen This Before

When we started working with AI in 2019, chatbots were its most visible application. Organisations were deploying them extensively for customer service and internal enquiries. In practice, however, users quickly reached a dead end whenever a conversation deviated from the predefined questions and answers.

We chose conversational AI instead, approaching the challenge from a different perspective. We wanted to understand how to improve an interaction, rather than simply how many conversations could be automated. We have maintained that critical perspective on prevailing market trends ever since.

Today, we are seeing a similar pattern emerge with AI agents. In our conversations with organisations, we recognise two distinct responses.

The first group is experimenting extensively. Teams are building agents and automations, often with genuine success. But over time, they accumulate a collection of disconnected solutions, and nobody can clearly explain how those solutions collectively contribute to the company’s performance.

The second group is taking a more cautious approach. We encounter this frequently in construction and infrastructure. These organisations recognise the potential, but question which technologies will stand the test of time and whether an investment made today might become obsolete tomorrow. I understand that caution. In fact, it is simply common sense. The difficulty is that operational challenges remain unresolved in the meantime.

Ultimately, both groups need the same thing: a considered approach to making AI an integral part of their operations. For one, that means bringing coherence to what already exists. For the other, it means making a controlled start without taking on significant dependencies.

Being Able to Build Does Not Necessarily Mean Designing Well

Software development has become dramatically more accessible in a remarkably short period. With generative AI and coding agents, someone can now produce a working prototype in a matter of weeks, where previously it would have taken months and a substantial budget. Construction companies, too, are seeing employees develop their own applications using tools such as Copilot Studio, ChatGPT and Claude.

But a working prototype is not the same as a product that will still be operational, maintained and integrated with the rest of the organisation two years from now. Our ability to build software has increased enormously. Our ability to design it well has not advanced at the same pace.

Good design begins with understanding the challenge: the people involved, their working environment, the processes within which a solution must operate, and the implications of every decision for the wider organisation. This requires research, testing and validation in real-world conditions. That is how we work.

It also means asking a question that is far too often overlooked in AI initiatives: what does this organisation not need?

Not every challenge requires AI. Not every task needs to be performed autonomously. And not everything that is technically possible justifies the investment.

Why Modules?

This design philosophy led us to modules. It was a deliberate decision, rooted in the understanding that a business process involves far more than a collection of individual tasks.

Consider cost estimation at a construction company. An AI agent can analyse construction drawings and extract quantities. That is valuable. But the estimator must be able to verify the results, the figures must be transferred into the estimating software, and the information established during estimation must subsequently be available for project preparation, procurement and execution. Only when all of these elements are properly connected does the technology deliver meaningful value. And in an organisation managing dozens of projects simultaneously across multiple locations, this must work for every project, every single day. That is what a module does. A module is a clearly defined operational capability, such as interpreting drawings, processing project documentation or supporting cost estimation. A module may incorporate an AI agent, but it could equally rely on machine learning, conventional software or process logic. The process determines which technology we use. Around that technology, the module manages integrations, validation, human oversight and the flow of information into subsequent stages.

Large language models, such as those powering ChatGPT or Claude, are highly capable of interpreting text and drawings, but their outputs are not always entirely accurate. In cost estimation, where every quantity must be correct, that level of uncertainty is unacceptable. That is why we use language models only where interpretation is required, deterministic rules for calculations, and machine learning for recurring patterns. This makes a module more reliable, easier to verify and more predictable in terms of cost.

An agent can perform a task. A module makes intelligence an integral part of a business process.

From Standalone Applications to Intelligence Infrastructure

Designing in this way naturally raises another question: how do we enable different modules to use the same information and share context?

That is why we developed VIRON, Studio Vi’s Intelligence Infrastructure Platform. Within Viron, data, process logic, integrations and intelligence are organised into a coherent whole. Each module delivers value independently, while allowing an organisation to expand and connect capabilities incrementally.

A fundamental principle behind this approach is freedom of choice. Whether we are talking about the models behind ChatGPT, Claude or Copilot, the technology leading the market today may no longer be at the forefront in a few years’ time. VIRON has therefore been designed so that the underlying technology can be replaced without having to redesign the entire process. Achieving this requires deliberate architectural decisions from the outset. Simply building modular software is not enough. This is how organisations can invest in AI without becoming dependent on technology that is constantly evolving.

Start Small, Build for the Long Term

Studio Vi has grown through the solutions our clients have actually purchased, rather than promises about what technology might be capable of five years from now. Value must be created today.

That is why we begin with a specific operational challenge and implement an initial capability. We then examine how that capability can create value across the wider organisation and expand from there.

Because modules are reusable, not every implementation needs to start from scratch. This allows us to apply knowledge and technology with increasing efficiency. That scalability is a consequence of our design decisions. It is not the reason we make them.

The future of enterprise AI will not be determined by how many agents an organisation has, but by how effectively intelligence is integrated into its processes, systems and decision-making.

That is why we build modules.

Curious to see how this works in practice? Learn more about VIRON.