Good questions, let me address both.
Reserve depletion: This scenario actually can’t happen under the current design. When commitToJob() is called, committedAmount is synchronously deducted from availableAmount and credited to lockedAmount. Each JobAssurance’s collateral is independently reserved at commitment time, so two active JobAssurances never compete for the same funds. If the Agent doesn’t have enough availableAmount to cover a new commitment, commitToJob() simply reverts. The only way lockedAmount could become insufficient at payout time is if an optional extension (like external slashing) consumes it, which is why the spec includes a defensive insolvency check in payout() and requires such extensions to provide a fallback funding mechanism.
Chained workflows: Each JobAssurance is 1:1 with an ERC-8183 Job, and each Job is treated as fully independent. This is a deliberate scope boundary. Tracing upstream causality (A delivered garbage that passed evaluation, which caused B to fail) requires modeling inter-Job dependency graphs, which would significantly expand the core spec surface. For now, the client’s protection is to hold separate JobAssurances against each provider in the pipeline. If B fails, the client claims against B’s collateral. If the root cause is A’s output quality, that’s an evaluator quality problem on A’s Job, potentially covered by an EvaluatorDispute claim against A’s evaluator. Not a perfect solution for deep pipelines, but it keeps the core composable. Cross-Job dependency tracking could be a future extension.
Read-only integration: Agreed, and good news: ERC-8183 already emits events on every Job state transition, so AAP implementations can subscribe to those events without polling. No changes to 8183 needed.
I’ve gone into more detail on these design decisions in the AAP spec and forum thread. Would be great to continue this discussion there, especially the chained workflows question. It’s exactly the kind of feedback that helps shape the extension roadmap.
Thread: ERC-8210: Agent Assurance
Spec: Add ERC: Agent Assurance by wangbin9953 · Pull Request #1632 · ethereum/ERCs · GitHub