Why this mapping exists

What this is

A translation table. Twenty-eight concepts from Service-Oriented Architecture, each paired with its closest equivalent in agentic systems, with a plain description of both sides. It's published as a web page, as JSON and CSV, and as a formatted sheet you can print and put in front of people who don't read JSON.

It is small on purpose. The point isn't to define everything about agentic architecture — it's to give two people from different backgrounds a way to finish a sentence. An architect who spent a decade on service registries and an ML engineer who's been building tool-using agents for eighteen months are often describing the same structure with no overlapping words. This is a phrasebook for that conversation.

Why the terms come from SOA

Because a vocabulary's value comes entirely from how many people already share it, and a brand-new one starts at zero. SOA's terms have been in working use for twenty years. Anyone who has designed an enterprise system knows what a contract is, what a registry does, what loose coupling buys you and what it costs. Naming the agentic equivalents after concepts that already carry meaning imports all of that understanding for free.

There's a limit to the analogy, and it's worth stating plainly rather than glossing it. Services execute what they were built to execute. Agents decide. That difference shows up right where you'd expect: a circuit breaker halts calls to a failing service, while an agent fallback might reroute to a different agent or escalate to a person — related idea, genuinely different mechanism. SOA also treats statelessness as a virtue, where agentic systems often need deliberate memory, so the useful translation isn't "avoid state" but "be explicit about which state you keep." The mapping gets you most of the way and then hands off. That's the honest claim.

It's also worth learning from where SOA went wrong, not just where it went right — the complexity creep, the vendor fragmentation that standardization was supposed to prevent, the governance that arrived late. The whitepaper spends real time on those failures, because a field copying SOA's vocabulary should know which parts of the experience not to copy.

What this isn't

Not a standard. Nobody ratified this, and calling it a standard would be a claim we haven't earned. It's a proposal with a version number.

Not an architecture. Knowing what to call an agent catalog tells you nothing about how to build one, and nothing at all about whether you should.

Not a governance framework, an interaction protocol, or a certification scheme. Those are the genuinely hard problems — agent classification by autonomy level, protocols for negotiation and collaboration, orchestration that survives changing conditions, audit trails and human oversight, and metrics that let you compare two implementations honestly. All of them stay open. A vocabulary is the cheapest of the necessary pieces, which is a good argument for doing it first and a bad argument for stopping there.

The Agentic Ontology of Work addresses autonomy levels, human oversight, and audit trails in a formal model that software can validate. It is a proposal, not a ratified standard.

Versions and contributions

Version 2 has twenty-eight pairs. Version 1 had eighteen, covering the concepts with the most direct analogues; the rest arrived as the edges got clearer. It will keep moving, and the places it moves are the interesting ones — the pairings where an SOA concept nearly fits and then doesn't tell you what you actually needed to know.

If a pairing here is wrong, or one you rely on is missing, say so on GitHub. Arguments about where the analogy breaks are the most useful contribution this can attract, more than additions — the breakages are where the vocabulary needs its own words rather than borrowed ones.

Licensing and citation

Prose here is CC-BY 4.0; the structured data is Apache 2.0. Both mean: take it, use it, build on it, change it — just say where it came from. Reuse in a product glossary, a data catalog, an architecture review, a standards submission, or a course is all fine and none of it needs asking.

Each release is archived on Zenodo and carries a DOI, so a citation stays valid even if this page moves. Use 10.5281/zenodo.21823088 to point at the latest version, or 10.5281/zenodo.21823089 to pin v2.0.0 specifically. CITATION.cff in the repository has the same metadata in machine-readable form.

The honest measure of success is this mapping becoming redundant — the industry converging on shared terms, whether or not they're these ones.

Who publishes it

Skan works on observing how enterprise work actually gets executed and turning that into context AI systems can act on — which means spending a lot of time at the seam where agents meet real operational processes. That's the vantage point this came from: the vocabulary problem is one you hit constantly and unavoidably when you try to describe agentic systems to enterprise architects, risk teams, and each other.

Publishing it openly is deliberate. A vocabulary that belongs to one vendor isn't a vocabulary, it's a product glossary, and the industry has enough of those. This is offered to be argued with.