Technology has a habit of making us believe that every new breakthrough renders everything that came before it obsolete.
When television became mainstream, many predicted the end of radio.
When e-commerce emerged, some predicted the end of physical retail.
When smartphones arrived, there were predictions that desktop computing would become irrelevant.
Reality is usually more nuanced.
Successful technologies rarely eliminate their predecessors. Instead, they change how and when those predecessors are used.
Today, we are witnessing a similar phenomenon with AI.
As natural language interfaces become increasingly capable, a growing number of people have begun to assume that traditional enterprise applications are destined for the same fate. If users can simply ask for information, request actions, and interact conversationally with enterprise systems, why would anyone need grids, dashboards, forms, charts, filters, multi-select operations, or Query-by-Example interfaces?
After all, can’t we simply ask for what we want?
The question is reasonable.
The conclusion is not.
Natural language interfaces represent one of the most important shifts in enterprise computing in decades. They lower barriers, simplify interactions, accelerate discovery, and allow users to express intent in a remarkably intuitive manner.
Yet they do not eliminate the need for visual experiences.
In fact, many operational workflows become more effective when both approaches coexist.
Expressing intent and consuming information are fundamentally different activities.
Natural language is often the most natural way to express intent:
- Show me delayed orders.
- Reserve inventory for customer ABC.
- Push this order to fulfillment.
- Identify orders that may miss their ship date.
However, once the information is returned, users frequently need to scan, compare, sort, filter, group, chart, analyze, and act upon large sets of data.
A transportation planner reviewing hundreds of shipments.
A warehouse supervisor monitoring fulfillment exceptions.
A customer service representative investigating order status across multiple systems.
These users are not simply asking questions.
They are operating.
And operational work often benefits from visual experiences.
On the left, a user interacts conversationally with an AI assistant to identify and act upon delayed orders. On the right, the same business capability is consumed through a traditional operational interface using Query-by-Example, grids, filtering, multi-select actions, and visual workflows.
Neither approach is inherently superior.
Both are consumers of the same underlying business capability.
The debate, therefore, should not be whether conversational interfaces replace screens.
The more interesting question is:
How can both consume the same enterprise capability without creating separate implementations?
That question takes us beyond interfaces and into architecture.
The Capability Is the Asset
In our previous articles, we discussed how enterprise capabilities can be represented as reusable intents and how those intents can be operationalized within governed enterprise environments. Our SmartForge solution brings all of these concepts together.
Once a capability exists as an intent, something important happens.
The capability becomes independent of the interface.
An agent can invoke it.
An API can invoke it.
A workflow can invoke it.
Another system can invoke it.
The capability itself becomes the durable asset.
Historically, however, every new consumer introduced new friction.
Making a capability available to an application required development.
Making the same capability available through an API required additional development.
Making it available through a chatbot often required another implementation.
Every new consumption model created another project.
Another backlog item.
Another maintenance burden.
One of the recurring themes throughout our work has been the elimination of this friction.
Our intent framework was designed around a simple principle:
Define a capability once. Consume it everywhere.
Once an intent has been operationalized, publishing it to AI becomes largely frictionless.
ForgeViu extends this same philosophy into visual experiences.
Visual Experiences Without Application Development
Traditionally, visual applications require development.
A screen must be designed.
Integrations must be written.
Service layers must be created.
Actions must be wired together.
Testing must be performed.
Deployment must occur.
The business requirement may be simple, but the delivery process rarely is.
ForgeViu challenges this assumption.
Once a capability exists as an operationalized intent, organizations should not have to build another application simply to consume it visually.
Instead, visual experiences are assembled through composition.
A grid can point to an intent.
A chart can point to an intent.
A detail panel can point to an intent.
Actions can point to intents.
The resulting experience emerges from existing capabilities rather than new development.
This distinction is subtle but important.
ForgeViu is not a screen builder.
ForgeViu is not a low-code platform.
ForgeViu is a capability publishing model for visual experiences.
Just as operationalized intents can be published to AI without writing new business logic, they can also be published into visual workspaces without traditional application development.
The intent remains unchanged.
Only the consumption model changes.
AI Is Not the Only Beneficiary
Although much of today’s discussion centers around AI, the underlying challenge is much broader.
Enterprise users have always needed frictionless access to operational capabilities.
Years before today’s excitement around agentic AI, we observed this challenge through Smart Viu in Blue Yonder WMS environments.
Smart Viu enabled organizations to create operational workspaces without traditional screen development. Users could define data access, actions, and operational views through configuration rather than application coding.
The lesson was not about AI.
The lesson was about friction.
Business users consistently wanted new operational experiences without waiting for another development project.
Today’s enterprise landscape presents the same challenge on a larger scale.
Many modern platforms expose APIs but provide limited mechanisms for rapidly transforming those APIs into usable operational experiences.
Organizations often possess abundant data and capabilities but lack efficient ways to consume them.
ForgeViu extends the same friction-reduction philosophy beyond a single platform.
Capabilities from SAP.
JD Edwards.
Blue Yonder.
Transportation systems.
Custom applications.
Enterprise services.
All become candidates for immediate visual consumption.
In this sense, ForgeViu is not merely an AI-era innovation.
It is a general-purpose capability publishing model.
AI becomes one consumer.
Visual experiences become another.
Both benefit from the same underlying capability layer.
A Supply Chain Example
Consider a common enterprise scenario.
An organization already possesses operationalized intents capable of:
- Retrieving orders from SAP or JD Edwards.
- Retrieving inventory from multiple warehouse management systems.
- Retrieving shipment information from transportation management systems.
- Reserving inventory.
- Pushing orders into fulfillment.
- Deleting or cancelling orders.
Traditionally, creating a unified operational workspace around these capabilities would require significant development effort.
A new application would likely be proposed.
Integration work would begin.
APIs would be connected.
User interfaces would be developed.
Testing cycles would follow.
ForgeViu changes that equation.
Orders originating from SAP or JD Edwards may be presented in a master grid.
When a user highlights an order, additional tabs automatically display inventory information from multiple warehouse management systems and transportation information from one or more transportation management systems.
Context-sensitive actions become available based on the selected order.
Reserve Inventory.
Push Order.
Delete Order.
Additional operational actions.
At first glance, this appears to be a sophisticated custom application.
Yet something important happened behind the scenes.
No new integrations were created.
No new APIs were developed.
No new intent definitions were required.
No new business logic was written.
Existing intents were simply mapped to visual constructs such as grids, tabs, charts, detail panels, and actions.
The entire application emerged through orchestration of capabilities that already existed.
This dramatically changes the economics of enterprise software delivery.
Historically, every new requirement resulted in another application.
ForgeViu enables entirely new operational experiences to emerge from capabilities organizations have already operationalized.
Capability-First Computing
The industry is currently debating whether the future belongs to agents or applications.
We believe both perspectives miss the larger opportunity.
The future belongs to capabilities.
A common enterprise capability layer sits at the center.
Above it exist multiple consumers:
- Conversational agents.
- ForgeViu visual experiences.
- APIs.
- Automations.
- Future consumers not yet imagined.
The interface becomes a choice.
The capability remains constant.
This is the architectural shift that matters.
The future is not agent-first.
The future is not screen-first.
The future is capability-first.
ForgeViu is what happens when visual experiences become first-class consumers of operationalized enterprise capabilities.
Once a capability has been defined, governed, and operationalized, organizations should be free to consume it through whatever experience best serves the user.
Sometimes that experience is conversational.
Sometimes it is visual.
Increasingly, it will be both.
