cs.AIAug 27, 2026
SaveA Contract-Centered Architecture for Scalable and Manageable Agentic Runtimes
Organizations: PwC China AI Center
Abstract
Enterprise agentic systems must coordinate changing capabilities, execution capacity, and independently governed data. We define Skill, Harness, Scaffold, and an external data substrate as responsibility contracts. The central hypothesis, cost-aware capability-capacity separability, asks whether compatible capacity changes preserve semantic outcomes while capability changes preserve the capacity-response relationship within declared margins and enforcement budgets. We operationalize the data boundary through a source-oriented Data Wiki, an output-oriented Theme Wiki, and a versioned Intermediate Relation. Executable 5W1H+Which predicates bind source identity, validity, authorization, semantics, operations, relations, and evidence requirements. Request-bound tickets add execution-time revalidation and typed rejection. A conditional soundness argument states the required trust and atomicity assumptions; dependency invalidation makes change propagation explicit. A single-process reference model agrees with a declared specification oracle on all 1,024 combinations in a finite synthetic fault domain and passes five lifecycle checks. These are conformance results, not measurements of retrieval quality, production safety, or scaling. We specify a held-out data study and a cluster-period crossover with distinct supported, falsified, conditional-engineering, and inconclusive verdicts. The core separability hypothesis remains empirically untested.
Figures & tables
Figure 1: Shown: business capability enters as a versioned Skill contract, the Harness admits and binds an activated path, the Scaffold supplies the execution and control boundary, and the CIO-governed semantic and telemetry substrate remains stack-external; any derived index or summary in that substrate is discovery metadata rather than source authority. Why it matters: the diagram separates the two interventions whose independence P1 tests and identifies the boundary at which recoupling and enforcement cost must be observed. Class: architecture.
| Object | Primary enterprise owner | Typical change cadence | Stable contract |
|---|---|---|---|
| Skill | Business product owner with AI/automation developers | Hours to weeks | Goal, typed I/O, effects, tests, evidence, version |
| Harness | AI platform/runtime and governance teams | Days to months | Admission, activated path, effects, binding constraints, postconditions, trace |
| Scaffold | Enterprise platform, cloud/server-farm, SRE, security, and operations | Weeks to years | Resource, isolation, locality, identity, attestation, execution |
| Data substrate | CIO/data authority with domain data stewards | Weeks to years | Semantic access, provenance, routing, lifecycle, intermediate representation |
Table 1: Enterprise ownership, typical change cadence, and stable contract. One team may implement multiple objects, but their decision rights, stable contracts, and evidence responsibilities remain distinguishable.
| Boundary | Business semantics | Runtime governance | Physical execution | Enterprise data |
|---|---|---|---|---|
| Skill | owns | declares requirements | does not own | consumes governed contracts |
| Harness | compiles activated capability | owns | binds but does not supply | mediates access and evidence |
| Scaffold | does not interpret | exposes enforceable facts | owns | enforces locality and network boundary |
| Data substrate | preserves domain meaning | supplies policy/provenance facts | does not schedule | owns semantic integration and routing |
Table 2: Responsibility boundaries in the proposed architecture. The table defines handoffs and non-ownership; it is not a completeness rating of products or organizations.
| Object | Claim type | Scoped claim | Evidence status |
|---|---|---|---|
| Enterprise-runtime responsibility architecture | Design proposal | Four responsibility objects separate business capability, runtime governance, execution/NFR ownership, and enterprise data governance through stable contracts and change cadence | Architectural synthesis; narrow data-boundary reference model only; no full runtime or adoption validation |
| Shared organizational contract | Interpretive thesis | Architecture makes communication, ownership, change cadence, and evidence obligations explicit across enterprise groups | Definitional framing choice of this paper, not a testable prediction; adoption value unevaluated |
| P1 | Proposition | Cost-aware capability-capacity separability inside | Analytic argument; proposed experiment (§ 10 ) |
| Path safety / mediation | Proposition | Complete mediation enables path-level admission checks | Analytic argument; cited external evidence; proposed experiment (§ 11 ) |
| P15 | Hypothesis | Output-plus-process gates improve discrimination, attribution, or training | Cited external evidence; proposed experiment (§ 11 ) |
| P16 | Hypothesis | A pinned address/index policy with source fallback supports task-family reconstruction | Proposed experiment (§ 11 ) |
Table 3: Claim types and evidence status. “Proposed experiment” denotes a protocol, not a completed study in this paper. The first two rows are definitional and interpretive choices rather than testable claims; for them the relevant question is whether the distinctions are useful and consistently applied, not whether an experiment confirms them.
| Evidence plane | Primary decision question | Representative evidence | Does not establish |
|---|---|---|---|
| Business/use-case | Does the versioned Skill produce the intended business outcome for its declared users and workflow? | Task and requirement completion, output quality, cycle time, human correction, adoption, and outcome-specific benefit or loss | Runtime admission integrity, isolation, capacity, availability, portability, or cost behavior |
| System/runtime | Does the admitted path execute within its declared contract and enterprise NFR envelope? | Gate and trace integrity, path and effect conformance, throughput, active-agent capacity, latency, saturation, failures, isolation, availability, backpressure, and cost | Usefulness, workflow fit, user acceptance, or business value |
Table 4: Two required evidence planes for enterprise adoption. Each plane answers a different decision question; neither plane substitutes for the other.
Figure 2: Shown: a request and activated bundle pass deterministic admission gates to become a resolved Harness contract with typed data, path, authority, budgets, versions, binding, and trace identity. Why it matters: the contract is the inspectable unit on which complete mediation, replay, and capability-to-capacity binding are tested. Class: architecture.
Figure 3: Shown: the control plane holds the registry, policy, admission, and placement logic, while the data plane receives only the resolved contract and executes accepted work; the leaking variant injects every schema and policy into the request path. Why it matters: keeping inactive registry state and mutable control metadata off the request path limits unmeasured coupling between capability growth and runtime load. Class: architecture.
Figure 4: Shown: a main agent derives bounded sub-agents for unmet dependencies, then a separate verifier or semantic join checks their returned evidence before a termination gate closes the path. Why it matters: capability expansion during a run remains a sequence of admitted contracts rather than an invisible increase in ambient authority. Class: protocol.
Figure 5: Shown: logical control validates and binds a graph, physical execution runs it in compatible isolation and locality zones, and an evidence path records both decisions and effects; the vertical links are illustrative, potentially many-to-many contract mappings rather than a one-to-one logical-to-physical correspondence. Why it matters: placement optimization remains distinguishable from semantic policy while still exposing the resource channels that could recouple capability and capacity. Class: architecture.
Figure 6: Shown: the data authority resolves a semantic request into a governed contract, the Scaffold performs an isolated fetch, and the run receives an evidence bundle rather than source credentials; the figure’s shorthand means that no undeclared task semantics or credentials cross the boundary, while declared request fields and evidence obligations necessarily do. Why it matters: data policy and snapshot identity remain fixed experimental inputs instead of hidden properties of the capability or capacity treatment. Class: architecture.
Figure 7: Shown: a Skill moves through versioned validation, staged activation, monitored release, rollback, and retirement, with evidence attached to each transition and a freeze step where a converged Skill becomes code. Why it matters: the experiment can identify the capability configuration precisely and can repeat or reverse an intervention without conflating it with registry churn. Class: protocol.
| Hypothesis | Intervention and control | Evidence plane | Falsification or inconclusive condition |
| P1 (primary): capability Scaffold separability | Cluster-period randomized crossover. Independently vary activated capability configuration and Scaffold capacity configuration ; hold workload and data snapshot fixed; preregister reset or washout. | Semantic outcome ; runtime response ; enforcement overhead ; six condition-violation rates; cluster-aware uncertainty; capability-by-Scaffold interaction estimand. | Insufficient evidence: inconclusive. Clearly violated obligations: conditional-engineering. Only after all obligation gates pass, resolve runtime interaction, semantic non-inferiority, and cost bounds as supported, falsified, or inconclusive. |
| P15: vector gate | proposal-bank contrasts | – | margin failure or phantom violation |
| P16: evidence-path sufficiency | held-out joint contrast | – | direct-reading control wins |
| P17: policy-contract decoupling | dependency-change oracle | – | unanticipated propagation |
Figure 8: Shown: P1 maps to cluster-period interventions on capability and capacity, six measured obligations, semantic and runtime estimands, enforcement cost, and the conditions distinguishing supported, falsified, conditional-engineering, and inconclusive verdicts. Why it matters: the matrix ties every architectural claim to an observation and prevents missing coverage or low power from being reported as separability. Class: proposed measurement design.
More in this topic
Runtime Enforcement for AI Agents
Runtime enforcement for AI agents checks and constrains actions as they execute, helping prevent unsafe or unauthorized effects.
See all 279 papers