OPAL
Where Agents, Skills, and Tools get built — loosely coupled all the way down.
OPAL is where you build the agent harness — Agents, Skills, and Tools — and the context, comprising memory, that informs every Skill it runs. A Tool exposes a Virtuoso SQL Stored Procedure or an OpenAPI-compliant Webservice as an MCP-accessible interface, loosely coupled to a Skill above it and to a Data Space below — a database, knowledge base, filesystem, or API. Change what's underneath, and the Agent built on top doesn't need to know.
Agents · Skills · Tools · Context & Memory · Data Spaces · MCP · A2A
What the animation shows
- Four separate, replaceable layers. Agents, skills, tools and data spaces: nothing is wired to anything else. They meet at the harness, through open interfaces.
- Agent to harness. The request is routed to a matching skill. Skills package the know-how, so the agent never hard-codes it.
- Skill to tool. The skill calls a tool through an open interface: MCP, OpenAPI, GraphQL, whatever the tool exposes.
- Tool to data space. A live query against the source, in place: SPARQL, SQL or GraphQL over RDF, relational and file data.
- Results return along the same path. Each hop is a link or an API call: no shared code, no copies.
- Swap the agent. Skills, tools and data spaces stay as they are. Coupling is by contract, not by implementation.
- Swap any layer the same way. Agents, skills, tools and data spaces: loosely coupled by design.
Loosely coupled, top to bottom. Agents, Skills, and Tools are all created and deployed in OPAL. An Agent calls a Skill; a Skill calls a Tool; a Tool — an MCP-accessible interface OPAL exposes over a Virtuoso SQL Stored Procedure or an OpenAPI-compliant Webservice — reaches a Data Space beneath it: a database, knowledge base, filesystem, or API. Each link can be discovered and replaced independently, so a change at one layer doesn't ripple through the rest.
Every agent framework wants its own tool definitions, hard-wired to whichever database happened to be behind them at build time. The result, eighteen months into most enterprise AI programs, is a pile of one-off integrations that break the moment a schema changes or a system gets replaced — because the Agent, the Tool, and the Data Space were never separate things to begin with. OPAL exists to keep them separate: Agents, Skills, and Tools you build once in OPAL — Tools that expose Virtuoso SQL Stored Procedures and OpenAPI-compliant Webservices as MCP-accessible interfaces — sitting above Data Spaces that can change underneath without anyone rewriting a prompt.
Three layers, each loosely coupled to the one beneath it#
Nothing about your systems changes. OPAL is where Agents, Skills, and Tools get created and deployed, and where Tools stay loosely coupled to the Data Spaces they depend on.
- Agents, Skills, and Tools, created and deployed in OPAL. This is where the work of building an agent actually happens — including the Tools it calls — not a prompt pasted into a chat window.
- Skills run on context, not guesswork. Every Skill call carries context — including memory of prior calls and their outcomes — so an agent doesn't start blind on each invocation.
- Skills are loosely coupled to Tools. A Skill calls a Tool by contract, not by hard-wired implementation — the Tool behind it can change without the Skill being rewritten.
- Tools expose Virtuoso Stored Procedures and OpenAPI Webservices as MCP-accessible interfaces. OPAL wraps a Virtuoso SQL Stored Procedure or an OpenAPI-compliant Webservice as a Tool, loosely coupled to the Data Space underneath — the source of truth stays in the system that already owns it.
- MCP-native and A2A-ready. Every Skill is exposed as a Model Context Protocol tool and publishes an Agent Card, discoverable by any MCP client or A2A-aware agent without custom client code.
- Identity separate from the human it acts for. Each call down the chain carries its own ABAC-scoped agent identity, so an agent can be granted exactly the access a task requires — no more, no less.
- Versioned like code. Agents, Skills, and Tools are artifacts you can diff, review, and roll back — not a prompt someone edited in a chat window last Tuesday.
Three tiers, each one replaceable on its own#
Why believe us — the facts
OPAL is not a new company's first product. It runs on Virtuoso, the engine OpenLink has developed since 1998, and on the ABAC identity model already protecting production data spaces — the agent layer is new, the governance underneath it is not.
Same connectivity, no new trust boundary. Skills that read or write relational data go through UDA's ODBC/JDBC drivers — the same drivers your BI tools already use, under the same security review.
Deployment shape: a typical OPAL rollout exposes [N] skills across [M] backend systems within the first engagement phase, scoped to [K] ABAC identity roles. (Figures to be supplied from engagement records — this page states nothing it cannot prove.)
Virtuoso, OPAL, and LOAM, working as one#
VOICE (Virtuoso Open Interoperable Context Engine) pairs federated data access and semantic context with an agent harness and persistent memory (LOAM, Linked Open Agent Memory), so any agent and any LLM can work across the Data Spaces you already have.
Ready when your data is
Bring one workflow your team keeps rebuilding in prompts.#
We'll show you what it looks like as a governed OPAL skill instead — and whether a Forward Deployed Engineering engagement gets it into production.