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

Specifying the Delegated-Autonomy Boundary: Requirements Engineering for Agentic AI
Jul 19, 2026Chetan Arora, Andreas Vogelsang, Abbi SharmaAI Agent Safety AI Agent Governance
Faculty of IT, Monash University Melbourne, Victoria, Australia · University of Duisburg-Essen Essen, Germany
Beyond Accuracy: Disentangling Decomposition from Typed-State Quality Assurance in Multi-Agent LLM Pipelines
Oct 22, 2026Maria Gabriela Alves Zuppardo, Vinicius Cardoso GarciaMulti-Agent LLM Systems LLM Agent Evaluation
Centro de Informática, Universidade Federal de Pernambuco (UFPE), Recife, PE, Brazil
RAC: A Relational Agent Contract for Constraint-Governed Engineering Tasks
Oct 14, 2026Kaiyuan Zheng, Fengqing Jiang, Yichen Feng +6LLM Agent Reliability
University of Washington · Western Washington University · King Abdulaziz City for Science and Technology (KACST)

Jul 19, 2026J/K move · Enter open · S save

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

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

Open paper AskPDF arXiv

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.

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