Designing Ontology After Microservices in AI‑Native Service Architecture

Over the past ten years microservices have become the default enterprise software architecture. Business growth leads to splitting services, building middle platforms, and adding gateways, registries, message queues, and observability platforms. This solves parallel development and independent deployment but keeps architectural discussions focused on deployment topology.

The introduction of AI agents changes the requirements. Besides humans, the system now serves agents that must understand goals such as “find high‑risk customers this week and give recommendations”, “handle a batch of fulfillment exceptions”, or “explain why monthly profit dropped”. These tasks span CRM, ERP, ticketing, order, inventory, logistics, finance, and data‑warehouse systems. Existing microservices expose APIs but cannot answer semantic questions like whether the “customer” in CRM, ticketing, and finance is the same entity, how metrics such as “high risk” or “effective lead” are defined, which conclusions are factual versus model‑based, what actions a user may perform, or which data, rules, and versions underpin a judgment.

Historically these gaps were filled by employee experience, departmental collaboration, and offline processes. Agents lack that organizational knowledge and must rely on explicitly provided context; the more interfaces and the more fragmented the semantics, the longer the reasoning chain and the lower the accuracy.

The missing layer is a business‑semantic layer. Microservices handle deployment and runtime; agents handle task understanding and execution; between them we need a layer that explicitly manages business objects, metrics, rules, and evidence. This is the role of Ontology.

Consequently, the next‑generation application service architecture must migrate its design starting point: microservices continue to solve runtime problems; Ontology aggregates the dispersed objects, rules, and actions into a unified business semantics; agents use this semantics to achieve goals. Service boundaries are driven by the business ontology, while deployment follows scenario, team, and compliance needs.

What Problems Microservices Left Behind

Microservices still provide four engineering values:

Independent delivery : different teams can develop, test, and release at their own pace.

Elastic scaling : order queries, model inference, vector retrieval, and payment transactions can use different resource strategies.

Fault and security isolation : high‑risk capabilities such as payment, settlement, and identity can be protected independently.

Technology and compliance isolation : GPU services, data residency, and legacy system adapters can use different tech stacks.

However, microservices encourage teams to own their domain data models, state definitions, and business rules. As a result, the deployment boundary becomes the business boundary, and the same business concept sprouts multiple local versions across services.

CRM 的客户    → 线索来源、商机阶段、归属销售
客服系统的客户    → 联系人、服务等级、历史工单
订单系统的客户    → 收货主体、订单与履约状态
财务系统的客户    → 签约主体、信用额度、应收账款

These models are valid in their own contexts, but the enterprise lacks a cross‑system answer to questions such as how the objects correspond, when they are valid, and who decides. The microservice architecture itself does not assume this responsibility, creating a long‑standing semantic gap that becomes a systemic risk once agents are in production.

Four Scenarios That Expose Semantic Gaps

Sales collaboration : CRM, SCRM, marketing automation, and contract systems evolve independently, yet there is no unified mapping for “customer”, “contact”, “opportunity”, or “effective lead”. AI can detect purchase signals but cannot determine whether it can write back an opportunity stage.

Business operation : Order, inventory, logistics, payment, and after‑sale services scale and isolate faults independently, but “fulfillment exception”, “sellable inventory”, and “compensation eligibility” are scattered across services, causing agents to make conflicting decisions based on different snapshots.

Customer service : Knowledge base, ticketing, device, and customer systems are built by domain, yet the same return‑policy appears in operational documents, FAQ, and contract clauses with different versions; agents cannot know which rule applies to the current customer.

Business analysis : Transaction systems and data warehouses are decoupled, allowing independent query and computation optimization, but metrics such as revenue, active customers, and gross margin have divergent definitions; agents can generate fluent reports but cannot guarantee traceable numbers or reasons.

The common root is that existing systems provide data and APIs but no unified, executable, traceable business world for consumers.

Why Ontology Is Needed

Current technical means cover part of the need: APIs list available interfaces, knowledge bases list documentation. Production‑grade agents, however, must answer deeper questions: what state an object is in, how a metric is calculated, how rules constrain actions, who has permission, and how results are audited.

In this article, “Ontology” refers not to Semantic Web OWL/RDF but to an enterprise Business Ontology—a service layer that uniformly describes business objects, relationships, states, metrics, actions, policies, and evidence.

Object : customers, opportunities, orders, tickets, products, organizations, etc.

Relationship : links such as customer‑opportunity‑contract‑order‑ticket.

State : object status, transitions, and valid conditions.

Metric : unified definitions for revenue, gross margin, active customers, etc.

Action : permissible business actions and their preconditions.

Policy : business rules, permissions, approvals, security, and data scope.

Evidence : data sources, rule versions, snapshot timestamps, and execution records.

Ontology does not replace underlying systems—CRM, ERP, data warehouses remain the authoritative sources of transaction facts. Its role is to map those facts into a unified Business Semantics that humans, applications, workflows, and agents can share, while routing controlled operations back to the authoritative systems.

Industry practice already validates this view:

Palantir Foundry makes Ontology the core of its product architecture, organizing objects, relationships, actions, permissions, and underlying data into a stable business model that agents and workflows consume.

Salesforce Data Cloud connects Sales Cloud, Service Cloud, Marketing Cloud, etc., with a unified data model that provides cross‑system context for Agentforce.

用友’s AI product YonClaw builds on the BIP business model, skills, processes, and security audit to enable agents to reuse business semantics and execute tasks under control.

These examples operate at different architectural layers but all illustrate that production‑grade agents need a unified business runtime model, standardized capability contracts, and auditable execution boundaries.

Ontology‑Driven Service Architecture

Traditional service design follows organization and technical constraints:

组织结构与技术约束 → 服务拆分 → 各服务内部建模 → API 集成

Ontology‑driven design reverses the order:

业务场景 → 对象、关系、状态、指标、动作、策略与证据
        → 形成 Ontology 模块
        → 通过协议暴露可理解、可执行的业务能力
        → 按负载、团队、安全与合规需要选择部署形态

Two diagrams illustrate the core structural differences.

The distinction is not about using large models or retaining microservices, but about what the architecture serves and who it serves.

Traditional microservice architecture treats each service as the basic unit: a service encapsulates its data, rules, and API, and upper‑level applications call interfaces based on pre‑designed flows. It assumes callers know business meanings, call order, and error handling, so the focus is on how services are split, deployed, communicated, and governed.

AI‑Native architecture treats business objects, relationships, states, metrics, actions, policies, and evidence as the basic unit. Humans, applications, workflows, and agents all face the same understandable, discoverable, executable business runtime model. Agents plan paths dynamically and cannot rely on developers to pre‑wire every task, so the system must provide machine‑readable contracts for “what an object is, how a metric is calculated, which rules constrain an action, who may execute it, and what evidence backs a decision”, and enforce permissions, approvals, audit, and compensation during execution.

Thus AI‑Native is not a simple model layer added on top of microservices; it reallocates architectural responsibilities: microservices, monoliths, and SaaS retreat to the record and capability execution layer; the Ontology Service Layer unifies cross‑system business semantics and rules; the capability protocol makes these abilities discoverable and callable; the Agent runtime executes goals within defined permission, approval, and audit boundaries. The architectural focus expands from “is the service topology reasonable?” to “is the business semantics unified, are capabilities composable, and is the agent’s dynamic execution controllable?”. This shift moves the architecture from a “model + API” two‑layer to a more complete five‑layer shape.

Five‑Layer Application Architecture

Experience & Trigger Layer : captures human actions, dialogues, events, and system calls, deciding where a task enters the system. AI‑Native does not require every business to become a chat interface.

Agent Runtime : responsible for goal understanding, dynamic planning, capability selection, and task state management, providing checkpoints, failure recovery, and human‑in‑the‑loop intervention within clear boundaries.

Capability Protocol Layer : exposes business capabilities via standard contracts so they are discoverable, understandable, and callable. MCP (Micro‑Capability Protocol) serves agents, while APIs and events still serve applications and system integration.

Ontology Service Layer : unifies objects, relationships, states, metrics, actions, policies, and evidence, turning dispersed system capabilities into an executable business runtime model—the semantic core of the whole architecture.

Record & Data Layer : stores authoritative facts and completes final transactions. CRM, ERP, databases, microservices, monoliths, and SaaS can continue to exist without being rebuilt for agent integration.

The guiding principle is: the closer a layer is to business intent, the more probabilistic judgment it may allow; the closer a layer is to rules and transactions, the more deterministic, auditable, and non‑bypassable it must be.

Key is not to let AI take over all logic but to confine uncertainty to upper layers while sinking determinism into lower layers. Agents can decide the next step to try, but they cannot redefine metric definitions, modify refund permissions, or skip approvals; every read, judgment, and execution must be grounded in explicit semantics, rules, and evidence.

Division of Responsibilities

Microservices, monoliths, SaaS answer “how capabilities run”: splitting, scaling, fault isolation, and independent delivery.

Ontology answers “how the business world is defined”: object definitions, metric calculations, rule constraints, and evidence.

Agent runtime & capability protocol answer “how goals are achieved”: task decomposition, capability selection, and controlled execution.

Together they solve runtime, semantics, and execution problems, forming the new AI‑Native application architecture. Service boundaries may shift with team, load, or compliance needs, but the Business Semantics remain stable.

Conclusion: microservices successfully break large systems into independently developable units, yet they also scatter business objects, rules, and context across services. When agents dynamically plan and execute cross‑system tasks, the missing unified semantics become execution risk. Ontology provides the unified business model; capability protocols make abilities discoverable; and the Agent runtime executes goals within controlled, auditable boundaries. This is the genuine transformation of AI‑Native architecture.

The next article will explore the relationship and differences between Domain‑Driven Design and Ontology from the perspectives of data governance and domain modeling.