Contract-Based Agentic Systems Engineering: Delegation as Quotient for Assured System Design

Sai Sandeep Damera; Ryan Matheu; John S. Baras

eess.SYOct 23, 2026

Contract-Based Agentic Systems Engineering: Delegation as Quotient for Assured System Design

Authors: Sai Sandeep Damera, Ryan Matheu, John S. Baras

Organizations: Department of Electrical and Computer Engineering and the Institute for Systems Research, University of Maryland, College Park, MD 20742, USA

Abstract

A component an agent builds from a prompt can satisfy it and still break the system it joins, because the prompt omits what its neighbours assume of it. The artifact to hand over is computed, not written. A SysML v2 requirement with assumed and required constraints is an assume/guarantee contract, so when a system requirement is decomposed over fixed neighbours, the open component's requirement is the contract quotient, the weakest sound one, and again a SysML v2 requirement. Its required constraints carry the neighbours' assumptions, which a requirement for the mission alone drops and unit tests with mocked neighbours cannot reach. Signal Temporal Logic is closed under the quotient. We build the requirements, with derivation, allocation, satisfaction and verification, as a SysML~v2 model and compute the quotient from it. A case study delegates the local controller of a simulated warehouse robot, whose route crosses a worker's path and ends at a dock, to one language model under the quotient requirement, a mission-only requirement and a natural-language task, and scores the deliveries on live episodes against the system requirement from ground truth.

Figures & tables

Figure 1: The C-BASE architecture. The orchestrator agent is responsible for contact organization and delegation. A delegate contract is computed via the quotient operation and the unimplemented behavior is then shipped as a work order to the design agent. A candidate component is then subject to verification. Upon satisfaction of the local behaviors derived from the quotient contract, a candidate component is integrated into the system. If the overall system with the delegated component satisfies the system-level contract, it is accepted into the overall system design.

Figure 2: (a) Since the most recent observation, reported with error

e_{\mathrm{p}}

, the robot has moved by up to

\delta_{\mathrm{r}}+s_{\mathrm{r}}

and the person’s nearest point has closed in by up to

\delta_{\mathrm{p}}+v_{\mathrm{a}}\,\mathrm{age}

, so the true clearance

c_{\mathrm{true}}

can breach 0.40 m while the reported

c_{\mathrm{rep}}

does not. (b) The controller relies on perception, localization and the drive, and each of them assumes a bound on the yaw rate the controller commands.

Symbol	Meaning	Symbol	Meaning
$c_{\mathrm{true}}$	true clearance now, robot body to nearest point of the person’s body; $c_{\mathrm{true}}^{+}$ its smallest value up to the next tick	$c_{0}$	required clearance
$c_{\mathrm{stamp}}$	true clearance at the observation time of the report in hand	$\delta_{\mathrm{r}}$ , $\delta_{\mathrm{p}}$	tolerances of the drive’s displacement and of the person’s closing
$c_{\mathrm{rep}}$	reported clearance, to the nearest reported person point	$v_{\mathrm{a}}$	closing speed of the person’s body
$\mathrm{age}$	time since the observation in hand was measured; $\mathrm{gap}$ the time from the tick to the next control tick	$\|v\|$ , $\|w\|$	magnitudes of the commanded speed and yaw rate ( v , w in the listings)
$e_{\mathrm{p}}$	bound on $c_{\mathrm{rep}}-c_{\mathrm{stamp}}$ in view, the perception error	$e_{\mathrm{loc}}$ , $e_{\mathrm{yaw}}$	position and heading error of the pose estimate
$s_{\mathrm{r}}$	largest commanded speed in effect over the age and the drive’s 0.15 s lag before it, times the age; $s_{\mathrm{r}}^{+}$ the same with the age counted to the next tick	$g$ , $y$	distance and heading error to the dock, true or estimated ( $g_{\mathrm{true}}$ , $g_{\mathrm{est}}$ ; g_est in the listings)

Table 1: Notation of the case study. Signals are read at a control tick; lengths in m, times in s, rates in m/s and rad/s.

Figure 3: The requirements of the case study’s architecture model. Stakeholders and their concerns frame the robot’s specification. Derivations run from the system requirement to the three fixed components’ contracts and to the requirement dispatched to the controller slot, which strengthens the quotient ( Definition 4.10 ). Each requirement is allocated to and satisfied by a part, and the verification case of the quotient condition verifies the dispatched requirement, with its result item holding the verdicts.

Clause	Bound	Set by
System $\mathcal{C}_{\mathrm{sys}}$ assumes
approach	$k_{\mathrm{ext}}\leq 0.02+1.5\,\mathrm{age}$ and $k_{\mathrm{ext}}^{+}\leq 0.02+1.5\,(\mathrm{age}+\mathrm{gap})$	largest limb closing measured, 1.385 m/s
blind side	nobody within 0.40 out of view, now and to the next tick	the camera’s field of view
frames	a scan and a people record every 0.5	sensor rates
walk	crosses once, within 0.72 of its segment, back at most 0.72	the drawn walks
route	the route 1.4 from mapped surfaces	the warehouse layout

Table 2: The contracts of the case study, one clause per row, with the mechanism that sets each bound. Notation as in Table 1 ; lengths in m, times in s, rates in m/s and rad/s. The architecture model names

\mathcal{C}_{\mathrm{P}}

\mathcal{C}_{\mathrm{L}}

and

\mathcal{C}_{\mathrm{D}}

PerceptionContract , LocalizationContract and PlantContract ; they are the fixed components’ contracts

\mathcal{C}_{i}

of Section 4 .

Delivery	Admitted by its own harness	Safe at the bounds	Live, 30 standard	Live, at the edge	Closest
agent, derived requirement	yes	yes	30 of 30	4 of 4	1.42 m
agent, mission-only	yes	yes	30 of 30	not run	1.57 m
agent, mission-only, resampled	yes	no, breaks 8 of 482	30 of 30	16 of 22	0.14 m
agent, natural language	yes, by its own scoring	yes	30 of 30	not run	1.22 m
reference, hand-written	yes, under all three	yes	30 of 30	not run	1.56 m
witness, written to the mission-only letter	yes, by the first mission-only harness	no	0 of 30	not run	contact in 29

Table 3: The deliveries and the controls. Admission is by the harness of each delivery’s own condition. A design is safe at the bounds when it keeps the system requirement with the fixed components at their contract bounds. The live columns count the episodes in which the system requirement held on the truth, over the 30 standard scenarios and at the setting of Section 6.5 where the neighbors work at the edge of their contracts, and the last column gives the closest the robot came to the worker in any episode.

Figure 4: The three deliveries live on one draw at the setting of Section 6.5 , one row per delivery and four frames matched by the walker’s progress, from a run recorded for this figure and outside the counts of the text. In the two middle frames the evaluator’s geometry is drawn into the camera view: the robot’s body disc, the required 0.40 m clearance as the dashed circle, the walker’s nearest body point with the clearance to it, and the robot’s positions over the preceding 5 s. The deliveries selected under the derived requirement and under the natural-language task stopped before the walker stepped out, 1.47 m and 1.25 m from her at the closest. The mission-only delivery drove on for three more seconds and stopped 1.27 m further along, in her path; at the closest approach her foot lies inside the circle, 0.25 m in the frame and 0.22 m between frames, the one red mark of the figure.

Variant	Changed bound	GT	Q	D	M
as declared	age 0.40 s, rest error 0.05 m	24	24	12	120
slower perception	age 0.80 s	12	12	0	120
faster perception	age 0.20 s	24	24	12	120
coarser map	rest error 0.20 m	0	0	0	120

Table 4: The 288 governors without a memory admitted as one fixed component’s contract changes, on the first harness of 98 scenarios. GT counts the governors that keep the system requirement with the fixed components at the variant’s bounds, Q those the quotient

\mathcal{C}_{\mathrm{q}}

admits and D those the dispatched requirement admits, both at those bounds, and M those the mission-only requirement admits against ideal neighbors, which do not change.

Requirements Engineering

Requirements engineering studies how stakeholder needs are elicited, specified, analyzed, validated, and traced into dependable systems.

See all 60 papers

Jul 19, 2026

Specifying the Delegated-Autonomy Boundary: Requirements Engineering for Agentic AI

Agentic AI systems do not just predict or recommend; they plan, maintain state, and act in external environments with varying degrees of autonomy. This changes the requirements engineering problem in a specific and under-addressed way: it introduces what we call the delegated-autonomy boundary -- the set of decisions about what may be delegated to the system, under what graduated authority, with what oversight, and how control is returned. Current practices bury these decisions inside prompts, tool schemas, and runtime policies, even though they are requirements-level commitments. This paper proposes two complementary artifacts. First, an Agency Justification Record (AJR) helps teams decide when an agent is warranted over simpler alternatives. Second, an Agentic Delegation Policy (ADP) captures what must be specified for safe and effective development: purpose, authority, information, coordination, assurance, and evolution. Crucially, authority in the ADP is modelled as graduated, i.e., a tiered structure. We illustrate the framework with two contrasting examples: a safety-critical hospital discharge coordination agent and an automated code review agent.

Chetan Arora, Andreas Vogelsang, Abbi Sharma

Faculty of IT, Monash University Melbourne, Victoria, Australia · University of Duisburg-Essen Essen, Germany

AI Agent Safety AI Agent Governance

Ask PDF

Oct 22, 2026

Beyond Accuracy: Disentangling Decomposition from Typed-State Quality Assurance in Multi-Agent LLM Pipelines

Multi-agent LLM pipelines are often credited with gains in software engineering tasks, but it is rarely clear whether a gain stems from the typed contract between agents or from the specialized prompts that decomposition enables. We study this attribution problem in Requirements Engineering, comparing three architectures for classifying requirements as functional or non-functional and then prioritizing them with MoSCoW: a single-call baseline; a two-call variant that reuses the pipeline's specialized prompts but passes an unvalidated intermediate; and a pipeline with a Pydantic-validated typed state. The 18 conditions cover PROMISE NFR+ (625 requirements), three locally hosted small language models, and two languages. The F1 gain over the baseline is associated with the two-call, specialized-prompt variant (up to +0.075), whereas the typed state adds a small difference (-0.003 to +0.013) that is significant in one of six comparisons. Beyond accuracy, the typed pipeline contains out-of-range model outputs at the agent boundary, while the unvalidated variant fails later and drops the requirement, and it shows a small, reproducible increase in inter-model MoSCoW consistency whose cause our design cannot isolate. The study is associative: the contrasts bundle prompts, call count, and staged context, and the results come from three 7--8B models on one dataset. The implementation and replication package are archived on Zenodo (https://doi.org/10.5281/zenodo.23380444).

Maria Gabriela Alves Zuppardo, Vinicius Cardoso Garcia

Centro de Informática, Universidade Federal de Pernambuco (UFPE), Recife, PE, Brazil

Multi-Agent LLM Systems LLM Agent Evaluation LLM Agent Verification Requirements Engineering

Ask PDF

Oct 14, 2026

RAC: A Relational Agent Contract for Constraint-Governed Engineering Tasks

Engineering agents must produce artifacts that satisfy exact, coupled constraints. Existing solutions often require agents to make semantic decisions and also derive consequences such as precise geometry or timing from those decisions, leading to failures in constraint-governed engineering tasks. In this paper, we introduce RAC, a harness-agnostic contract for the action and feedback layer of engineering agents. It specifies authoritative observations, semantic actions, tool-based realization, independent verification, and repair evidence. The agent decides which relations an artifact should satisfy; specialized tools derive their concrete consequences. On PCB placement, routing, and repair tasks, RAC achieves the highest clean-pass rate for all nine evaluated models, averaging 90.9%, compared with 74.0% for the strongest baseline, requirements-only delegation. In job-shop scheduling, direct relational actions achieve 96.3% quality pass versus 59.6% for code-mediated delivery with access to the same scheduling backend. Our evaluations on 141 embedded-code tasks across four microcontroller identify the action contract as a source of agent capability: preserving semantic control while delegating mechanically derivable outputs improves the reliability of constrained artifacts.

Kaiyuan Zheng, Fengqing Jiang, Yichen Feng +6

University of Washington · Western Washington University · King Abdulaziz City for Science and Technology (KACST)

LLM Agent Reliability

Ask PDF

Abstract

Requirements Engineering

Explore similar work

Specifying the Delegated-Autonomy Boundary: Requirements Engineering for Agentic AI

Beyond Accuracy: Disentangling Decomposition from Typed-State Quality Assurance in Multi-Agent LLM Pipelines

RAC: A Relational Agent Contract for Constraint-Governed Engineering Tasks