Semantic Models ≠ Live State: Why Agents Need Object Runtime

The previous article discussed how ontology Actions connect decisions, permissions, and real business systems through action contracts, with a key requirement: before executing an action, the object's current state and data version must be re-verified. This raises the question: where does this "current state" come from?

A semantic model can define what customers, contracts, receivables, and disputes are, their relationships, and allowed states. However, it does not automatically store the current outstanding receivables, grace periods, dispute status, and credit limits for a specific customer like CUS-001. These facts are typically scattered across CRM, contract, receivables, and complaint systems, updating at different frequencies.

If an Agent only reads the semantic model, it knows the meaning of objects, states, and rules but not what is actually happening now. If it directly reads multiple source systems each time, it must itself understand object identity, field meanings, update times, and state conflicts.

Semantic models define "how the business world is understood"; object runtime answers "within explicit time, version, and evidence boundaries, what is the current state of this specific object?"

Semantic Models Answer Definition Questions; Object Runtime Answers Instance Questions

The "customer" in a semantic model is a class of business objects. The model can define:

Customer attributes and identifiers

Relationships between customers, contracts, receivables, and disputes

Meaning of states like credit-normal, warning, and restricted

Events that may trigger state changes

Preconditions for credit-limit adjustments and what those conditions mean

Object runtime, by contrast, cares about a specific customer instance:

What outstanding receivables CUS-001 currently has

Maximum overdue days and when that was observed

Whether an accepted commercial dispute exists

Current credit limit and data version

Which system, record, and rule version each state comes from

Therefore, object runtime is not a larger ontology model. It is a runtime capability that organizes specific objects, current states, associated facts, business events, and action results under unified semantic constraints.

"Object runtime" is not a standardized industry product name. Here it refers to a class of architectural capability that can be composed from event streams, caches, search indexes, state projections, and object services — not necessarily built as a standalone product.

Borrowing the digital-twin concept, object runtime is like a "business object digital mirror for Agents": source business systems still store real records and bear transaction responsibility, while object runtime only organizes reconstructable state projections with time, version, and evidence. It resembles the state-mapping part of a digital twin but without physical simulation or device control.

It is also not a "fourth layer" beyond semantic, decision, and action layers. The three layers divide core business responsibilities; object runtime is an optional runtime capability that provides current object context and state feedback for those responsibilities.

"Current State" Is Not a Single Field Lookup

Many states are not pre-existing standard fields in source systems but are combinatorial results of multiple facts under specific times and rules.

For example, "customer is in credit-warning state" may simultaneously depend on:

Current outstanding amount and overdue days — authoritative source: receivables system; key time/version: receivables version, last posting time

Whether contract has a grace period — authoritative source: contract system; key time/version: contract version, clause effective time

Whether a dispute has been accepted — authoritative source: complaint/dispute system; key time/version: acceptance event time

Current credit rating and limit — authoritative source: CRM or credit system; key time/version: customer record version

Warning-state judgment criteria — authoritative source: decision rules or policies; key time/version: rule version and effective interval

If only credit_status = warning is returned, the Agent cannot know whether this state is the latest result or yesterday's cache; whether it was computed with new rules or an already-expired policy.

Therefore, a decision-usable state projection must at least retain:

Unified object identity and associated objects

Semantically interpreted current facts and derived states

Observation time, source data versions, and rule versions

Evidence and data-source references

Freshness, missing-data, conflict, and unknown-state markers

Object runtime does not provide "absolute real-time single truth" but a traceable object projection that explains "as of what time, based on which versions and evidence, this conclusion was drawn."

What Object Runtime Actually Manages

A usable object runtime typically assumes five responsibilities:

First, reference unified identity and associate object relationships. It must know whether the customer ID in CRM, the party ID in the contract system, and the payer ID in the receivables system refer to the same business object in the current scenario. This mapping should reference master data or confirmed identity rules, not be guessed by the Agent ad hoc.

Second, maintain reconstructable state projections. It can acquire facts via events, CDC, data services, or scheduled calibration, then organize them into a current view for queries and decisions under unified semantics. Even if the projection is lost, it must be rebuildable from source facts.

Third, record events and observed state transitions. The semantic model defines which state transitions are business-allowed; object runtime records which events and changes were actually observed for a specific object. If an illegal transition is observed, it should generate a quality or governance alert, not rewrite the source system.

Fourth, preserve time, version, evidence, and freshness. Object runtime must not expose only a latest value; it must also indicate when the value was observed, where it came from, whether it is stale, and how conflicts are handled. This is a prerequisite for explainable decisions and auditable actions.

Fifth, ingest action results and reflect manual corrections. After an action executes, object runtime should update the projection via business events or reconciliation results. Business-user corrections to state or object relationships must go back to the corresponding source system or governance process, then be reflected through the projection pipeline — not just "fixed" on the projection.

How It Differs from Data Platforms, Agent Runtime, and MCP

Object runtime is easily confused with data warehouses, master-data platforms, Agent Runtime, or semantic services. The following boundaries must be kept separate:

Ontology Semantic Layer — answers: what do objects, states, relationships, and events mean? — does not replace: real-time state of object instances.

Source Business Systems — answers: what are the source records and final transaction results? — does not replace: cross-system unified semantic view.

Data Platform — answers: how are historical and real-time data aggregated, analyzed, and reused? — does not replace: source business transactions and authoritative pre-action verification.

Master Data Platform — answers: how are core object identities and baseline attributes unified? — does not replace: process states, business events, and action results.

Object Runtime — answers: what state is a specific object in right now, and what are the evidence and freshness? — does not replace: source system's transaction authority.

Agent Runtime — answers: what step is the Agent task currently at? — does not replace: authoritative state of business objects.

MCP, API & Semantic Services — answers: how to discover, query, and invoke these capabilities? — does not replace: business state and transaction control.

The most critical distinction: a customer entering credit-warning is a business object state; an Agent generating a limit-adjustment proposal and awaiting human approval is an Agent task state. They can be correlated, even hosted on the same technical platform, but their semantics, lifecycles, and authoritative sources must be separated.

Complete Flow Through a Customer Limit-Adjustment Case

In the "identify overdue risk and adjust customer credit limit" scenario, object runtime does not directly modify the customer limit; it ensures decisions and actions receive a traceable current object view.

Receivables system emits "receivable overdue" event; contract system provides grace period and contract version; dispute system provides current acceptance status.

Object runtime maps these facts to the same customer and associated receivables, generating a customer risk projection with observation time, source versions, and evidence references.

Decision service forms a limit-adjustment proposal based on a specific projection version; the decision record references that projection version and the rules used.

Action request enters the action gateway; per the action contract, the system re-queries the customer limit in CRM and verifies key source facts (receivables, disputes, etc.). If the projection is stale or version-conflicted, it refreshes context first, then decides whether to proceed, re-decide, or re-obtain human confirmation based on whether changes affect the original decision.

CRM completes the real limit-adjustment transaction, returning external transaction ID and final data version. Object runtime updates the projection upon receiving the business event or completing reconciliation.

When monitoring detects event delays, sequence gaps, or ordering conflicts, affected projections are marked expired, conflicted, or unknown, and recovered via replay, source re-fetch, and reconciliation — never treating unconfirmed state as completed.

The core of this chain is not "copying a set of customer data" but enabling every decision to answer: what was seen at that time, which version was used, why this conclusion was drawn, and what was re-verified before execution.

Not Every Scenario Needs Object Runtime

If a scenario only reads a single business system, query frequency is low, and it does not depend on complex cross-system state, a semantic service that assembles object context on-demand per request is usually sufficient.

If the semantic service queries multiple source systems on every request to assemble current object context for the Agent, it resembles a business-semantics-constrained Agent BFF (Backend for Frontend) aggregation layer. When the system begins to continuously maintain state projections, handle event ordering, record versions, and support reconstruction and reconciliation, it has exceeded typical BFF duties and enters the object-runtime scope described here.

Consider building explicit object-runtime capability when:

A single object's current state frequently requires combining facts from multiple systems

Decisions are sensitive to latency, event ordering, and data freshness

Multiple Agents or business applications need to reuse the same unified object context

Tracking object state transitions and action execution results is required

Rebuilding the decision context at a historical point in time is needed

The build decision should not be "do we have an object-runtime product" but: does on-demand assembly fail to meet scenario requirements for timeliness, consistency, reusability, and traceability?

Start with a Minimal Object Projection

Object runtime is not suited to start with "sync all enterprise objects." A more practical path:

Pick a high-value scenario; clarify exactly which object states decisions and actions truly need.

Specify for each fact: source system, authority boundary, object identity, event time, and versioning mechanism.

Design only the minimal projection required for that scenario, and define freshness, missing-data, conflict, and degradation rules.

Combine events, CDC, API queries, caches, or indexes per existing system conditions, while preserving rebuild and reconciliation capabilities.

Publish object context via semantic API or MCP query tools, returning projection version, observation time, evidence, and freshness.

Have decision records reference the projection version; have state-change actions re-verify source systems before execution.

Validate projection reliability under event delays, duplicates, losses, reordering, source-data conflicts, and projection rebuilds.

Technically, object projections can land in relational databases, document stores, graph databases, search engines, or high-speed caches. The key is not which database is chosen, but whether projection boundaries, source facts, versions, freshness, rebuild, and transaction authority are clear.

To determine what a minimal object projection should contain, the project must first define which business questions the model must answer and how those questions are validated by data and results.

Summary

Semantic models let machines know what business objects are; object runtime lets machines know what state a specific object is in at a traceable point in time.

It organizes scattered current facts into a unified object context reusable by decisions and Agents, but does not thereby gain the source system's transaction authority. Honest expression of latency, conflicts, and unknown states is more important than giving an Agent a seemingly complete but unprovable "latest value."

Semantic models define "what an object means"; object runtime states "as of when, based on what evidence, this object is in what state"; source business systems still decide "what actually happened in the end."