Product roadmap: what is next for vizualmodel.ai

Not and endpoint

vmblu is not an endpoint. As AI evolves, it has to evolve along. This is how we see the future.

Predicting the AI software-development market several years ahead is probably impossible. The capabilities that looked ambitious twelve months ago quickly become standard features. Coding agents improve, context windows increase, models become better at reasoning across repositories and software-development environments become increasingly agent-driven.

Any tool built for this market therefore has to start from one assumption:

the AI will get better.

Vizual Model is designed around that assumption.

Our objective is not to compensate permanently for limitations in today's coding agents. It is to build the architectural layer that remains useful as those limitations disappear.

From editor to architecture platform

vmblu began as a way to express software architecture explicitly and that remains the foundation.

A system can be decomposed into components, interfaces and connections and represented visually as well as structurally. But the value of that model extends considerably further: once architecture exists in machine-readable form, it can become context for coding agents, a navigation system for developers, an integration boundary for tools and a control layer for running applications.

The roadmap therefore moves vmblu from an architecture editor towards a broader architecture platform.

Better agent context

Coding agents currently spend a surprising amount of effort rediscovering the structure of software. They search files, inspect imports, trace calls and reconstruct relationships that the development team often already understands conceptually. A structured architecture should make much of that work unnecessary.

We want agents to be able to ask questions such as:

• What components are relevant to this change?
• What does this component own?
• Which interfaces may it use?
• What source files implement this node?
• Where is this message handled?
• What other parts of the system depend on this behaviour?

vmblu already contains many of the elements needed to answer these questions.

We expect this to evolve into something resembling an architecture-to-agent context compiler: selecting the architectural and implementation context an agent needs for a particular task without forcing it to rediscover the entire system every time.

Architecture that stays connected to code

A model becomes useless if it stops reflecting reality. Maintaining the relationship between architecture and implementation is therefore one of our most important areas of development. Some information naturally flows from architecture towards code.Other information can be derived from source code and linked back into the model.

Source locations, handlers, transmitted messages and interfaces can be inspected and associated with architectural components.

The objective is not to model every line of code, that would simply create another representation that needs to be maintained, the objective is to preserve the information that matters at architectural scale.

Multiple implementation paradigms

Message passing is central to the original vmblu runtime and remains especially useful for distributed, event-driven and agentic applications. It creates explicit boundaries between components and provides a natural point at which communication can be observed, controlled and secured. But not every software system should be built entirely around messages.

Conventional function calls, promises and direct service invocation remain excellent tools when synchronous execution and tightly coupled behaviour are appropriate.

We therefore see an opportunity for architecture to express different interaction semantics explicitly. The important point is not to force every application into a single programming paradigm. It is to make the paradigm visible. A direct call means something different architecturally from sending a message to an independent component. Developers should be able to see that distinction in the system design.

Architecture should clarify implementation, not obscure it.

Runtime control for agentic software

AI agents will increasingly interact directly with running applications. That creates enormous possibilities, but it also creates a new security problem. Giving an external agent unrestricted access to internal application functionality is rarely desirable. vmblu's communication model creates a natural control boundary.

Selected application capabilities can be exposed as explicit tools. Requests enter through known interfaces. Communication can be validated, observed, logged or restricted. The runtime therefore becomes more than an implementation mechanism, it becomes part of the application's governance model.

As agentic software grows, we believe this will become increasingly important.

Reference architectures and blueprints

Tools alone are not enough. One of the next major areas for Vizual Model is a growing library of architectures and examples, that we call Blueprints.

Some will demonstrate technical patterns: messaging, authentication, agent integration, real-time systems or multi-application architectures. Others will represent much larger domain designs.

The objective is to create reusable architectural knowledge rather than another collection of code snippets. Coding agents already know how to write most common implementation patterns. What they benefit from is higher-level structure, and Blueprints can provide that structure.

AI as an architecture partner

The longer-term direction is perhaps the most interesting. Today we primarily think of architecture as information that helps AI build software. There is no reason for the relationship to remain one-directional.

An AI architecture assistant should be able to inspect a system, understand its components and relationships and reason at the architectural level. It should be able to say:

• This component is acquiring too many responsibilities.
• These two subsystems are becoming unnecessarily coupled.
• This communication path creates a bottleneck.
• This capability belongs behind an interface.
• This architecture will make the proposed feature difficult to implement.

Eventually, AI may become as useful in architecture as coding agents have become in implementation. That is a direction we intend to explore.

What does not change

Specific models will change, agent frameworks will change, programming languages will change, development environments will change...

We are deliberately avoiding a roadmap that depends too heavily on any particular one of them. The underlying problem is more stable: large software systems need structure and developers need to understand that structure. AI agents need context and constraints, and applications need controlled boundaries through which humans, components and agents can interact.

That is the layer where we want Vizual Model to operate and vmblu is the starting point, not the endpoint. As coding becomes increasingly automated, we believe the centre of gravity of software engineering is design and our roadmap follows it.