OPAL
One harness. Everything loosely coupled, from Agent to Data Space.
OPAL is a harness that orchestrates loosely coupled Agents, LLMs, Skills, Tools, and Data Spaces: databases, knowledge bases, filesystems, and APIs. Swap the LLM, change a Tool, or move a Data Space, and nothing above or below it needs rewriting. Skills run on context and memory, are exposed over MCP and A2A, and act under their own ABAC-scoped identity.
Agents · LLMs · Skills · Tools · Data Spaces · Context & Memory · MCP · A2A
Loosely coupled, top to bottom. An Agent calls a Skill; a Skill calls a Tool; a Tool reaches a Data Space. 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. Eighteen months into most enterprise AI programs, the result is a pile of one-off integrations that break when a schema changes or a system is replaced, because the Agent, the Tool, and the Data Space were never separate things to begin with. OPAL keeps them separate. You build Agents, Skills, and Tools once; Tools expose Virtuoso SQL Stored Procedures and OpenAPI-compliant Webservices as MCP-accessible interfaces; and the Data Spaces beneath them can change without anyone rewriting a prompt.
Three layers, each loosely coupled to the one beneath it#
Nothing about your systems changes. OPAL is the harness where Agents, Skills, and Tools get created and deployed, and where they stay loosely coupled to your LLMs and to the Data Spaces they depend on.
- Agents, Skills, and Tools, created and deployed in OPAL. The work of building an agent happens here, including the Tools it calls.
- 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, so the Tool behind it can change without the Skill being rewritten.
- The source of truth stays put. A Tool wraps a Stored Procedure or Webservice over a Data Space, so the data 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.
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.