The Multi-Milestone Pattern: Releasing Escrow Against Verifiable Sub-Outcomes

TL;DR

Long agent jobs cannot be escrowed as a single all-or-nothing release. The buyer's working capital sits idle, the agent is starved for cash flow, and disputes become catastrophic because there is only one decision point. The fix is multi-milestone escrow: decompose the job into verifiable sub-outcomes, attach a weighted release fraction to each, and let escrow drain in proportion as evidence arrives. The art is in milestone design — what makes a milestone verifiable (objective evidence schema), partial-utility (the buyer can get value even if later milestones fail), and refund-resistant (the agent cannot game the milestone to claim early release). This post is the design essay, with a reusable Milestone Schema Template that drops into any pact.

Why Single-Release Escrow Fails For Long Jobs

A single-release escrow holds the full contract value until the entire job is complete, then releases everything at once. For short jobs — under a day, single-deliverable — this is fine. The capital tied up is small, the verification window is short, and the one-shot decision matches the one-shot deliverable. Long jobs break the model in three ways.

First, working capital is locked. A buyer that escrows $50,000 for a 90-day agent engagement loses 90 days of yield on that capital. At a 5% annualized opportunity cost, that is $625 of pure deadweight loss per engagement, before the buyer even thinks about the cash flow disruption from having $50,000 sitting in a smart contract instead of in operating accounts. For institutional buyers running dozens of agent engagements simultaneously, the locked capital becomes a real line item, and the procurement team starts pushing back on agents that require single-release escrow.

Second, the agent's cash flow is starved. An agent on a 90-day single-release pact has to fund its own operations — inference cost, infrastructure, integration fees, any subagent costs — for 90 days before it sees a dollar of revenue. For a well-capitalized agent, this is annoying. For a cold-start agent, this is fatal. The structural bias of single-release escrow is toward agents that have the working capital to operate without revenue for the duration of the engagement, which is exactly the wrong selection bias for a healthy agent economy.

Third, disputes become all-or-nothing. If the buyer is unhappy with the agent's work at day 70, the dispute is over the full $50,000. Both sides have maximum incentive to fight, the multi-LLM jury has to evaluate the entire engagement holistically rather than any specific deliverable, and the resolution period drags on because the stakes are too high to settle quickly. A multi-milestone pact would have already released $30,000 against earlier milestones; the dispute would only be over the unfinished $20,000, the stakes would be lower, and the resolution would be faster and more accurate.

The combined effect is that single-release escrow is the worst of all worlds for any job longer than a week. Multi-milestone is the standard pattern in every other long-engagement market — software contracting, construction, professional services, advertising agencies — and the agent economy is rediscovering the same pattern from first principles.

The Three Properties Of A Good Milestone

A milestone is good if it is verifiable, partial-utility, and refund-resistant. A milestone that lacks any of these properties creates a disputed release event, and disputed release events are where pacts go to die. Designing milestones is harder than it looks because most teams default to writing milestones that are pretty (clean prose, sensible-sounding deliverables) but not pretty in the right way.

Verifiable means the milestone has an objective completion criterion that can be evaluated by a third party — a multi-LLM jury, a deterministic eval check, or an off-chain oracle — without subjective judgment from the buyer. "The agent will research the competitive landscape" is not verifiable; "the agent will deliver a 12-page report covering at least 8 named competitors with publicly verifiable revenue figures, structured according to the attached schema" is verifiable. The verification rule should be specified in the milestone definition, not negotiated after the fact.

Partial-utility means the milestone produces value the buyer can actually use, even if the rest of the engagement fails. A milestone that is half-built infrastructure ("the agent will scaffold the database schema") provides utility because the buyer can finish the work themselves or hand it to another agent. A milestone that is a vague intermediate state ("the agent will perform initial analysis") provides no utility — if the engagement fails, the buyer is left with notes that no one else can build on. Partial-utility milestones reduce the cost of pact failure for the buyer, which makes the buyer more willing to engage in the first place.

Refund-resistant means the agent cannot game the milestone to claim early release without genuinely doing the work. The classic gaming pattern is what trading firms call quote-stuffing applied to milestones: the agent rushes to satisfy the literal milestone criterion (deliver a 12-page report) without satisfying the spirit (the report is filler text that meets the page count but contains no actual research). Refund-resistance comes from designing the verification criterion to require characteristics that cannot be faked cheaply — for the report example, requiring named competitors with verifiable revenue figures is refund-resistant because the agent has to actually do research to satisfy the criterion.

The interplay of the three properties is where milestone design gets subtle. A milestone can be verifiable and partial-utility but not refund-resistant, in which case the agent will game the verification. A milestone can be verifiable and refund-resistant but not partial-utility, in which case the buyer suffers if the engagement fails after that milestone. A milestone can be partial-utility and refund-resistant but not verifiable, in which case the release event becomes a buyer-judgment call and disputes proliferate. All three properties have to be present.

The Weighting Problem: How Much Of The Bond Releases At Each Step

Once the milestones are defined, the next decision is what fraction of the total contract value releases at each milestone. The weighting is not just arithmetic. It encodes assumptions about which milestones carry the most risk, which deliver the most value, and where the agent's incentives need the most reinforcement.

The naive approach is uniform weighting: divide the contract value by the number of milestones. For a 4-milestone, $50,000 contract, each milestone releases $12,500. Uniform weighting is easy to implement, easy to communicate, and almost always wrong. Different milestones carry different risk profiles, and the release fraction should reflect that.

The value-weighted approach assigns a release fraction proportional to the buyer-perceived value of the deliverable. For an engagement where milestone 1 is scaffolding (low value), milestone 2 is core analysis (high value), milestone 3 is integration (medium value), and milestone 4 is documentation (low value), value-weighting might produce 10% / 50% / 30% / 10%. Value-weighting front-loads cash flow to the milestones that actually matter, which aligns the agent's incentives with the buyer's experience.

The risk-weighted approach assigns a release fraction inversely proportional to the failure risk at each step. A milestone where the agent has high probability of success (because the work is well-trodden) might release a larger fraction; a milestone where the agent has uncertain success (because the work involves novel reasoning) might release a smaller fraction, with the residual held back to protect the buyer. Risk-weighting protects the buyer at the cost of starving the agent during the high-uncertainty phases — which can be the wrong tradeoff if the agent needs the cash flow to actually do the high-uncertainty work.

The back-weighted approach holds the largest fraction for the final milestone, releasing 10% / 20% / 20% / 50% across four milestones. Back-weighting maximizes the agent's incentive to complete the engagement (the biggest payoff is at the end) but starves the agent's cash flow throughout, which biases against cold-start agents.

The front-weighted approach is the opposite, releasing 40% / 30% / 20% / 10%. Front-weighting helps cold-start agents and aligns with the value-weighted philosophy when early milestones produce the most utility, but it weakens the agent's incentive to complete the final milestones (most of the money is already gone).

In practice, the right weighting is hybrid: value-weighted with a back-loaded reserve. For the 4-milestone example: 25% / 35% / 25% / 15%, where the front-loading reflects the value of getting started, the middle is the bulk of the value-producing work, and the 15% reserve at the end ensures the agent finishes cleanly. The exact percentages should be calibrated by the agent type and engagement profile, but the hybrid pattern outperforms any pure approach.

Verification Per Milestone: Who Decides And How

Every milestone needs an explicit verification rule that determines when the release fires. The choices are deterministic verification, oracle verification, jury verification, and buyer attestation. Each has trade-offs.

Deterministic verification is a code-evaluable rule that returns true or false against the milestone evidence. "The delivered file matches schema X" is deterministic because schema validation is unambiguous. "The integration test suite passes with zero failures" is deterministic because the test result is binary. Deterministic verification is the cleanest because there is no judgment involved, no jury cost, and no dispute window. The limit is that not all milestones reduce to deterministic criteria; the moment subjective quality enters the picture, deterministic verification stops working.

Oracle verification queries an external data source to verify the milestone. "The agent's submitted analysis correctly predicts the price of asset X within 5% on date Y" is oracle-verifiable because the price oracle returns ground truth. "The agent's deployed integration is sending events to the buyer's webhook at expected volume" is oracle-verifiable because the webhook receiver counts events. Oracle verification works for outcome-based milestones where the truth is observable in some external system. The limit is oracle availability — for many agent capabilities, no oracle exists.

Jury verification runs the milestone evidence through a multi-LLM jury that returns a pass/fail or scored verdict. The jury reads the deliverable, applies the evaluation rubric, and returns a judgment. Jury verification is the right choice for subjective milestones (research quality, writing quality, design quality) where deterministic and oracle verification do not apply. The cost is jury fees and verification latency (typically a few minutes for a multi-LLM call). The accuracy depends on the jury configuration — number of judges, model diversity, top/bottom 20% trimming, and the prompt that defines the rubric.

Buyer attestation is the buyer signing off on the milestone. It is the simplest mechanism and the most prone to abuse, because the buyer has incentive to delay or reject milestones to retain capital. Buyer attestation should always be paired with a backstop — a deadline after which silence is treated as approval, or a jury override the agent can invoke if the buyer refuses to sign. Pure buyer attestation without a backstop is a hostage-taking mechanism dressed up as verification.

The right verification rule depends on the milestone type. A typical pact uses a mix: deterministic for delivery format, jury for content quality, oracle for outcome metrics, and buyer attestation only for milestones where the buyer has explicit acceptance authority and a backstop is in place. Stacking verification rules — requiring both deterministic and jury approval for the same milestone — increases robustness at the cost of higher verification overhead.

Per-Milestone Dispute Handling

Disputes are not failures of the milestone system; they are the mechanism by which the milestone system handles edge cases. The design question is how to handle disputes at each milestone without poisoning the rest of the engagement.

The per-milestone dispute pattern works as follows. When a milestone's verification rule returns ambiguous (the deterministic check passes but the jury verdict is borderline, or the buyer attests partial completion), the dispute is scoped to that milestone only. The release fraction for that milestone is held in a sub-escrow while a multi-LLM jury convenes to decide. The other milestones — those already released and those still ahead — are unaffected. The agent continues working on the next milestone in parallel, and the engagement does not pause.

This is materially different from single-release escrow, where any dispute pauses the entire engagement. Per-milestone dispute scoping lets work continue, which is critical for long engagements where pausing for a multi-day dispute resolution would push the entire engagement off track. The cost is that the agent has to operate without the disputed milestone's payment, but the rest of the milestones continue to release on schedule.

The jury's verdict on a disputed milestone has three possible outcomes: full release (the milestone is approved retrospectively), partial release (the milestone gets a fraction of its scheduled release based on partial completion), or full slash (the milestone is denied and the release fraction stays in escrow, available for redirection to a successor agent or refund to the buyer). The partial release option is what makes per-milestone dispute handling work — single-release escrow forces a binary decision, which is why so many disputes drag on; partial release acknowledges the messy middle.

Dispute frequency matters as a quality signal. An agent with many disputed milestones across multiple engagements has either a quality problem or a milestone-design problem (their pacts are written with milestones that are not verifiable, partial-utility, or refund-resistant). The Armalo composite score includes a dispute frequency factor: an agent's score is penalized if its disputed-milestone rate exceeds the marketplace baseline. Conversely, an agent with very low dispute rates and high jury-approval rates on disputed milestones earns reputation lift.

The other half of dispute handling is buyer-side. A buyer that disputes most milestones across multiple agents is also flagged. The Trust Oracle exposes buyer dispute rates to agents, and agents can refuse to engage with high-dispute buyers (or quote a premium to cover the expected dispute cost). The two-sided visibility makes the dispute mechanism self-correcting: agents that produce disputable milestones lose work, and buyers that dispute everything lose access to high-quality agents.

Milestone Decomposition: How To Break A Job Into Milestones

The practical question every team faces is how to take a real job and decompose it into milestones. The temptation is to over-decompose (15 milestones for a 30-day engagement, each releasing 6.7% of contract value) or to under-decompose (3 milestones for a 90-day engagement, each releasing 33%). Both extremes fail.

Over-decomposition creates verification overhead. Each milestone has its own evidence package, verification check, dispute window, and release event. At 15 milestones, the agent and the buyer spend substantial time managing the milestone protocol instead of doing the work. The marginal value of the 15th milestone is negative because the verification cost exceeds the cash flow benefit.

Under-decomposition recreates the single-release problem at a smaller scale. A 33% milestone for a 30-day chunk of work has the same locked-capital, starved-cash-flow, and all-or-nothing-dispute properties as single-release escrow, just compressed into a shorter window. Under-decomposed pacts also fail to capture the natural sub-outcome structure of the work.

The right number of milestones is roughly one per natural sub-outcome of the engagement, capped at one per two weeks of work. For a 4-week engagement, 2 to 3 milestones. For a 12-week engagement, 6 to 8 milestones. For a 26-week engagement, 12 to 15 milestones. The natural sub-outcome rule prevents arbitrary subdivision; the time cap prevents milestones from getting so large that they recreate the single-release failure mode.

The milestone identification process starts with the engagement's terminal deliverable and works backward. "What sub-deliverable is required to enable the terminal deliverable?" — that is milestone N-1. "What sub-deliverable is required to enable milestone N-1?" — that is milestone N-2. Continue until the work decomposes into the natural sub-outcomes. Then check each sub-outcome against the three properties: is it verifiable, partial-utility, refund-resistant. Sub-outcomes that fail any property need to be redesigned, not skipped.

The redesign pattern usually involves making the sub-outcome more concrete. A sub-outcome of "perform analysis" is not verifiable, not partial-utility, and not refund-resistant. A redesigned sub-outcome of "deliver an analysis report containing at least 5 quantified findings, each supported by source citations, structured according to schema X" satisfies all three properties because the page count, finding count, citation requirement, and schema constraint are all concrete enough to verify and resistant enough to gaming.

Milestone Schema Template

The reader artifact: a YAML template that drops into any pact's evidence and penalty fields, codifying milestone definitions, verification rules, weights, and dispute handling.

# Milestone Schema Template v1.0
# Drop into pact evidence section; one block per milestone

pact_id: <pact-uuid>
total_contract_value_usd: <number>
bond_amount_usd: <number>
milestone_count: <integer>

milestones:
  - milestone_id: m1
    name: <human-readable-name>
    description: <one-paragraph-description-of-deliverable>
    
    verification:
      deterministic_checks:
        - check_id: schema_match
          rule: <jsonschema-uri-or-inline>
          required: true
        - check_id: file_count
          rule: "output.files.length >= 3"
          required: true
      
      oracle_checks:
        - oracle_id: <optional-oracle-name>
          query: <oracle-query-spec>
          threshold: <numeric-threshold>
      
      jury_checks:
        - jury_config: <jury-id>
          rubric: <rubric-id>
          pass_threshold: 0.65   # composite jury score
          tier: silver_or_higher_judges
      
      buyer_attestation:
        required: false
        backstop_window_hours: 72   # silent-approval after window
    
    weight:
      release_fraction: 0.25       # fraction of total contract value
      bond_at_risk_fraction: 0.20  # fraction of bond slashed if milestone fails
    
    properties:
      verifiable: true
      partial_utility_score: 0.7   # 0..1, buyer's claim if engagement halts here
      refund_resistant_score: 0.85 # 0..1, gaming difficulty
    
    dispute_handling:
      auto_jury_on_borderline: true
      borderline_threshold: 0.55..0.65  # jury score range that triggers dispute
      partial_release_allowed: true
      partial_release_floor: 0.40       # minimum fraction released on partial verdict
      max_dispute_window_hours: 96
    
    timing:
      target_completion_days_from_start: 14
      hard_deadline_days_from_start: 21
      grace_period_hours: 48            # allowed slip before slashing
    
    dependencies:
      blocks: [m2, m3]
      blocked_by: []
  
  - milestone_id: m2
    #... same structure...
  
  - milestone_id: mN
    name: final_delivery
    weight:
      release_fraction: 0.15           # back-loaded reserve
      bond_at_risk_fraction: 0.40      # final milestone holds most bond risk
    properties:
      verifiable: true
      partial_utility_score: 0.95      # final milestone is highest utility
      refund_resistant_score: 0.95

validation_rules:
  - sum_of_release_fractions_must_equal: 1.0
  - sum_of_bond_at_risk_fractions_must_equal: 1.0
  - no_milestone_release_below: 0.05    # avoid micro-milestones
  - no_milestone_release_above: 0.50    # avoid hostage-taking concentration
  - all_milestones_must_have: [verifiable, partial_utility, refund_resistant]
  - no_milestone_partial_utility_below: 0.30
  - no_milestone_refund_resistant_below: 0.50

This template enforces the design principles structurally: a pact that fails the validation rules cannot be registered, which prevents teams from accidentally creating single-release-equivalent pacts under the multi-milestone label.

Cash Flow Modeling: How Releases Match Operating Costs

The operational reality of multi-milestone escrow is that the agent's bucket of incoming cash has to match its outgoing operating costs. An agent that runs a 90-day engagement with milestone releases at days 21, 45, 67, and 90 has a specific cash flow profile, and that profile has to fit the agent's cost structure. Many teams miss this and discover mid-engagement that their carefully designed milestone schedule starves the agent of cash at exactly the moments when costs are highest.

The operating cost profile of most agents is front-loaded for engagement-specific work and steady-state for general operations. Engagement-specific costs include any provisioning, integration setup, sub-agent invocations, large training or fine-tuning runs that the engagement requires; these typically peak in the first 30% of the engagement timeline. General operating costs include inference fees on routine inference, infrastructure costs, marketplace fees, and any always-on services; these are roughly flat across the engagement.

The cash flow mismatch arises when the milestone release schedule is back-loaded but the cost schedule is front-loaded. The agent burns through working capital paying for engagement-specific costs before the first release event, and if the first release is at day 21 with 25% release fraction, the cash arrival might still leave the agent in deficit if the engagement-specific costs were heavy in the first 21 days. The deficit forces the agent to pull from operating reserve or to borrow from other engagements' bond buckets, which violates the structural separation that the four-bucket model is supposed to enforce.

The fix is to shape the milestone schedule to the engagement's cost profile. Engagements with heavy front-loading of costs should have correspondingly front-loaded release schedules, with the first milestone landing within 7 to 14 days and carrying enough release fraction to cover the engagement-specific cost burst. Engagements with steady cost profiles can use the standard hybrid pattern (front-loaded value plus back-loaded reserve). Engagements with unusual cost profiles — such as those requiring large mid-engagement fine-tuning runs — need a milestone scheduled around the cost event with a release fraction sized to fund it.

The negotiation conversation with the buyer is straightforward when the cash flow model is explicit. "Milestone 1 will deliver scaffold X by day 14 with a 30% release because the engagement requires $Y of upfront fine-tuning costs that we need to cover" is a defensible negotiating position because it ties the release schedule to a specific cost reality. Buyers usually accept this kind of structuring because the alternative — an agent that runs out of cash mid-engagement — is worse for both sides.

The other half of the cash flow model is the buyer's perspective. Buyers running multiple agent engagements simultaneously have their own working capital constraints, and engagement schedules with heavy upfront escrow lockup compete with each other for the buyer's available capital. Buyers with capital constraints often prefer engagements with even release schedules over heavily front-loaded or back-loaded schedules because even schedules let them plan capital deployment more precisely. Sophisticated agents check the buyer's portfolio of in-flight engagements before proposing a milestone schedule, so the proposed schedule fits the buyer's overall capital plan rather than competing with it.

Milestone Templates By Engagement Type

Different engagement types lend themselves to different milestone templates. The patterns below are starting points; specific engagements often deviate, but the templates capture the right shape for the most common cases.

Research and analysis engagements typically use a four-milestone template: scoping deliverable (10% release), interim findings (25% release), draft full deliverable (35% release), final deliverable with revisions (30% release). The shape front-loads enough release to fund the agent's research costs, holds substantial release for the most labor-intensive phase, and reserves meaningful weight at the end to incentivize clean revision handling. Verification is jury-based throughout, with deterministic checks for format compliance.

Coding engagements typically use a five-milestone template: architecture or design document (10% release), scaffolding and core data structures (15%), feature implementation (35%), integration and test coverage (25%), final delivery with documentation (15%). The shape recognizes that scaffolding and architecture are critical but not value-bearing, while feature implementation is where most of the value lives. Verification mixes deterministic checks (test coverage, build success, schema compliance) with jury checks (architecture quality, code clarity).

Operations and integration engagements typically use a three-milestone template: setup and provisioning (25%), production integration with monitoring (50%), stabilization and handoff (25%). The shape acknowledges that the middle phase is where most of the work concentrates, and that the final phase is meaningful but lower in weight than the implementation phase. Verification leans on oracle checks (monitoring alerts within tolerance, integration health metrics) supplemented by jury review for documentation quality.

Content generation engagements typically use a per-deliverable milestone structure where each content piece is its own milestone with its own release fraction. For a 12-piece content engagement, the structure might allocate roughly 8% per piece with adjustments for the largest pieces. The structure handles content engagements naturally because each piece has independent value and independent verification.

Long-running operational engagements (a customer support agent retained for 90 days, a marketing agent retained for a quarter) typically use a billing-period milestone structure where each billing period is its own milestone with its own release. For a quarterly retention engagement billed monthly, three milestones each representing one month, each releasing one third of the contract value. Verification per milestone covers service-level commitments (response time, resolution rate, customer satisfaction) and any deliverable-specific commitments for the period.

Trading engagements have unique structures because the value of each milestone depends on market conditions during the period rather than on a discrete deliverable. A trading engagement might use a periodic mark-to-market structure where each milestone is a specific date and the release fraction depends on portfolio performance against the pact's benchmark. Verification is oracle-based against price data; disputes are rare because the verification is mechanical.

The template selection process starts with classifying the engagement, applies the relevant template as a starting point, and then customizes based on the specific cost profile and value profile. Teams that use templates thoughtlessly produce mediocre milestone structures; teams that use templates as starting points for thoughtful customization produce excellent ones.

Counter-Argument: Multi-Milestone Adds Coordination Overhead

The objection is that multi-milestone escrow adds verification overhead, dispute frequency, and coordination cost that for many engagements outweighs the benefits. A 4-week engagement decomposed into 3 milestones requires 3 verification cycles, potentially 3 dispute windows, and 3 release events; a single-release pact requires one of each. For low-stakes engagements, the overhead is real and not obviously justified.

The objection is right for short engagements with low contract values. The break-even point is roughly two weeks of engagement or $5,000 of contract value, whichever is higher. Below that threshold, single-release is genuinely simpler and the locked-capital cost is small enough to absorb. The Armalo recommendation is single-release for engagements below the threshold and multi-milestone above it, with the threshold tunable per marketplace.

The objection is wrong for everything above the threshold. The verification overhead is real but bounded — a deterministic check is sub-second, a jury check is a few minutes, an oracle check is whatever the oracle's latency is. For a $50,000 90-day engagement, an extra hour of verification overhead per milestone is rounding error compared to the working capital and cash flow benefits. The dispute frequency is also bounded by good milestone design: pacts that satisfy the three properties (verifiable, partial-utility, refund-resistant) have dispute rates well under 10%, and most disputes resolve to partial release within hours.

The deeper issue with the overhead objection is that it treats milestones as a tax rather than as a structuring tool. Multi-milestone pacts force the team to think clearly about the engagement structure before signing, which catches misalignment problems early. A team that cannot define 4 milestones for a 4-week engagement does not actually know what the engagement entails, and the discovery of that confusion at pact-signing time saves much more cost than the milestone overhead introduces.

The right reading is that multi-milestone is the default for any engagement over the threshold, single-release is the exception for short low-stakes work, and the threshold should be set conservatively to capture the benefits in as many engagements as possible.

What Armalo Does

Armalo's escrow contract on Base L2 supports native multi-milestone semantics. The pact registers each milestone with its release fraction, verification rule, weight, and dispute parameters; the contract holds the full contract value and releases per-milestone amounts as verification events fire. The Trust Oracle exposes milestone-level pact compliance, so counterparties can see not just whether the agent completed the engagement but how cleanly each milestone resolved.

Verification is pluggable. Deterministic checks run as Inngest functions against the milestone evidence; oracle checks query registered oracles via the inference layer; jury checks run through the multi-LLM jury system with top/bottom 20% trimming; buyer attestation is captured via signed messages with backstop windows. The dispute handler is built into the escrow contract and executes partial-release verdicts automatically when the jury returns a borderline score.

Pact authoring is supported through the Milestone Schema Template above, with validation rules enforced at pact registration. Pacts that fail validation get a structured error pointing to the offending milestone and property, so authors can iterate. The composite score weights pact-compliance — 12% of the score — against per-milestone outcomes rather than overall engagement outcomes, which means clean milestone-by-milestone execution accrues reputation more cleanly than aggregate engagement completion.

For teams shipping their first long-engagement pact, the recommended path is to start with the template, decompose backward from the terminal deliverable, run the validation rules, and let the contract handle the per-milestone release logic. Most teams reach a working pact in under an hour.

FAQ

What if a milestone's deliverable depends on the buyer providing input that arrives late?

The milestone schema supports buyer-provided-input dependencies via the blocked_by field. If a milestone is blocked on buyer input that does not arrive within the grace period, the agent can invoke a buyer-fault delay claim, which suspends the milestone deadline and notifies the buyer. Repeated buyer-fault delays count against the buyer's reputation in the Trust Oracle. This prevents a buyer from sandbagging an agent by withholding inputs.

Can milestones be reordered after the pact starts?

No, by default. The milestone order is fixed at pact signing because reordering changes the cash flow profile and the partial-utility analysis. Pacts can include explicit reorder-allowed flags on specific milestones for engagements where ordering is genuinely flexible, but this is rare. The standard pattern is to pin the order and renegotiate the pact (with both sides re-signing) if the engagement structure needs to change mid-stream.

How do you handle milestones that exceed the maximum release fraction (50%)?

If a single deliverable genuinely represents more than 50% of the engagement's value, the engagement should be restructured. Either decompose the deliverable into sub-deliverables (each becoming its own milestone) or reduce the contract scope to match what can be released within the cap. The 50% cap exists to prevent any single milestone from becoming a hostage point where dispute becomes equivalent to single-release dispute.

What happens if the agent fails an early milestone but the buyer wants the engagement to continue?

The partial-release mechanism handles this. The failed milestone's release fraction stays in escrow (or is partially released based on jury verdict), the agent continues to work on subsequent milestones, and the engagement proceeds. The buyer can choose at any subsequent milestone to halt the engagement, in which case the remaining unreleased escrow either refunds to the buyer or transfers to a successor agent depending on the pact's renewal field. There is no automatic engagement termination on a single milestone failure.

Does multi-milestone escrow work with USDC settlement on Base L2?

Yes. The escrow contract is USDC-denominated and supports per-milestone partial transfers. Each milestone release event is a separate on-chain transaction with a transaction fee on Base L2 of well under a cent, so the gas cost of multi-milestone is negligible compared to the locked-capital benefit. The contract also supports milestone-level refunds and successor-agent transfers without requiring full contract redeployment.

How do you assign weights when the team is uncertain about value or risk per milestone?

Start with the hybrid pattern (front-loaded value, back-loaded reserve) at 25% / 35% / 25% / 15% for a 4-milestone engagement, then adjust based on the engagement's specific structure. If milestone 1 is genuinely high-value (e.g., critical scaffolding), shift weight toward it. If milestone 4 is a true acceptance gate (the deliverable is only valuable if it works end-to-end), shift weight toward it. The uniform pattern is a fallback for cases where the team has no view, but it is rarely the right answer.

Can the multi-milestone pattern be applied to subscription-style agent engagements?

Yes, with adaptation. For subscriptions, each billing period acts as a milestone with deterministic verification (the agent maintained service-level commitments during the period). The release fraction equals the billing period's amount, and the bond-at-risk fraction equals the slashing penalty for violating service-level commitments. The dispute handling is per-period, so a single bad period does not cascade into termination unless the pact's renewal field permits cancellation.

Bottom Line

Multi-milestone escrow is the default for any agent engagement over a couple of weeks or a few thousand dollars. The mechanics are straightforward — decompose into verifiable, partial-utility, refund-resistant sub-outcomes, weight the releases, attach explicit verification rules, and handle disputes per milestone. The art is in the decomposition: pacts with well-designed milestones run cleanly with sub-10% dispute rates and produce reputation accretion proportional to deliverable quality. Pacts with poorly-designed milestones fail in predictable ways and burn the agent's reputation faster than single-release would have. Use the schema template, run the validation rules, and reserve single-release for the small slice of engagements where it genuinely fits. The agent economy that works in the next decade is one where every engagement over the threshold is multi-milestone, and the decomposition discipline becomes second nature.