RAC: A Relational Agent Contract for Constraint-Governed Engineering Tasks · Kaiyuan Zheng, Fengqing Jiang, Yichen Feng, Zubin Aaron Assadian, Yuetai Li, Bhaskar Ramasubramanian, Basel Alomair, Luyao Niu and Radha Poovendran, University of Washington and collaborators · arXiv, October 2026
A University of Washington paper reports that the agent-tool contract moved PCB pass rates more than model choice did
Machine-readable
Download Markdown
The authors propose a contract for the tools a harness exposes. The agent states what the artifact should satisfy as relations among named objects, such as "C1 close to U1", and never writes coordinates. Specialized tools derive the geometry, an independent checker verifies the result, and failed checks return repair evidence that names the conflicting relations. It needs no retraining.
On 98 printed circuit board tasks across six seeds and nine models, the paper reports a mean clean-pass rate of 90.9% for this contract. Direct coordinate generation averaged 23.2%, and adding a Python sandbox did not help (21.0%). The strongest baseline, handing the tools only the requirements, reached 74.0%. In job-shop scheduling on 30 public instances, relational actions passed quality checks 96.3% of the time against 59.6% when the agent returned code against the same scheduling backend. The authors also report lower token use for eight of nine models on the PCB tasks.
The model gap was smaller than the interface gap. Under the contract, eight of nine models landed between 89.8% and 95.9%, above the best any model reached with any baseline, and Claude-Opus-4.8 (91.8%) edged out Claude-Opus-5 (89.8%). The result held when two GPT-5.6 models ran inside Codex, Claude Code and OpenCode, where clean-pass rates stayed between 91.8% and 95.9% and the harnesses differed mainly in token cost. The authors state the limit themselves: it only applies where a deterministic realizer and an independent checker exist or can be built, and requirements that cannot be written as checkable predicates fall outside it. These are the authors' own benchmarks, and we did not read the appendices, including the embedded-code evaluation on 141 tasks.
Why it matters: The tasks are hardware and scheduling, not application code, so the numbers do not transfer directly to a software factory. The design lesson does: where an agent can state intent and a tool can compute and independently check the consequences, take the derivation off the agent. That is a harness decision you can make before you change models.