Before the Web, productivity wasn’t the problem.
Connectivity was.
Tools such as Microsoft Access, Excel, report writers, executive information systems, and native applications gave users rich visual environments for working with data, information, and knowledge.
The catch?
Productive interaction was application-specific.
The application supplied the interface. It understood the document format. It determined what the user could do.
Meanwhile, another important transformation was underway.
Removing the Coupling, One Layer at a Time
ODBC (Open Database Connectivity) loosened the coupling between Windows applications and database management systems.
At OpenLink Software, we then developed UDBC — Universal Database Connectivity — taking the ODBC API cross-platform, without its Driver Manager and Administrator layers.
Ke Jin developed those missing layers.
The natural fusion of the two produced iODBC, completing a cross-platform ODBC environment that extended the programming model to Unix, Linux, macOS, and other operating systems.
Then Java attacked application-to-operating-system coupling with its famous proposition:
Write once, run anywhere.
JDBC brought database-independent connectivity into that portable application model.
The progression was clear:
ODBC → database independence
UDBC/iODBC → cross-platform database independence
Java/JDBC → cross-platform applications + database independence
Each removed another assumption about where applications or data had to live.
But one assumption remained.
The application still defined the experience.
CORBA to MCP: Same Problem, New Interaction Model
Applications didn’t merely need access to remote data. They needed loosely coupled access to capabilities across networked systems.
CORBA sought to address this through distributed objects:
Application → Object Interface → Distributed Capability
Model Context Protocol (MCP) addresses the same fundamental problem for AI applications and Agents, exposing capabilities as tools and resources:
Agent → Tool Interface → Distributed Capability
CORBA and MCP aren’t the same architecture, but they are aimed at the same problem:
How does software invoke capabilities in a loosely coupled manner?
CORBA approached it through distributed object interoperability.
MCP approaches it through Agent-accessible tools and resources.
The architectural requirement persists.
The interaction model changes.
And that’s the important difference: the capability was already becoming loosely coupled.
Now the experience can be loosely coupled too.
Then came the Web.
The Web Connected Everything. The GUI Remained the Gateway
HTTP, HTML, URIs, and hyperlinks delivered something extraordinary:
Web-scale connectivity.
Resources could be globally named and reached across networks using a generic protocol.
But the rich productivity of native applications didn’t simply come along for the ride.
There was no Web-native equivalent of Microsoft Access that simply added HTTP connectivity to the established native-app experience.
Instead, the browser became the gateway.
HTML supplied structure. CSS supplied presentation. JavaScript supplied behavior. Framework after framework emerged to recreate increasingly sophisticated application experiences inside the browser.
The results could be excellent.
But somebody still had to build them.
The dominant model remained:
Human → GUI → Application → Data + Actions
The Web had loosened connectivity dramatically.
Productive interaction remained application-specific.
AI Agents Change the Equation
Large Language Models (LLMs) add natural language to computing’s UI/UX stack.
AI Agents take the next step.
Given appropriate identity, authorization, context, skills, and tools, an Agent can act on a user’s intent.
That changes the interaction model:
Human → Agent → Data + Actions
Agents don’t merely retrieve information.
They do things.
MCP provides a standardized mechanism for connecting AI applications and Agents to the external tools, resources, and capabilities required to perform those actions.
The interaction model therefore becomes:
Human → Agent → Governed Data + Tools → Actions
Documents are data containers. They may be managed by filesystems, database management systems, or hybrid combinations of both.
Tools provide action-oriented capabilities.
The Agent needs to identify the resource, understand what it represents, determine its relationships, discover appropriate capabilities, and obtain authorized access to the data and actions required to complete the task.
That access can be governed by identity, attributes, context, and policy — including Attribute-Based Access Control (ABAC).
And when a GUI would be useful?
Generate one.
The GUI Moves from Gateway to Generated Artifact
This is the inversion.
The GUI hasn’t disappeared.
Its role has changed.
Instead of:
Human → GUI → Application → Data + Actions
we can have:
Human → Agent → Governed Data + Tools → Actions
And, when visual interaction helps:
Agent → Generated Experience
The GUI moves from gateway to generated artifact.
The data persists.
The capabilities persist.
The experience becomes disposable.
Northwind: One Database, Three Eras
Northwind makes this progression tangible.
In the Pre-Web era, Microsoft’s Northwind sample database shipped with products such as Access and SQL Server.
Access provided the rich native GUI. SQL Server data could be reached through ODBC. Excel could likewise connect using ODBC, including through Microsoft Query.
Pre-Web:
Northwind Data → Native Application → Productive GUI
Then came the Web.
Northwind didn’t suddenly acquire an HTML equivalent of its rich Access front end.
You could build one. But HTML, CSS, JavaScript, server-side software, and frameworks now stood between the data and the finished experience.
Web:
Northwind Data → Web Stack → Custom Web Application
The Web connected the data.
It did not automatically carry forward the native-app productivity experience.
Today, the equation changes again.
The NorthwindKG Reactive Dashboard is an artifact produced by an AI Agent.
The dashboard isn’t the starting point.
It’s an outcome.
Agent environments such as Muse, Claude, ChatGPT Work, and others can work with underlying data, invoke tools, and generate an experience appropriate to the task.
Agentic:
Northwind Data + Tools → Agent → Task-Specific Experience + Actions
That’s more than a faster way to build another application.
It changes what the application is.
This Is Where The Semantic Web Project Gets Interesting Again
AI Agents are ravenous for context.
To act effectively, an Agent benefits from knowing:
What is this entity?
What type of thing is it?
How does it relate to another entity?
What constraints apply?
Who may access it?
What capabilities are available?
What do these relationships and capabilities mean?
These are precisely the kinds of questions addressed by The Semantic Web Project.
HTTP provides connectivity.
URIs provide globally scoped names.
RDF provides machine-computable entity-relationship representation.
Linked Data makes those relationships discoverable and traversable.
Ontologies provide machine-computable context through shared semantics, classifications, relationships, and constraints.
MCP exposes tools and capabilities to the Agentic interaction layer.
The Web gave us an interconnected document network.
The Semantic Web Project supplied the ingredients for an interconnected entity-relationship graph.
AI Agents add the missing interaction layer:
Humans express intent.
Agents deal with the machinery.
Humans don’t need to write SPARQL, understand RDF, inspect database schemas, or study tool definitions before accomplishing a task.
The Agent can work with governed, machine-computable resources and tools on their behalf.
And when visual interaction helps, it can generate the experience.
Three Eras. One Journey
Pre-Web Era
Rich native-app productivity.
Application-specific interaction.
Progressively looser coupling to databases, operating systems, and distributed functionality.
Web Era
Web-scale connectivity.
Generally GUI-mediated interaction.
Native-app productivity rebuilt for the browser.
Agentic Era
Web-scale connectivity.
Governed data access.
Machine-computable context.
Discoverable tools and actions.
Experiences generated when useful.
The historical progression is really a story of progressive decoupling:
ODBC → database
UDBC/iODBC → operating system
Java/JDBC → application runtime + database
CORBA → distributed object interoperability
HTTP → Web-scale resources
MCP → Agent-accessible tools and actions
AI Agents → productive interaction from the predetermined GUI
And that brings the pieces together:
Native-app productivity.
Cross-platform data access.
Web-scale connectivity.
Machine-computable context.
Distributed action execution.
The NorthwindKG dashboard offers a glimpse of the result.
The Agent accesses the data.
Context supplies meaning.
Policy governs access.
Tools provide actions.
The task determines the experience.
That’s Semantic Web escape velocity.
AI Agents provide the interaction layer that can finally bind it all together.
Additional Information
- URIBurner Weblog providing a large collection of live AI Agent and Data Access Usage Demonstrations
- Live Reactive Northwind Sales Performance Dashboard Generated by Muse
- Semantic and Context Layers via Open Standards
- LLMs Obsolete the GUI Moat. They Don’t Obsolete Loosely Coupled Architecture Built on Open Standards
- The Agent Engineering Stack Nobody Shows You
- Large Language Models (LLMs) as Powerful Generic RDF Clients