The AI Agent Era Doesn't Need More Data — It Needs a Semantic Layer

TL;DR

In the AI Agent era, what's really missing isn't more data — it's an open map of the system.

UModel is an object-graph semantic runtime for enterprise AI. It describes the enterprise world as objects and relationships, and makes those descriptions queryable, verifiable, and callable from agent code. It is not another observability tool, Configuration Management Database (CMDB), or knowledge graph. It sits above them and organizes the facts they already hold into a unified object graph. Taken together, these capabilities mean enterprise data is no longer whatever each system happens to record on its own: it is organized, queried, verified, and invoked around objects.

UnifiedModel is an open source digital twin semantic layer built for Agents. It organizes enterprise assets, runtime data, and system relationships into a queryable object graph. In controlled DataAgentBench experiments, all four flagship models gained 10-20 percentage points once the semantic layer was in place, with GLM-5.2 reaching 50.2% pass@1. Instead of facing isolated data fragments, the Agent reads metrics per object, walks relationships to localize root causes, and actually understands the system it is looking at.

The Problem Isn't a Weak Model — It's the Missing System Structure

Agents have improved fast over the past year. They write code, call tools, plan across multiple steps, and search back and forth across logs, metrics, traces, and change tickets. But drop one into a real production system and ask, "What is actually wrong with payment-gateway right now?" and it will still happily produce an answer that sounds authoritative and is quietly dangerous.

The cause isn't wrong information from any single tool. CPU at 88% is correct. P99 at 2150 ms is correct. That one slow trace is correct too. The problem is that all of these are only symptoms. The Agent has plenty of fragments, but it doesn't know which object each fragment belongs to, how the objects connect, who depends on whom, or which upstream configuration just changed.

This is the engineering version of the blind men and the elephant. Metrics, logs, traces, tickets, and code repositories each touch a real piece of the animal. No single structure tells the Agent what the whole elephant looks like.

The usual first reaction is to give the Agent more capability:

Swap in a stronger model so it can reason longer.
Give it a longer context and push in more logs and documents.
Add retrieval-augmented generation (RAG) so it can retrieve more fragments.
Add memory so it keeps past conversations and lessons.
Wire up more Model Context Protocol (MCP) tools, or even go multi-agent.

Every one of these makes sense, but they add capability and data. They don't address system structure. Connecting to every system is not the same as understanding it. Having every fragment in context is not the same as knowing how they relate.

What's missing is a semantic layer — a structure that captures the objects, relationships, fields, evidence, and action context of the real system.

What a Semantic Layer Really Is: An Externalized World Model

To an Agent, a complex system should not be a pile of tables, APIs, and log files. It should be a queryable world model:

Which objects exist: services, hosts, databases, configurations, deployments, teams, alerts.
How objects connect: services call services, services run on hosts, deployments affect services, configurations act on traces.
Which fields each object class carries: status, owner, service-level objective (SLO), lifecycle, primary key, labels.
Which observability evidence hangs off which object: metrics, logs, traces, events, Runbooks.
Which actions are allowed under which conditions: rollback, rate limiting, scale-out, retry tuning.

In information science, this idea is rooted in ontology — the study of what kinds of things exist in a domain and how they relate. UnifiedModel brings that thinking into engineering systems, describing a digital twin object graph with a very small set of unified primitives.

A semantic layer does not copy all your data into a new database, nor chop documents into segments for a vector store. Think of it as a system map for the Agent. The Agent can still call Prometheus, Simple Log Service (SLS), Elasticsearch (ES), MySQL, Kubernetes, and the CMDB — but it starts from objects rather than from a database engine, follows relationships to the evidence, and then generates an executable query or action plan.

UnifiedModel: Design and Capabilities

The Minimal Primitives of UnifiedModel: Set + Link + Field

UnifiedModel reduces the object graph to three core primitives:

Primitive	Meaning	Typical types
Set	A node — a class of objects or a class of data collections	EntitySet, MetricSet, LogSet, TraceSet, EventSet, RunbookSet
Link	An edge — a relationship among objects, data, and storage	EntitySetLink, DataLink, StorageLink
Field	Field semantics and constraints	Type, unit, semantic role, primary key, mapping, display form

Combine the three and you can express the full entity-data-storage chain:

EntitySet ──DataLink──> DataSet ──StorageLink──> Storage
│
└──EntitySetLink──> EntitySet

Here's the smallest example from an observability scenario:

platform.service is an EntitySet representing the service entity class.
platform.host is another EntitySet, representing hosts.
Services and hosts are joined by a runs_on relationship — that's an EntitySetLink.
A service's latency, error rate, and QPS hang off a MetricSet — that's a DataLink.
That MetricSet physically lives in Prometheus or SLS — that's a StorageLink.
latency_p99_ms is a Field. It carries more than a column name: type, unit, semantics, and query mapping.

What matters here isn't that you drew a graph. It's that the graph can be queried and validated — and discovered and called by an Agent.

Classes and Entities: Define the Model Once, Write to the Runtime Continuously

Two levels in the object graph are easy to conflate: classes and individuals.

Classes are the definition layer — what fields a "service" object has, what its primary key is, which datasets it can associate with, and which entities it can relate to. In UnifiedModel, EntitySet, DataSet, Link, and Field describe this layer. It corresponds to the TBox in ontology.

Individuals are runtime data.checkout-service, payment-gateway, and catalog-api are concrete service entities; payment-gateway calls risk-control is a concrete relationship. They are written, updated, and expired continuously as the system runs. This layer corresponds to the ABox.

A simplified definition layer might look like this:

kind: entity_set
domain: platform
name: platform.service
pk:
  - id
fields:
  - name: id
    type: string
    semantic_role: entity_id
  - name: status
    type: string
  - name: latency_p99_ms
    type: double
    unit: ms

The runtime then writes entities and relationships continuously:

{
  "entity_set": "platform@entity_set@platform.service",
  "entity_id": "payment-gateway",
  "fields": {
    "status": "degraded",
    "latency_p99_ms": 2150
  }
}

This split matters. Classes tell the Agent which types and methods exist in the world; individuals show it what is happening in that world right now. The first is stable, the second dynamic, and only together do they make a live object graph.

Runtime: Turning the Object Graph into One Query Surface for Humans and Agents

UnifiedModel Runtime isn't another isolated platform. It adds a semantic runtime on top of the systems you already run.

Top to bottom, it has four layers:

Access layer: Web UI, CLI, Skills, MCP Gateway. Humans query it; agents query it too.
Runtime services: Workspace, definition validation, entity writes, relationship writes, Query Service, Agent Gateway.
Graph abstraction layer: a single encapsulation of objects, relationships, methods, datasets, and storage mappings.
Storage layer: memory, files, graph databases, plus external data sources such as Prometheus, SLS, ES, and MySQL.

One Query Surface: SPL Covers Definitions, Entities, Topology, and Data Plans

An object graph has to be queryable in a stable way, or it's just documentation. UnifiedModel covers several viewpoints with a single SPL query surface:

Query surface	Purpose
`.umodel`	Query model definitions and metadata
`.entity`	Query specific entities
`.entity_set`	Call methods on an entity class — list datasets, generate a metric plan, generate a log plan
`.topo`	Query topology relationships and neighbors
`.runbook_set`	Query the O&M knowledge and recommended actions attached to an object

An entity query can be very direct:

.entity with(domain='platform', name='platform.service')
| project id, display_name, status, owner
| limit 20

A topology query starts from an object and looks at its neighbors:

.topo
| graph-call getNeighborNodes(
    'platform@entity_set@platform.service',
    'payment-gateway',
    2
  )

Method calls matter even more. An Agent can first ask an EntitySet which methods it has, then call one by signature. A service object, for example, can expose get_metrics, get_logs, and list_data_set. The call doesn't dump full data into the model — it returns an executable plan:

.entity_set with(
  domain='platform',
  name='platform.service',
  ids=['payment-gateway']
)
| entity-call get_metrics('latency_p99_ms', '5m')

The result can be PromQL, an SLS query, ES DSL, or a structured query plan. The Agent executes the plan afterward, which cuts hallucination and reduces the risk of querying the underlying data sources incorrectly.

AI-Friendly: Self-Describing, Progressive Disclosure, MCP, and Skills

"Agent-friendly" doesn't mean stuffing docs into the model. It means making the runtime discoverable.

UnifiedModel does three things for Agents.

First, self-description and progressive disclosure. The Agent doesn't need the full schema up front. It can call __list_method__ to learn which methods the current EntitySet offers, what the parameters are, and what comes back, then decide the next step. Context doesn't fill up all at once, and the Agent never has to guess.

Second, the MCP Gateway. A standard protocol exposes query, explanation, example, and validation capabilities to any Agent. Read tools are available by default; write tools are off by default or require explicit authorization; resources expose metadata only; and every access goes through the Query Service.

Third, Skills. Common capabilities are packaged as loadable skills — object graph queries, root-cause analysis (RCA), impact analysis. Claude Code, Cursor, and Codex then share the same semantic capabilities instead of each Agent writing its own adapter.

The design principle behind all three: discover before calling, get a plan before executing, go through the semantic layer before touching the underlying tools.

UnifiedModel in Practice

Onboarding: From a Real System to a Queryable Object Graph

Onboarding a real system into UnifiedModel takes three steps.

Step 1: model it. Write the model package YAML and define entities, fields, relationships, datasets, and storage mappings. Then run the validation tool to confirm the model is legal.

umctl umodel validate <workspace> --file model-pack.yaml
umctl umodel import <workspace> --file model-pack.yaml

Step 2: write runtime individuals. Entities, relationships, lifecycle, status, and observability evidence stream in continuously. Entities can come from the CMDB, Kubernetes, OpenTelemetry Resource, the Service Catalog, or your deployment system; relationships can come from traces, configuration systems, code dependencies, or manual registration.

umctl entity write <workspace> --file entities.json
umctl topo write <workspace> --file relations.json

Step 3: query the graph. Humans query with .entity and .topo, and Explorer visualizes the result automatically; Agents discover methods through MCP and Skills, generate query plans, and run troubleshooting flows.

Today you write models and data by hand. Automatic registration, OTel mapping, service discovery, and code scanning will keep lowering that cost. The key point: modeling isn't a big-bang project. It grows incrementally — one scenario, one domain, one service path at a time.

Case Study 1: Read Metrics per Object Instead of Hand-Writing PromQL

Back to the question from the talk: someone asks the Agent, "How is payment-gateway doing?"

Without a semantic layer, the Agent has to work out for itself:

Which service object does payment-gateway map to?
Which system holds the metrics?
What is the metric name for P99?
Should the label be service, service_id, or app?
Is the unit seconds or milliseconds?

Get any of these wrong and the result looks reasonable but is useless.

With an object graph, the flow becomes:

Use .entity to locate platform.service/payment-gateway.
Follow DataLinkto the MetricSet and LogSet it's associated with.
Call get_metrics to generate a query plan, with the entity id, window, unit conversion, and metric semantics filled in automatically.

The Agent can then answer:

Status: degraded
QPS: 4200
Error rate: 14.8%
P99: 2150 ms
Replicas: 5/5

The numbers aren't the point. The point is that they were retrieved per object. The Agent didn't need to master a PromQL dialect or guess a label. The object graph turned "that service" into a precise query.

Case Study 2: RCA Isn't Guessing the Latest Release — It's Walking the Relationship Chain

The second scenario is root cause localization: why did payment-gateway blow its P99 SLO?

The object graph gives you a traversable chain of relationships:

Flash Sale 大促
  └─triggers─> cfg-checkout-retry
      └─affects─> checkout-service
          └─calls─> payment-gateway

This chain connects a business event, a configuration change, an upstream service, and the affected service. The Agent no longer just sees that payment-gateway got slow. It walks up the relationships and pins down the cause: the sales promotion triggered the upstream checkout retry configuration, which amplified traffic.

It can also rule out red herrings. A payment-gateway v3.2.1 deployment 12 hours earlier looks suspicious, but the relationships and evidence show it only changed the log format, which doesn't explain a P99 SLO breach. So the Agent doesn't mechanically blame the latest release.

4000 QPS × 3.5x sales promotion traffic × (5 / 2) retry amplification = 35000 QPS 
35000 / 4000 = 8.75x

The conclusion becomes:

The root cause isn't that deployment. It's the upstream retry count going from 2 to 5 and then meeting promotion traffic.
The overload is roughly 8.75× the original capacity.
The recommended action is to roll retries back to 2 and add rate limiting.

Closing: Model the Real World First, Then Organize the Data

In the agent era, what we need to add isn't more fragments. It's a structure that organizes them. Data is just the symptom; objects and relationships are the system structure.

UnifiedModel's core bet is this: use Set + Link + Field to build a real system into an object graph that can be queried, traversed, and executed against; hand that graph to humans and Agents alike through SPL, the Runtime, MCP, and Skills; then close the loop across data, knowledge, and action so the Agent doesn't just see metrics — it understands the system along its real relationships.

One line: model the real world first, then organize the data. The semantic layer is the infrastructure of the Agent era.

Community

The AI Agent Era Doesn't Need More Data — It Needs a Semantic Layer

TL;DR

The Problem Isn't a Weak Model — It's the Missing System Structure

What a Semantic Layer Really Is: An Externalized World Model

UnifiedModel: Design and Capabilities

The Minimal Primitives of UnifiedModel: Set + Link + Field

Classes and Entities: Define the Model Once, Write to the Runtime Continuously

Runtime: Turning the Object Graph into One Query Surface for Humans and Agents

One Query Surface: SPL Covers Definitions, Entities, Topology, and Data Plans

AI-Friendly: Self-Describing, Progressive Disclosure, MCP, and Skills

UnifiedModel in Practice

Onboarding: From a Real System to a Queryable Object Graph

Case Study 1: Read Metrics per Object Instead of Hand-Writing PromQL

Case Study 2: RCA Isn't Guessing the Latest Release — It's Walking the Relationship Chain

Closing: Model the Real World First, Then Organize the Data

Read previous post:

Read next post:

Alibaba Cloud Native Community

You may also like

Comments

Alibaba Cloud Native Community

Related Products

Application Real-Time Monitoring Service

Managed Service for Prometheus

Real-Time Livestreaming Solutions

QwenWork