UModel: Alibaba's Workspace-Scoped Object Graph for Agent Queries
The semantic layer that makes enterprise data understandable to AI agents — model entities and relations once, query through SPL/MCP/REST, and connect telemetry, services, and business objects in one object graph.
At a glance
- What is it?
- UModel is a local, vendor-neutral semantic runtime from Alibaba that models entities and relations once, then exposes them to agents and humans through SPL, MCP, and REST. It is early (v0.4.0) and the licence file is non-standard, so adopt it for local evaluation, not as a production semantic layer.
- Who is it for?
- Adopt UModel if you are building agent workflows that need a shared, queryable object graph over services, telemetry and business objects, and you are comfortable running a Go 1.22+ service locally with GRAPHSTORE=memory for evaluation.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem UModel targets: schema fragments that agents cannot read across
An agent asked to investigate a service outage needs to know that a service owns a pod, that the pod emits metrics, that those metrics belong to a dataset, and that a runbook is attached to the service. In most enterprises those facts live in four systems with four naming conventions. UModel's premise is that you model that vocabulary once, as a model pack, and then let agents query the resulting graph instead of stitching together ad hoc lookups. The README frames this as turning fragmented schemas, entities, business objects, telemetry links and topology relations into workspace-scoped graph context. The intended users are platform and data governance teams who want agent workflows to share one semantic contract, plus the agent authors who consume it. The scope is deliberately local: the repository ships a local service, a umctl CLI, an MCP server, an OpenAPI contract, a React Web UI, example packs and Docker assets. Cloud-hosted control planes and domain-specific read APIs outside Query Service are named as out of scope.
Model packs, EntityStore, Query Service: the runtime shape
The architecture described in the README is a four-part loop. Model packs define the object vocabulary: EntitySets, datasets, links, storage and relation semantics. EntityStore writes the runtime entities and topology relations that instantiate that model, so the graph is populated rather than declared. Query Service is the single read surface, and it speaks three namespaces: .umodel for the model itself, .entity for entities, and .topo for topology. AgentGateway and MCP sit on top, exposing discovery, resources, query examples and what the README calls safe tools for agent clients. Everything else (Web UI, CLI, REST, SDK) operates against the same public contracts, which is the design choice that matters here: the contracts are the product, and the server internals are not. The workspace is the isolation boundary. The quickstart names a demo workspace, and the demo video describes an agent reading across the object graph in a workspace called quickstart-multidomain, discovering services, walking cross-domain topology and pulling metrics and logs through model-scoped query plans. That phrase, model-scoped query plans, is the mechanism worth understanding: the agent does not hand-write a query against your metrics store, it asks the model what is queryable and the plan is derived from the model.
Getting it running: make check-env, make quickstart, make stop-all
The documented path is short. Requirements are Go 1.22 or newer, Make, Node.js 22 or newer for the Web UI, and pnpm 9 or newer preferred, with corepack or npm exec fallback supported by the Makefile. First you check the toolchain with make check-env. Then make quickstart starts a local API, starts the Web UI, preloads the demo workspace with GRAPHSTORE=memory, and, per the README, leaves no local demo data behind after the process stops. The UI is at http://localhost:5173, where you select demo and inspect it through Explorer, Query, Data Store and Agent views. To stop everything, make stop-all. Agent integration has its own first step: umctl agent discover demo, then connecting an MCP client through umodel-mcp. There is also a skills route. A skill-aware agent can load three SKILL.md files that let it read entities, relations, topology and the model, discover entity-linked RunbookSet skills, and run model-guided root-cause analysis. In Claude Code the install is /plugin marketplace add alibaba/UnifiedModel followed by /plugin install umodel@unifiedmodel. For Qoder, Codex and Cursor the README says to copy the same files into .qoder/skills/, .agents/skills/ and .claude/skills/ respectively. Note that GRAPHSTORE=memory is the documented quickstart setting, so persistence behaviour beyond that is not something the supplied material describes.
Where the open-source core stops
The README is unusually direct about the boundary, and that directness is a feature. Cloud-hosted control planes, multi-tenant authorization, Aliyun internal frontend packages, and domain-specific read APIs outside Query Service are stated as outside the public core. Read that as a deployment constraint, not a roadmap hint. If your requirement is per-tenant isolation with hosted control, this repository does not give it to you; you would be building that layer yourself on top of the public contracts. The same applies to any read API that is not expressed through .umodel, .entity or .topo. A second limitation is maturity. The release history shows v0.2.0, v0.3.0 and v0.4.0 within roughly a week of each other in June 2026, with the most recent push in September 2026. Version 0.2.0 is described as introducing the plan/data mode contract and the agent-friendly query envelope, which means the agent-facing contract is recent and still moving. Teams that need a frozen interface should pin a version and expect to re-read the query envelope documentation on upgrade. Third, the licence metadata says NOASSERTION while the README carries an Apache-2.0 badge. Those two signals conflict, and only the repository's licence file can settle it. Do not treat the badge as the answer.
How UModel differs from a CMDB or a vector store
The obvious comparison is a CMDB, and the difference is the read surface. A CMDB stores configuration items and exposes an API shaped by its own schema; UModel asks you to declare the schema as a model pack first, then serves queries through .umodel, .entity and .topo so that an agent can inspect the vocabulary before it queries the data. That ordering matters for agents, which otherwise guess field names. The second comparison is a vector store or a retrieval index. A vector store returns text chunks ranked by similarity and has no notion of a link between a service and its runbook. UModel's graph is typed: links and relation semantics are declared in the model pack, and topology is a first-class query namespace rather than a property you hope the embedding captured. The trade-off is authoring cost. A vector store ingests documents and works immediately; UModel requires someone to write and maintain the model pack, and the quality of every agent answer depends on that pack being right. If your data is unstructured text with no stable entity identity, the model pack is the wrong abstraction and a retrieval index is the better tool.
Maintenance, upgrades and licence implications
Upgrade cost here is contract cost, not binary cost. The public surface is the OpenAPI document at api/openapi/openapi.yaml and the MCP tool and resource schema at api/mcp/tools.schema.json, plus the CLI and SDK. Those are the files to diff between releases, because the README states that clients should not depend on server internals. The v0.2.0 release note about a plan/data mode contract and an agent-friendly query envelope is exactly the kind of change that lands in those schemas, and agent code that hard-codes query shapes will feel it. On licensing, the repository metadata reports NOASSERTION and the README badge reports Apache-2.0. I cannot resolve that from the supplied material, and it is not a legal question I should answer for you. If you intend to redistribute UModel or embed it in a product, read the actual licence file in the repository and get your own advice. If you are only running it locally for evaluation, the practical exposure is lower but the ambiguity is still worth resolving before you build on it.
Editorial conclusion
Adopt UModel if you are building agent workflows that need a shared, queryable object graph over services, telemetry and business objects, and you are comfortable running a Go 1.22+ service locally with GRAPHSTORE=memory for evaluation. Do not adopt it as a production control plane, a multi-tenant authorization layer, or a replacement for your existing CMDB or observability backend, because the README explicitly places cloud-hosted control planes and multi-tenant authorization outside the public core. Before committing, verify three things: the actual licence text in the repository (the metadata says NOASSERTION while the README badge says Apache-2.0), whether your data sources can be expressed as EntitySets and links in a model pack, and whether the .umodel, .entity and .topo query surface covers the reads your agents need.
Community notes