The vocabulary problem
SOA-to-Agentic AI Terminology Mapping
Ask three practitioners to define an "AI agent" and you'll get four answers. The same goes for "workflow," "orchestration," and "task." That isn't an academic quibble — it's why integrations break at the seams, why buyers can't tell two products apart, and why nobody can write a governance policy that means the same thing twice. Enterprise computing had this exact problem before SOA gave it a shared grammar. So rather than invent a vocabulary from scratch, we started from the one that already worked.
Agentic AI Taxonomy V2 (based on SOA)
We didn't invent the agentic terms on the right, and SOA isn't ours to claim. We set the two vocabularies side by side, because the quickest way to get an industry to agree on what to call something is usually to borrow from a naming scheme it already settled once. Related concepts sit next to each other, so you can read straight down either column.
SOA era
Agentic era
Service / Microservice
A discrete unit of functionality that can be accessed remotely and acted upon independently, deployed and versioned on its own so that changing it does not require changing its consumers.
Agent
An autonomous AI entity that can perform specific tasks, make decisions, and interact with other agents, choosing how to accomplish an objective rather than following a fixed sequence of steps.
Microservices
Architectural approach using small, independently deployable services, each owning a narrow slice of business capability so teams can build, release, and scale them separately.
Agent Tools
Specialized, focused AI agents designed for specific tasks within larger systems, narrow enough to be reasoned about, tested, and replaced individually rather than as part of one monolithic agent.
Common Services
Reusable services that provide shared functionality across multiple applications — authentication, notification, document generation — maintained once and consumed everywhere.
Agentic Tools
Reusable AI capabilities and functions that agents can utilize to perform common tasks, exposed as a shared library so every agent does not reimplement the same retrieval, extraction, or calculation.
Service Contract
A formal specification defining how to interact with a service, including inputs, outputs, and constraints, so consumers integrate against the contract rather than the implementation.
Agent Contract
A specification defining an agent's capabilities, interaction protocols, and behavioral constraints — what it may do on its own, what it must escalate, and what callers can rely on.
Service Registry
A directory where services are published and can be discovered by consumers, holding the endpoint, version, and contract for each registered service.
Agent Catalog
A repository where agents are registered and can be discovered by other agents or orchestrators, recording each agent's capabilities, ownership, and permitted scope.
Service Discovery
A dynamic mechanism for locating available services at runtime, resolving which instance to call as deployments scale up and down.
Agent Discovery
A dynamic mechanism for locating available agents and their current capabilities at runtime, so work is routed to whichever agent is actually able and permitted to handle it.
Service Bus (ESB)
Enterprise service bus providing message routing, transformation, and integration capabilities, so systems that do not share a data format can still exchange work.
Execution Mesh
Central orchestration layer managing agent lifecycle, routing, and coordination, carrying work between agents and the systems they act on.
API Gateway
A single entry point managing routing, security, authentication, and rate limiting for service consumers, so those concerns are handled once at the edge rather than in every service.
Agent Gateway
A single entry point managing routing, authentication, and rate limiting for external systems and human users interacting with agents, and the place where access policy is applied.
Orchestration (BPEL)
Coordinating multiple services to execute complex business processes, with the sequence, branching, and error handling defined centrally.
Agentic Orchestrator
System that coordinates multiple agents to execute complex automated workflows, assigning work, tracking progress, and deciding what happens when an agent fails or escalates.
Service Choreography
A peer-to-peer collaboration pattern where services interact directly via events, without central control over the sequence.
Agent Choreography
A peer-to-peer collaboration pattern where agents coordinate directly through shared events or signals, without a central orchestrator directing each step.
Service Composition
Combining multiple services to create higher-level business functionality, so a complete process can be assembled from parts built independently.
Agent Assembly (or Agent Build)
Combining multiple agents to create complex autonomous systems and workflows, assembling specialists into something that completes an end-to-end process.
Loose Coupling
Services are designed to have minimal dependencies on each other, so one can change or fail without forcing changes elsewhere.
Agent Autonomy
Agents operate independently with minimal dependencies, making autonomous decisions within their granted scope rather than waiting on a controller for every step.
Service Granularity
The level of functionality encapsulated within a single service, and the trade-off between many small services and fewer larger ones.
Agent Scope
The breadth and depth of responsibilities assigned to a specific agent, which determines both what it can accomplish alone and how much of the system its failures reach.
Statelessness
A design preference that services not retain client state between calls, so any instance can serve any request.
Session State Boundary
An explicit definition of what an agent retains in operational memory between interactions and what it deliberately discards — since useful agents often need memory rather than none.
Idempotency
A property ensuring repeated calls produce the same effect as a single call, making retries safe after a timeout or partial failure.
Idempotent Action
A property ensuring a repeated agent action produces the same effect as a single execution, which matters more here because retries are often decided autonomously.
Circuit Breaker
A resilience pattern that halts calls to a failing service to prevent cascading failure, resuming only once it recovers.
Agent Fallback Protocol
A resilience pattern that halts delegation to a failing or underperforming agent and reroutes to a fallback agent or human escalation, rather than simply stopping.
Event-Driven Architecture
Architecture where services respond to and produce events for loose coupling, with producers unaware of which consumers will react.
Agent Triggers
Event-based activation mechanisms that prompt agents to take specific actions, so work begins when a condition is met rather than when someone invokes it.
Message Exchange
Structured communication patterns between services, defining request/response, publish/subscribe, and the message shapes each side expects.
Agent Communication Protocol (ACP)
Standardized methods for agents to exchange information and coordinate actions, covering not just message format but how intent, context, and results are conveyed.
Service Integration Protocol
Standard protocols for web service communication and data exchange, such as SOAP and REST over HTTP.
Agent Integration Protocol (AIP)
Standardized interfaces and protocols for agent communication and integration, so agents built on different platforms work together without bespoke adapters.
Interoperability
Ability of different systems and services to work together effectively, across vendors, platforms, and data formats.
Cross-Agent Standards
Protocols and standards enabling agents from different systems to collaborate, so a multi-agent workflow is not confined to one vendor's runtime.
Enterprise Integration Patterns (EIP)
Standard patterns for integrating enterprise applications and services — named solutions to recurring routing, transformation, and messaging problems.
Agent Patterns
Reusable design patterns for agent interaction, coordination, and integration, giving teams a shared name for structures they would otherwise reinvent.
Canonical Data Model
A shared, standardized data schema used across services to avoid point-to-point translation between every pair of systems.
Canonical Context Model
A shared, standardized schema for context entities so agents interpret the same situational data consistently across an enterprise, rather than each holding its own view.
Service Consumer / Provider
The two parties in a service interaction: the caller and the service being called.
Requester / Fulfilling Agent
The two parties in an agent-fulfilled intent: whoever originates the request — a person, another agent, or an orchestrator — and whichever agent fulfills it.
Service Versioning
Managing multiple concurrent versions of a service interface as it evolves, so existing consumers keep working while new ones adopt the change.
Skill Versioning
Managing multiple concurrent versions of an agent's skill set or behavior as it evolves through feedback and memory updates, so changes are traceable rather than silent.
Service Virtualization
Creating virtual representations of services for testing and development, so teams can build against dependencies that are unavailable or costly to call.
Agent Virtualization
Creating test agents by abstracting real-world conditions for testing, training, and development purposes, so behavior can be exercised safely before it touches production work.
SLA (Service Level Agreement)
Service Level Agreement defining performance, availability, and quality metrics, and what happens when they are not met.
Agent QoS
Quality of Service metrics defining agent performance, reliability, and response standards, including accuracy and escalation rates alongside latency and uptime.
Service Level Objective (SLO)
An internal target metric that supports meeting an external SLA, set tighter than the commitment to leave room to recover.
Agent Performance Objective
An internal target metric supporting an agent's external QoS commitments, tracked continuously so degradation is caught before it breaches the commitment.
Governance
Policies, processes, and controls for managing services throughout their lifecycle, from approval and deployment to retirement.
Agentic Governance
Framework for managing agent behavior, compliance, ethics, and lifecycle management, including audit trails, human oversight, and accountability for autonomous decisions.
Downloads
Everything here is free to use and share, with attribution. The JSON and CSV are the same twenty-eight pairs in machine-readable form — drop them into a glossary, a data catalog, or an architecture review deck.
The whitepaper
The full paper: why the vocabulary gap matters, what SOA got right, what it got wrong, and what still needs standardizing beyond names.
Terms sheet
All twenty-eight pairs on a formatted reference sheet, ready to print or circulate.
Terms
One row per pair, four columns. Opens in any spreadsheet.
Terms
The canonical source the rest of this page is generated from.
Why this exists
The definitional chaos costs real money. CIOs can't evaluate vendors when each one uses proprietary terminology. Development teams hit integration problems when two things both called "agents" turn out to work nothing alike. Risk management is close to impossible when the scope and capabilities of an "agentic system" are undefined.
SOA solved a version of this in the early 2000s, and it's worth being honest that it didn't solve it perfectly — SOA implementations drowned in complexity creep, fragmented across vendors anyway, and often shipped without the governance to hold them together. Those failures are as instructive as the successes, which is why the whitepaper spends as much time on them.
What still needs standardizing
A shared vocabulary is the start, not the finish. What the industry still needs is agent classification by autonomy level, protocols for how agents negotiate and collaborate, orchestration patterns that survive changing conditions, governance covering audit trails and human oversight, and quality standards that let you compare two implementations honestly.
We're not proposing to solve that alone, and we'd rather not see it solved proprietarily. If a pairing here is wrong, or one you need is missing, open an issue — disagreement about where SOA's concepts stop working for agents is exactly the useful kind.
More on the thinking behind this, what it deliberately isn't, and how to use it: about this mapping.
Related project
Agentic Ontology of Work
The Agentic Ontology of Work (AOW) defines how these terms relate to each other. It includes a five-level autonomy scale, rules for human oversight, and checks that trace each result to its business objective. It is published as a whitepaper and as an OWL ontology with SHACL shapes and JSON Schemas.
A crosswalk, maintained in the AOW repository, maps each of the 28 agentic terms on this page to AOW: https://github.com/Skandotai/agentic-ontology-of-work/blob/main/crosswalks/soa-to-agentic-terms.csv