Skip to content
Back to skills

Three Sided Agent Labor Market

ASecurity

Design and review an explicitly modelled multi-party agent-labor market, including participation groups, cross-group effects, information and control boundaries, and settlement outcomes. NOT for payment plumbing, a pricing theorem, or an unverified escrow operation.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 24, 2026
toolsgo

Works with

  • cli

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 2, 2026

npx -y skills add curiositech/port-daddy --skill three-sided-agent-labor-market --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Three Sided Agent Labor Market?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Three Sided Agent Labor Market
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/curiositech-three-sided-agent-labor-market/badge)](https://www.skillsdirectory.com/skills/curiositech-three-sided-agent-labor-market)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: three-sided-agent-labor-market
description: Design and review an explicitly modelled multi-party agent-labor market, including participation groups, cross-group effects, information and control boundaries, and settlement outcomes. NOT for payment plumbing, a pricing theorem, or an unverified escrow operation.
license: Apache-2.0
metadata:
  category: Research & Academic
  tags:
  - mechanism-design
  - multi-sided-platform
  - agent-marketplace
  - settlement-design
  - information-asymmetry
  provenance:
    kind: first-party
    owners:
    - port-daddy
  authorship:
    maintainers:
    - port-daddy
  io-contract:
    kind: deliverable
    produces:
      - kind: design-doc
        description: A model-bounded market worksheet with flows, assumptions, settlement states, and unresolved risks
---

# Three-sided agent-labor market design

“Three-sided” is a local modelling claim, not a count of logos, UI roles, incentive constraints, or reputation fields. Begin by naming the participation groups in the decision at hand, their outside options, their information, and the cross-group effects that matter. Only then decide whether a three-sided platform model is useful.

This skill preserves first-party ideas about operators, rented assets, skill licensing, float plans, and reputation as **proposals**. It does not claim they are economic theorems, deployed contract behavior, or a proven remedy for adverse selection.

## Model the groups before pricing

1. **List parties and roles.** A requester R may pay an operator O; O may rent a worker from owner W and license a skill from L; an intermediary P may charge a transaction fee.
2. **Choose the modelled groups.** State which roles share a participation decision and outside option for this decision. Five parties do not establish five sides. A shared legal identity does not itself collapse roles: one person may make separate buying and selling decisions. Aggregate roles only when a stated model justifies treating their participation decisions jointly; record what variation that aggregation discards.
3. **Draw four kinds of edge separately.** Record payments, control/authority, information/evidence, and reputation signals. A payment does not grant authority; an outcome signal does not prove quality.
4. **State cross-group effects and assumptions.** Name the counterfactual: holding total price fixed, would moving a charge from R to W change participation or volume? Also name multi-homing, platform competition, membership versus usage charges, and the price units.
5. **Select a pricing hypothesis, not a flip rule.** Rochet–Tirole’s two-sided model says price structure can matter when side-specific elasticities and cross-side effects matter. It does not say that scarce supply is always subsidized, or that a supply-to-demand flip follows automatically.
6. **Choose a settlement state model.** State who can produce evidence, decide a dispute, appeal, reverse a decision, and release funds. If the underlying float-plan/escrow contract and state machine have not been read, label the design a proposal.

### Hand check: roles are not sides

For the constructed example, draw R → O payment for delivered work; O → W lease payment; O → L license payment; and O → P transaction fee. Then record that R demand may affect W/L participation and W/L availability may affect R participation. This proves five parties and several flows; it does **not** prove a three-sided market.

A review can tentatively distinguish O, W, and L as participation groups only if the stated model supports that distinction and identifies their cross-group effects. Aggregating some roles instead needs a separate justification. If the evidence cannot support that, report “side count unresolved” and do not apply a multi-sided price result.

## Source-bounded economic lenses

| Lens | Supported question | Limit |
|---|---|---|
| Rochet & Tirole (2003) | Do price allocation, side elasticities, and cross-group effects change volume under named assumptions? | Its model is two-sided; it does not count local roles or select a subsidy side. |
| Grossman & Hart (1986) | How might residual control affect incentives when contracts omit contingencies? | It does not prescribe runtime revocation, reputation debits, or bonds. |
| Akerlof (1970) | Could hidden quality shrink trade under stated asymmetric-information assumptions? | It does not prove every skill market is lemons or prove metering/clawback remedies. |
| Chiu, Zhang & van der Schaar, arXiv:2512.04988v2 (2026) | What can a stylized capacity-constrained matching simulation illustrate? | Agents, jobs/clients, and platform rules are simulated; reputation is state/signal, not a third side or deployment evidence. |

See [the source ledger](references/01-primary-sources.md) and [method boundaries](references/02-first-party-proposal-boundary.md).

## First-party proposal: a float-plan settlement worksheet

Use the following only as a design worksheet until the actual contract and state machine are read. It is not a claim about shipped behavior.

| Field | Proposed meaning | Evidence/authority question |
|---|---|---|
| Float plan | task, acceptance criteria, budget ceiling, bounty, deadline policy | Who signs; which fields are versioned; what proves the current plan? |
| Held credits | bounty + bond + lease + license fee | Who funds each amount; can any amount be changed after acceptance? |
| Evidence | test receipt, delivery record, or reviewer finding | Who can submit it; how is provenance checked? |
| Decision | success, partial, failure, dispute, reversal, or collusion investigation | Which authority decides; is appeal possible; how is an earlier decision superseded? |
| Release | transfers and retained holds | What prevents double release after reversal or appeal? |
| Reputation signal | a separately scoped outcome annotation | Who may write it; can it be challenged; does it survive identity changes? |

### Constructed arithmetic hand check

Suppose bounty is 8 credits, bond is 2, lease is 1, and license fee is 0.5. Held amount is 8 + 2 + 1 + 0.5 = **11.5**. If a proposed 3% fee applies only to bounty, fee = 0.03 × 8 = **0.24** and net operator bounty = 8 − 0.24 = **7.76**. One proposed success transfer is:

| Recipient/purpose | Credits |
|---|---:|
| operator bounty after fee | 7.76 |
| return of bond to funder | 2.00 |
| asset lease | 1.00 |
| skill license | 0.50 |
| intermediary fee | 0.24 |
| **total** | **11.50** |

The arithmetic balances one constructed success row. It does not establish conservation across funding failure, partial completion, a false evaluator result, a dispute, reversal, collusion, or lost identity.

## Settlement outcomes: keep non-success distinct

| Outcome | Minimum record | Funds/reputation result that may be claimed |
|---|---|---|
| Success | accepted evidence, decision authority, decision version | Apply only the stated release rule. |
| Partial | delivered scope, omitted scope, assessment and authority | Hold/release allocation remains a policy choice; do not infer proportional payout. |
| Failure before work | plan acceptance, funding, and start/effect status recorded separately; failure can follow acceptance | Do not call it a completed task; return or retain funds only under the stated contract. |
| Failure after possible effect | evidence of attempted work and uncertainty | Preserve the unknown-effect state; do not silently retry or pay success. |
| Dispute | competing evidence, parties, reviewer authority, appeal window | Place disputed amounts on hold; a dispute is not sabotage. |
| Reversal | prior decision ID, new evidence, reversal authority | Create a superseding decision and prevent duplicate release. |
| Collusion allegation | parties, evidence, independent review path | Do not auto-slash from an allegation; preserve investigation and appeal. |

### Worked dispute and reversal

Use the 11.5-credit proposal above. A test evaluator reports success, so no transfer is final until its authority and evidence are recorded. W then supplies evidence that the worker’s output was evaluated against the wrong revision. Before any release, the state becomes **dispute**, and all 11.5 credits remain held. An authorised reviewer later reverses decision D17 with D18, records the corrected revision evidence, and chooses a partial-settlement rule. A valid ledger must show D17 superseded by D18 and exactly one release path. If a release already occurred, recording a reversal cannot put money back into escrow: record a separate authorised recovery or compensating transfer and any unrecovered deficit. This pre-release trace demonstrates evidence and accounting questions; it does not establish an oracle, appeal system, or a fair partial-payment formula.

## Diagnose the design, not the label

| Finding | Check | Repair |
|---|---|---|
| Phantom side | roles listed but no separate participation response/cross-group effect | collapse roles or mark the side count unresolved |
| Unsupported subsidy claim | “subsidize supply” asserted without elasticities, homing, price units, or counterfactual | record a testable local pricing hypothesis |
| Control leap | residual control theory is cited as a runtime permission | specify first-party authority and contract evidence separately |
| Lemons overreach | opaque skill is presumed low-quality | identify the asymmetric-information condition and a measurement plan |
| Reputation reification | reputation field called a market side | model it as signal/state unless a separate group/constraint is demonstrated |
| Premature success | dispatch or a single evaluator signal triggers settlement | require decision authority, evidence provenance, and a versioned state transition |
| Bond guarantee | bond/control right said to bound every loss | enumerate limits: appeal, evaluator error, collusion, insolvency, and identity failure |

## Diagrams and references

- [Group and flow modelling graph](diagrams/01-group-flow-model.md)
- [Settlement and dispute state machine](diagrams/02-settlement-states.md)
- [Primary source ledger](references/01-primary-sources.md)
- [First-party proposal boundary](references/02-first-party-proposal-boundary.md)
- [Worked settlement cases](references/03-worked-settlement-cases.md)
- [Market experiments and reputation evidence](references/04-market-experiment-worksheet.md)

## Historical provenance

The original skill and foundations reference are preserved as byte snapshots outside the active bundle. [Preimage record](provenance/ARCHIVAL-MATERIAL.md) provides canonical commit, source path, and SHA-256. This skill makes no Book novelty claim; the separate planning note records one possible explanatory figure question.

## Bundle navigation

[references index](references/INDEX.md).

Files in this skill

  • SKILL.md13.8 KB
  • references/foundations.md3.8 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…