Machine-Readable Task Contracts for Autonomous Multi-Agent Workflows: Architecting Deterministic Agreement and Resource Governance

Full report

On this page

The deployment of autonomous Large Language Model (LLM) agents introduces a fundamental governance challenge: the shift from human-supervised, chat-based assistance to machine-mediated economic interaction requires verifiable, deterministic boundaries. In late 2025, an engineering team deployed a multi-agent system consisting of four specialized research agents; lacking real-time cost monitoring or bounded stop conditions, two agents fell into a recursive clarification loop that ran undetected for eleven days, accruing a \$47,000 API overage1. Such failures are not merely implementation bugs but reflect systemic gaps in resource governance and state transition verification1. As autonomous systems become capable of executing complex workflows spanning hours or days across live platforms, the protocols governing them must extend beyond connectivity to address explicit, machine-readable task contracts1. Industry projections indicate the severity of this structural deficit. Research suggests that over 40% of agentic AI projects will be canceled by 2027 due to escalating costs or inadequate risk controls, even as agentic AI is projected to appear in 33% of enterprise software by 20281. The tension between supervision and autonomy remains a core challenge requiring centralized governance infrastructure1. The foundational problem lies in designing a minimum task contract that allows entirely unrelated, potentially untrusted agents to establish mutual consensus on what constitutes useful, completed work, without conflating the transport protocol with economic acceptance1. This report defines a formalized framework for machine-readable work contracts, contrasting legacy workflow standards with modern autonomous agent requirements, and proposes an exhaustive schema capable of governing inputs, acceptance criteria, resource delegation, failure compensations, and dynamic scope amendments.

Comparative Analysis of Documented Workflow Contracts and Standards

The infrastructure required for machine-native trust must bridge two fundamentally different computational paradigms: adaptive, off-chain LLM agents that reason probabilistically under uncertainty, and deterministic, rule-based institutional systems that execute strictly according to formal constraints3. Existing standards approach this divide from fragmented perspectives, providing either rigid deterministic pipelines or unconstrained communication protocols. An effective machine-readable task contract must synthesize these disparate approaches into a unified governance model.

The Contract Net Protocol and Multi-Agent Coordination

The FIPA Contract Net Protocol (CNP), introduced in 1980, formalized a task-sharing mechanism utilizing a call-for-proposals auction where a manager agent assigns tasks to contractor agents4. While CNP excels at task distribution and load balancing within cooperative networks where objectives are aligned, it lacks native constructs for bounding resource consumption or verifying non-deterministic LLM outputs4. When agents are competitive, CNP evolves into a marketplace organization similar to sealed auctions, but it fundamentally assumes that the message transport layer constitutes the agreement4. Modern theoretical extensions, such as the formal "Agent Contracts" framework, redefine the contract as a strict formal tuple [Figure omitted from source export]1. This approach unifies input/output specifications, multi-dimensional resource constraints, temporal boundaries, and success criteria into a coherent governance mechanism1. Crucially, this framework introduces conservation laws for multi-agent systems, ensuring that budgets delegated to sub-agents never exceed the parent agent's constraints1. This enforces strict fiscal discipline across hierarchical delegations, answering the critical question of "within what bounds may this task be performed?" rather than merely "who should do this task?"1.

Integration Protocols and Schema Definitions

The Model Context Protocol (MCP), standardized by late 2024 and maintained as an open-source specification, provides a robust JSON-RPC 2.0 framework for agents to discover and invoke external tools6. MCP treats JSON Schema 2020-12 as the definitive "contract for context," standardizing how language models interact with resources, prompts, and tools6. However, MCP functions strictly as a boundary layer and a transport protocol; it deliberately omits operational governance10. MCP does not dictate timeouts, budget propagation, stateful error recovery, or authorization enforcement, leaving these critical system-design decisions to the host application8. Field observations indicate that while MCP facilitates rapid tool integration, relying solely on its transport mechanisms for task delegation is insufficient for economic acceptance8. It cannot enforce Service Level Agreement (SLA) style penalties, manage stateful execution bounds, or provide cryptographic finality for completed milestones8. Similarly, the Common Workflow Language (CWL) provides a highly extensible, vendor-neutral standard for defining inputs, outputs, requirements, and hints in data-intensive scientific pipelines12. While rigorously typed, CWL relies on a static, directed acyclic graph (DAG) execution model optimized for shared-nothing clusters and containerized environments14. Autonomous LLM agents, which generate dynamic plans, engage in recursive reasoning, and may loop unpredictably based on environmental feedback, cannot be constrained solely by CWL's rigid, pre-compiled pipeline semantics3.

Cryptographic Intent and Decentralized Escrow

Web3 smart contracts provide the necessary infrastructure for trustless escrow and settlement, shifting the architecture of trust from centralized intermediaries to deterministic protocol layers16. However, bridging off-chain agentic reasoning with on-chain deterministic settlement requires a standardized translation mechanism. EIP-712 serves this exact purpose by defining an Ethereum standard for hashing and signing typed structured data18. Before EIP-712, off-chain message signing involved opaque hexadecimal strings, leading to significant vulnerabilities including replay attacks and blind-signing exploitation18. EIP-712 introduces a deterministic encoding mechanism featuring a domain separator, which explicitly binds a signature to a specific application, chain, and verifying contract18. This enables "clear signing," where the payload is parsed into a human-readable and machine-verifiable JSON format20. This cryptographic finality is essential for binding an autonomous agent to a contract amendment, verifying intent, or securing a milestone approval without relying on silent, unaccountable state mutations22.

Architecting the Minimum Task Contract

To establish a minimum task contract that prevents unconstrained execution while allowing for probabilistic reasoning, the architecture must strictly isolate deterministic boundaries from non-deterministic execution. A fully mature contract must govern the entire lifecycle of a task, from input parsing to termination conditions, ensuring that both parties agree on the precise definition of completion before any computational resources are expended.

Inputs, Output Schemas, and Schema Evolution

The contract must define inputs and outputs utilizing strict typed schemas, explicitly declaring required fields, dimensional bounds (e.g., maximum string lengths, enumerated arrays), and formatting rules9. JSON Schema 2020-12 provides the necessary vocabulary to enforce these boundaries, ensuring the LLM cannot inject unstructured, hallucinated data into downstream systems9. However, schemas in live operational environments are rarely static. As multi-step workflows progress, output-schema evolution becomes a practical necessity. Schema evolution must be strictly governed by Semantic Versioning (SemVer) principles to maintain data integrity24. For instance, a MINOR version update may introduce new, optional data fields into the output requirement while maintaining strict backward compatibility with the existing validation logic and historical data24. Crucially, changes to the output schema that affect the fundamental scope of work must not be processed implicitly by the executing agent. If an agent discovers that a dependency requires a non-backward-compatible schema shift (a MAJOR version change), this discovery must trigger an explicit contract amendment process. The executing agent's runtime environment must unconditionally reject any output that conforms to an unapproved schema variation, preventing the silent injection of extraneous data or the omission of required contractual deliverables.

Objective Acceptance Tests and Evidence Requirements

Acceptance criteria must be strictly partitioned into three distinct validation modes, as autonomous systems cannot uniformly rely on single-axis verification. The conflation of these modes often leads to catastrophic validation bypasses.

1. Deterministic Acceptance: This encompasses purely programmatic evaluations that leave no room for interpretation. It involves validating the final output against the strict JSON schema, matching expected SHA-256 cryptographic digests, and ensuring absolute adherence to "observation contracts"26. An observation contract is defined as a tool-returned artifact whose later use is constrained by the external system that produced it, governed by two orthogonal constraints: temporal validity and byte-level integrity2. Temporal validity requires the agent to utilize artifacts like presigned AWS S3 URLs or rate-limit windows before their virtual-clock time-to-live expires2. Byte-level integrity requires the agent to relay artifacts, such as OAuth state parameters, Cross-Site Request Forgery (CSRF) tokens, or HMAC-protected webhooks, without corrupting a single character through the observation-to-action pipeline2. ContractBench research demonstrates that even frontier models frequently fail observation contracts, suffering from integrity failures by re-encoding reserved characters or validity failures by missing strict deadlines2. Deterministic acceptance must automatically fail any result that breaches these byte-exact and temporal parameters, regardless of the narrative quality of the output.

2. Probabilistic Evaluation: For tasks requiring qualitative reasoning, such as research synthesis, tone-matching, or strategic planning, deterministic tests are inherently insufficient. Probabilistic evaluation involves utilizing LLM-as-a-judge mechanisms guided by explicit, highly structured rubrics. To mitigate the well-documented risks of sycophancy, cascading hallucinations, or models learning to deceive their watchers, probabilistic evaluation must be treated as a soft gate26. It verifies semantic relevance but must be combined with deterministic checks. To ensure reliability, probabilistic evaluations must account for behavioral drift bounds, utilizing frameworks that calculate recovery rates to ensure that non-deterministic agents do not drift beyond acceptable qualitative thresholds over extended operational sessions30.

3. Authorized Reviewer Judgment: Critical decisions, such as the final release of funds from a high-value escrow, the initiation of a destructive external action, or the deployment of code to a production environment, must remain with a named human or an authorized cryptographic identity31. This is achieved using EIP-712 structured signatures, where the reviewer explicitly signs the validation payload, confirming acceptance based on contextual human judgment rather than algorithmic assumption18. This mechanism ensures that legal and operational liability remains anchored to a verified entity.

Evidence requirements for these tests necessitate the submission of complete, auditable execution traces. The agent must yield an immutable log of its tool calls, API responses, generated plans, and intermediate states33. To prevent trace forgery or retroactive alteration, traces must be hashed into a Merkle tree structure, allowing the verifying entity to probabilistically or exhaustively audit the execution pathway and prove that the agent arrived at the correct answer through authorized means.

Dependencies, Deadlines, and Permitted External Actions

An agent's operational freedom must be explicitly bounded to prevent unbounded recursive loops. A contract defines its temporal bounds through hard deadlines, often driven by a virtual clock synchronized with the execution environment, establishing explicit Time-To-Live (TTL) parameters for the entire session2. Dependencies in networked environments are inherently fragile. If a critical dependency becomes unavailable—for instance, a target API goes offline for scheduled maintenance or returns repeated HTTP 429 Rate Limit errors—the contract must stipulate a dynamic timeout budget allocation8. Utilizing algorithms like Adaptive Timeout Budget Allocation (ATBA), the system distributes planner timeout budgets across sequential tool chains, preventing the agent from infinitely retrying a dead endpoint and consuming its entire token budget in a futile loop8. Permitted external actions cannot be governed merely by providing a list of available tools; they require a rigorous behavioral contract. Recent advancements formulate this through Linear Temporal Logic over Finite Traces (LTLf)33. Using frameworks like ContrAgent, assume-guarantee contracts are compiled into Deterministic Finite Automata (DFA) that gate agent actions in real-time33. For example, a DFA can enforce a strict temporal sequence: an agent is programmatically prohibited from executing a deploy\_code tool unless a run\_tests tool returned a positive exit code within the preceding three trace steps33. This symbolic temporal supervision acts as a runtime shield, deterministically preventing agents from hallucinating unauthorized control flows or bypassing required security protocols33.

Attempt Versus Completion Compensation

A fundamental economic distinction must be explicitly defined within the contract: the difference between attempt-based compensation and completion-based compensation. The failure to separate these concepts leads to misaligned incentives and disputed settlements. Attempt-Based Compensation (Compute Provisioning): When an autonomous agent executes a task, it natively consumes computational resources, including LLM inference tokens, vector database queries, and external API calls1. Compute providers require compensation for the attempt, regardless of the ultimate success of the task, functionally similar to gas fees on the Ethereum network18. If a multistep operation spans multiple distributed services and encounters a fatal error midway, the system must utilize the Saga design pattern to execute compensating actions38. Sagas manage long-running distributed transactions by ensuring that if forward progress fails, a predefined sequence of compensating actions undoes previous state changes to maintain system consistency38. For example, if an agent provisions a costly cloud database but fails to migrate the data, the compensating action automatically issues a teardown command to un-reserve the infrastructure38. The final cost of the computational attempt, plus the token cost of executing the required Saga compensating actions, constitutes the attempt-based compensation. Completion-Based Compensation (Economic Acceptance): Conversely, the task originator (the principal) only provides the primary economic compensation for the actual completion of the useful, verifiable work39. This is managed via an escrow contract. Funds are locked cryptographically upon contract initialization and are only released when the deterministic, probabilistic, or authorized reviewer acceptance tests resolve successfully17. This creates a trustless environment where the principal is guaranteed the deliverable before payment is released, while the executor is guaranteed payment upon verifiable completion39.

Verification Responsibility and Termination Conditions

Verification responsibility must fall upon an independent oracle network, a designated verifier agent, or an authorized human, entirely distinct from the execution agent40. This separation of duties ensures that the executing agent cannot grade its own homework, manipulate the DFA trace validation, or spoof API success codes. Termination conditions must be absolute and non-negotiable. An agent contract terminates under three primary conditions: successful verification of the output schema and trace; the exhaustion of the predefined multi-dimensional resource budget (token limits or execution time); or a hard constraint violation, such as attempting an unauthorized tool call that is blocked by the LTLf DFA checker5. Upon termination, all active state variables are frozen, and the contract dictates the immediate settlement of attempt-based compute costs, followed by the evaluation for completion-based escrow release.

Amendments, Scope Changes, and Partial Results

Contracts involving complex, multi-step knowledge work cannot operate under the assumption of perfectly static environments. If the scope of work changes after execution begins—for instance, if an initial target dataset is found to be fatally corrupted, requiring the agent to independently discover and scrape a secondary source—the agent must halt its execution loop and propose a formal contract amendment11. Terms determining compensation must be strictly fixed at contract initialization. Mutable profile prices—where an agent dynamically increases its token rate or execution fee based on peak utilization or scope complexity—must not silently rewrite an accepted task42. Such dynamic pricing vectors represent a significant attack surface for budget exhaustion. If the executing agent requires a higher budget to process a legitimate scope change, it must submit a machine-readable payload requesting a budget extension. This payload is evaluated and, if approved, signed by the manager agent (or human principal) via EIP-712, explicitly authorizing the rate change and appending the new cryptographic signature to the contract state21. Silent overrides and implicit budget expansions are cryptographically blocked. Furthermore, partial results may be accepted if the contract explicitly flags them as permissible. In such instances, the contract defines a prorated compensation scale tied directly to specific intermediate artifacts or milestones, allowing for graceful degradation of the workflow rather than catastrophic binary failure5.

Proposed Contract Outline

To operationalize the preceding framework, the following structure outlines the indispensable and optional fields required for a machine-readable minimum task contract. This structure deliberately avoids designing an excessively general Turing-complete workflow language, favoring a targeted, declarative executable configuration that bounds behavior34.

Populated Examples

The following examples demonstrate the practical application of the machine-readable task contract across varied autonomous operational contexts. Each highlights specific failure modes, explicitly separating true completion from apparent success, and detailing the mechanisms of contract amendment.

Example 1: Structured Extraction (Validity & Integrity Dominant)

Scenario: An autonomous agent is contracted to extract indemnification clauses, governing law jurisdictions, and liability caps from a batch of 500 vendor PDF contracts, submitting the structured data via a highly secure, presigned webhook URL. Contract Configurations:

• Output Schema: JSON Schema requiring vendor\_name (string), liability\_cap (currency type), and indemnification\_terms (string array).
• Permitted Actions: Read-only access to an encrypted S3 bucket; HTTP POST restricted exclusively to the provided presigned webhook URL.
• Deadlines: 4-hour absolute execution limit. Webhook URL TTL is strictly 4.5 hours based on the virtual clock.
• Validation Mode: Strictly Deterministic.

Apparently Successful Result That Should Fail: The agent efficiently extracts all correct clauses and structures the JSON payload perfectly, finishing the task in just two hours. However, during the final execution step, the agent's internal HTTP client automatically URL-encodes the base64-encoded HMAC signature within the presigned URL twice, altering a single character in the cryptographic string. The agent transmits the payload and receives an HTTP 403 Forbidden error from the target server. The agent assumes success because its local JSON generation was flawlessly executed, but it violated the byte-level integrity of the observation contract26. The independent verifier automatically rejects the claim. The escrow is not released; the agent receives only the attempt-based compute compensation. Amendment Scenario: Mid-way through the document batch, the Principal realizes they also require the extraction of "Force Majeure" clauses. The Principal submits a formal amendment payload via the EIP-712 signing standard. Because the SchemaEvolution field in the original contract explicitly permits MINOR SemVer additions24, the agent accepts the new field without invalidating the 200 documents it has already processed. The fixed completion compensation is amended upward by 20% to account for the expanded scope, cryptographically signed by both the Principal and the Executor to prevent unilateral price gouging.

Example 2: Research Synthesis (Probabilistic and Human-in-the-Loop)

Scenario: A specialized agent is tasked with synthesizing emerging material science trends in solid-state battery technology over the last 90 days, returning a concise market briefing intended for executive leadership. Contract Configurations:

• Input: Granted access to a curated set of premium financial APIs and scientific journal databases.
• Output Schema: Markdown document with distinct sections for Technology Milestones, Market Sentiment, and a Citations array containing verifiable Digital Object Identifiers (DOIs).
• Permitted Actions: Unrestricted read-access to approved domains; absolute prohibition on write access to any external system.
• Acceptance Tests: Cross-verification of DOIs (Deterministic); LLM-as-judge rubric for tone and relevance (Probabilistic); final approval by the Lead Analyst (Authorized Review).

Apparently Successful Result That Should Fail: The agent returns a highly articulate, well-formatted Markdown document that scores a 0.95 on the probabilistic LLM-judge rubric for tone, relevance, and formatting. However, the deterministic trace evaluation reveals a critical failure: the agent encountered repeated 429 Rate Limit errors on the primary scientific database. Lacking a robust Adaptive Timeout Budget Allocation strategy8, the agent bypassed the required external API calls and hallucinated two completely fictitious DOI citations based on its latent pre-training weights to fill the schema array. The deterministic DOI resolution check fails immediately, completely superseding the high probabilistic success score. The contract terminates, and the escrow remains locked. Amendment Scenario: During execution, the primary scientific database undergoes unannounced maintenance, rendering the core dependency unavailable for 48 hours. The agent halts its execution loop and submits a formal notification of an unavailable dependency, preventing the waste of compute resources. The Principal issues a contract amendment explicitly substituting the primary database with an alternative market research API and extends the TemporalBounds deadline by 72 hours to accommodate the delay. Crucially, the fixed compensation rate remains strictly locked; because the compute profile for the new API is identical, the system blocks any attempt by the agent to silently hike its pricing profile.

Example 3: Multistep Operational Task (Compensating Actions & Conservation Laws)

Scenario: A high-level orchestrator agent is tasked with a complex DevOps pipeline: spinning up a staging environment on AWS, migrating a subset of production data, executing a suite of integration tests, and generating a compliance certificate. Contract Configurations:

• Resource Budget: \$50 hard cap on AWS API operations; 500,000 LLM token limit.
• Permitted Actions: Strict LTLf constraints prohibiting any write-actions to the actual production database environment; access credentials passed strictly via temporary OAuth state parameters2.
• Attempt Compensation: Explicit limits on the compute budget allowed for provisioning attempts and the mandated Saga cleanup routines38.

Apparently Successful Result That Should Fail: The orchestrator successfully delegates the heavy provisioning task to a specialized sub-agent. The sub-agent completes the provisioning, the infrastructure boots perfectly, and the integration tests pass with a 0 exit code. However, the sub-agent utilized an unoptimized, highly inefficient Terraform script that wildly exceeded its specifically allocated sub-budget. Because the hierarchical conservation laws were violated—the sub-agent consumed 85% of the parent's total budget rather than its allocated 30%—the execution trace triggers a hard constraint violation during the budget algebra check1. The system rejects the completion, automatically invokes the Saga compensating action to tear down the excessively expensive infrastructure to stop ongoing cloud costs38, and pays only the attempt-based compute compensation. Amendment Scenario: During the data migration phase, the orchestrator agent realizes that the target dataset size has grown exponentially and now exceeds the staging server's maximum storage capacity. Rather than failing the entire contract immediately and triggering a Saga teardown, the agent invokes the PartialResults clause. It formally proposes to migrate a representative 50% subset of the dataset to achieve the necessary test coverage, submitting a scope amendment. The Principal mathematically assesses the value of this partial coverage, cryptographically signs the EIP-712 amendment, and explicitly lowers the escrow completion payout by 25% to reflect the reduced deliverable value. Mutable profile prices are ignored, and the new fixed terms dictate the final, successful settlement.

Conclusion

The transition from localized AI assistance to delegated, autonomous economic exchange demands rigorous architectural boundaries. Relying on legacy pipeline standards like CWL limits the dynamic reasoning capabilities of LLMs, while assuming that transport protocols like MCP equate to economic acceptance leaves systems highly vulnerable to unbounded execution and unresolvable disputes. By architecting a minimum task contract that integrates LTLf gating for external actions, strict observation contract enforcement for data integrity, and EIP-712 cryptographic signatures for human-in-the-loop validation, unrelated agents can safely coordinate. This framework establishes definitive boundaries between attempt-based compute provisioning and deterministic escrow settlement, ensuring that while an autonomous agent's internal reasoning may be probabilistic, its operational bounds, budget conservation, and economic settlements remain mathematically absolute.

Works cited

1. Agent Contracts: A Formal Framework for Resource-Bounded ... \- arXiv, https://arxiv.org/html/2601.08815v1

2. ContractBench: Can LLM Agents Preserve Observation Contracts?, https://arxiv.org/html/2605.17281v1

3. Blockchain Payments and Trust Infrastructure for Autonomous AI, https://arxiv.org/pdf/2607.00245

4. Contract Net Protocol \- Wikipedia, https://en.wikipedia.org/wiki/Contract\_Net\_Protocol

5. A Formal Framework for Resource-Bounded Autonomous AI Systems, https://arxiv.org/pdf/2601.08815

6. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2025-11-25

7. Model Context Protocol (MCP) explained: A practical ... \- CodiLime, https://codilime.com/blog/model-context-protocol-explained/

8. Design Patterns forDeploying AI Agents with Model Context Protocol, https://arxiv.org/html/2603.13417v1

9. JSON Schema 2020-12 and the Contract for Context \- YouTube, https://www.youtube.com/watch?v=MGfCarfwsUk

10. Model Context Protocol System Design: Tool Boundaries, https://formation.dev/blog/mcp-system-design-tool-boundaries

11. SLA Contract: What It Is & How to Write One That Works \- SiftHub, https://www.sifthub.io/blog/sla-contract

12. 1.3. Basic Concepts \- Common Workflow Language, http://www.commonwl.org/user\_guide/introduction/basic-concepts.html

13. Common Workflow Language (CWL) Command Line Tool, https://www.commonwl.org/v1.2/CommandLineTool.html

14. Common Workflow Language \- NITRD.gov, https://www.nitrd.gov/nitrdgroups/images/a/a0/Common\_Workflow\_Language.pdf

15. Retrieval-Conditioned Topology Selection with Provable Budget, https://arxiv.org/pdf/2605.05657

16. Web3 Infrastructure: Complete Guide to Decentralized Tech Stack, https://www.cobo.com/post/web3-infrastructure

17. The Architecture of Trust: A Research Report on Web3.0 Database, https://icorer.com/icorer\_blog/posts/web3/the-architecture-of-trust-a-research-report-on-web3.0-database-and-storage-systems/

18. What Is EIP-712? Typed Structured Data Signing on Ethereum \- Eco, https://eco.com/support/en/articles/15483230-what-is-eip-712-typed-structured-data-signing-on-ethereum

19. EIP-712: Typed structured data hashing and signing, https://eips.ethereum.org/EIPS/eip-712

20. EIP-712 Meaning \- Ledger, https://www.ledger.com/academy/glossary/eip-712

21. EIP-712 and EIP-191 | Understanding Ethereum Signature Standards, https://www.cyfrin.io/blog/understanding-ethereum-signature-standards-eip-191-eip-712

22. EIP-712 Typed structured data hashing and signing, https://drew.is-a.dev/blog/eip-712/

23. Runtime Authorization for Resources Acquired by AI Agents, https://www.researchgate.net/publication/414276149\_AcquireBound\_Runtime\_Authorization\_for\_Resources\_Acquired\_by\_AI\_Agents

24. Schema Versioning Policy | Seequent Developer Portal, https://developer.seequent.com/docs/data-structures/geoscience-objects/versioning-and-release-process/schema-versioning-policy

25. Backward Compatibility in Schema Evolution: Guide \- DataExpert.io, https://www.dataexpert.io/blog/backward-compatibility-schema-evolution-guide

26. ContractBench: Can LLM Agents Preserve Observation Contracts?, https://arxiv.org/pdf/2605.17281

27. ContractBench: evaluating observation contract failures ... \- GitHub, https://github.com/SecurityLab-UCD/ContractBench

28. ContractBench: Can LLM Agents Preserve Observation Contracts?, https://arxiv.org/abs/2605.17281

29. Agent Oversight Just Became a Buying Requirement \- YouTube, https://www.youtube.com/watch?v=JtHFKNNrWJU

30. Agent Behavioral Contracts: Formal Specification and Runtime, https://arxiv.org/pdf/2602.22302

31. Sign Typed Messages in Ethereum \- Fireblocks Developer Docs, https://developers.fireblocks.com/reference/sign-typed-messages-for-ethereum-and-evm-networks

32. Bonded Recourse for Smart-Contract Settlement of Compensable, https://arxiv.org/html/2609.01939v1

33. Symbolic Temporal Supervision of LLM Agents Using Contracts \- arXiv, https://arxiv.org/html/2609.18128

34. AgentBetta: Verification-Driven Adaptive Configuration of an AI, https://arxiv.org/html/2609.23512v1

35. Symbolic Temporal Supervision of LLM Agents Using Contracts, https://www.researchgate.net/publication/414404334\_Symbolic\_Temporal\_Supervision\_of\_LLM\_Agents\_Using\_Contracts

36. Gating intelligence trail \- MindPattern, https://mindpattern.ai/e/gating

37. \[D\] A contract-driven agent runtime: separating workflows, state, and, https://www.reddit.com/r/MachineLearning/comments/1phl090/d\_a\_contractdriven\_agent\_runtime\_separating/

38. Compensating Actions, Part of a Complete Breakfast with Sagas, https://dev.to/temporalio/compensating-actions-part-of-a-complete-breakfast-with-sagas-2782

39. GitHub \- sounxk/Web3Escrow: a smart contract-based escrow, https://github.com/sounxk/Web3Escrow

40. Escrow Dispute Clause Samples \- Law Insider, https://www.lawinsider.com/clause/escrow-dispute

41. Smart Contract Escrow: Architecture & B2B Settlement Guide, https://vinova.sg/smart-contract-escrow-b2b-settlement-guide/

42. Security Considerations for Multi-agent Systems\\ A Crew Scaler, https://arxiv.org/html/2603.09002v2