A Contract-Centered Architecture for Scalable and M... | AI Research

A Contract-Centered Architecture for Scalable and Manageable Agentic Runtimes proposes a framework to address the coordination challenges of deploying enterprise AI. The authors, Yaxiao Liu, Pengbo Liu, Yiwen Liu, Yihua Guan, Zhenghe Hou, and Jiaxing Song, argue that current benchmarks fail to account for how organizational changes—such as updating models, infrastructure, or data governance—interact within a single agentic runtime. The paper introduces a contract-based architecture designed to make these dependencies explicit and testable.

The Four Responsibility Objects

The architecture organizes runtime components into four distinct "responsibility objects" to clarify ownership and change management:

• Skill: A versioned, reusable business capability or workflow asset owned by business product owners.

• Harness: The runtime compiler and governor that manages admission, composition, and evidence capture.

• Scaffold: The execution and control boundary, including physical resources and non-functional requirements (NFRs), managed by infrastructure and operations teams.

• Data Substrate: An external, CIO-governed infrastructure that provides semantic access, provenance, and telemetry independent of the runtime stack.
  By separating these objects, the authors aim to allow business units to update Skills without redesigning the infrastructure, and platform teams to scale Scaffold capacity without altering the meaning of business capabilities.

Testing Capability-Capacity Separability

The central scientific contribution is the hypothesis P1, termed "cost-aware capability-capacity separability." This hypothesis posits that within a specific operating region, a runtime can change activated capabilities without materially altering capacity-response interactions, and conversely, change Scaffold capacity without degrading capability semantics, all while keeping enforcement costs within a defined budget.
To test this, the authors propose a cluster-period randomized crossover experiment. This protocol uses balanced order, reset/washout periods, and repeated failure regimes to produce one of four verdicts: supported, falsified, conditional-engineering, or inconclusive.

Architectural Limitations

The authors explicitly state that this paper does not report any completed runtime implementation, experiment, dataset, or measured result. The work is presented as an architectural framework and a falsifiable measurement protocol rather than a report of empirical findings.
Franklin analysis: The paper’s value lies in its attempt to formalize the "deployment gap" in enterprise AI. By defining six design conditions as measured obligations, the authors provide a structured way to evaluate whether a system’s components are truly independent. However, because the paper provides no experimental data, the feasibility of achieving this separability in a production environment remains unproven.

Why This Matters

Enterprise AI deployment often involves multiple teams—ranging from security and data governance to SRE and application development—operating at different speeds. The authors argue that architecture can function as a shared organizational contract. By making the handoffs between these groups explicit, the framework seeks to prevent hidden dependencies where changes in one area, such as infrastructure, inadvertently break business logic or policy enforcement.