How Forge Gives AI Agents a Living Ontology

In the first piece in this series, I wrote about a talk Dr. Frank Coyle gave at the AI Engineer World’s Fair. His question was simple. As AI agents start perceiving, deciding, and acting on their own, what stops them from drifting into nonsense, taking an action that’s semantically impossible in the real domain, or looping forever without producing anything useful?

His answer was ontologies. The structured, explicit definitions of what a domain’s concepts mean and how they relate to each other. Wrapped around a model’s probabilistic core, an ontology gives an agent something fixed to reason against instead of something it has to guess at. Without it, an agent can sound intelligent while still being fundamentally unreliable, because nothing ever told it what “correct” actually means for the system it’s operating in.

Opsera Forge, the enterprise software factory, is our answer, aimed at software delivery. It takes raw intent, an idea, a requirement, a fix someone on a team needs, and turns it into enterprise-ready code without losing the governance that makes that code trustworthy.

Coyle was describing agents operating in the world generally. Forge is that same argument applied to one specific, high-stakes loop, where an AI agent writes code that ends up in production.

A Software Factory Built as a Living Ontology

An ontology only does its job once a system is actually built to run on it. Forge is built that way from the ground up, structured across three pillars so every stage carries an explicit definition of what the system means, instead of leaving an agent to infer it from a bare prompt. Context captures what a system means. Spec-Driven makes that meaning something an agent can act on. Governance checks every change against it before that change ships. Let’s dive into these three pillars:

Context: The Ontology for the System Being Built

Take a legacy application that’s been running for over a decade. The people who wrote it have moved on. The documentation, if it ever existed, describes a version of the system that no longer matches what’s actually running in production. Ask an AI coding agent to modify that system, and it has nothing to reason from except the code itself, and code alone doesn’t tell you why a decision was made or what business rule it was protecting.

Context is Forge’s answer to that gap. It captures the legacy logic, architecture, organizational rules, and business intent behind a system as a living, reusable specification, one that gets updated as the system itself changes, not written once and left to go stale. That’s functionally the ontology Coyle described in his talk: an explicit, structured definition of what a system’s concepts mean and how they relate. Forge just scopes it to the software being built or maintained, instead of a general business domain. Once that definition exists, an agent working on the system isn’t guessing anymore. It has something to check its own work against.

Spec-Driven: Making the Ontology Enforceable

A definition that only lives in a document doesn’t stop an agent from drifting. It has to become something the agent is actually bound to follow.

Spec-Driven is where Forge does that. It turns a specification into a work order, a concrete unit of execution with requirements, tests, and a clear definition of done attached to it before any code gets written. An agent working from a work order isn’t inferring what “done” looks like from a vague prompt. It checks its output against a definition someone already agreed on.

Governance: The Guardrail Coyle Argued Every Agent Needs

Coyle’s core claim was that a model’s probabilistic core needs a deterministic structure wrapped around it. Ask the same question twice, and a good model gives you two answers that are close in meaning but not identical in form. That’s fine for drafting text. It’s not fine for deciding whether a piece of code is safe to ship.

Governance is that wrapper, applied to every change a system goes through, whether a human wrote it or an agent did. Before code moves forward, it runs against the same shared definition Context and Spec-Driven already established, checked inline as part of the process rather than caught later in a review queue. A human stays in the loop for the decisions that call for one. The agent doesn’t get to decide, on its own, that a change is good enough.

This is the piece that turns an ontology from a reference document into an actual guardrail. Context and Spec-Driven describe what correct looks like. Governance is what makes sure nothing ships without meeting it.

Coyle’s framing is about catching errors before they become expensive. Forge’s answer to “how do we know the guardrails are actually working” is ForgeScore, a health scorecard that rates software across eight engineering dimensions. It makes the abstract idea of “governed AI-generated code” concrete and auditable.

Turning AI Speed into Enterprise Value Needs a Real Structure

There’s an older pattern underneath all of this. The expert systems of the 1980s ran on hand-built rule sets, and they collapsed under their own weight because every rule needed a person to write it and maintain it by hand. Neural networks won out because they learned from data instead of needing everything spelled out in advance. That same flexibility is exactly what makes today’s agents unpredictable at scale.

The industry is rediscovering that the answer isn’t neural or symbolic, it’s neural with symbolic guardrails wrapped around it, applied wherever agents touch something that matters.

For us, that’s the software supply chain. An AI agent can generate code in minutes. Turning that code into something an enterprise can actually trust still takes real structure around it. That’s the gap Forge was built to close, and it’s encouraging to see the same underlying idea, ontologies as guardrails for agentic systems, showing up independently in Dr. Coyle’s work and in what we’ve been building with Opsera Forge.

If you’re thinking about how to keep AI-generated software trustworthy, secure, and compliant as your teams scale, Dr. Coyle’s talk is worth your time. And if you want to see the same principle running inside a real software factory, in production, today, schedule a demo.