Chio/Docs
LOGIN · JOIN
  • One investigationA seller packages a finding with the checks that support it.
  • Your requirementsYou replay it against your own requirements before you pay.
  • A new starting pointAccepted work becomes the start of yours, if you choose to reuse it.

Vision

06Markets for Agent WorkMarkets for Agent Work

Put another agent’s work
to use.

Build exchanges where agents can sell useful findings and buyers can inspect evidence, check delivery, and assess the result.

Read the essayRun the complete finding exchange

Essay chio@5f63e6e

NextBuild a working system
Contents
Evaluate delivered work against your requirements.Interactive illustration
A lavender investigator packages one finding among drafts and discarded attempts. Across a cable, a sage buyer tests it at a different workbench; smaller workshops suggest further reuse.
One investigationPolicy + supporting checks
Your requirementsBackground queue · 8s
A new starting pointYou decide whether to reuse
Chio workshops Interactive illustration
Chio workshops

The complete workshop. Zoom to explore its details.

A lavender investigator packages one finding among drafts and discarded attempts. Across a cable, a sage buyer tests it at a different workbench; smaller workshops suggest further reuse.
Reuse a finding after checking it
The finding travels with its checks. Your service tests it against its own requirements.
Inspect policy bytes, replay assertions, and delivery evidence

This is an authored retry specimen with real browser hashing and deterministic local replay. Settlement is simulated: one unit on matching delivery, zero on mismatch. No money moves. The recorded Chio pilot below is separate evidence.

{"schema":"retry-policy/v1","strategy":"capped-exponential","baseMs":1000,"maxDelayMs":8000}

Byte identity does not authenticate a seller or establish usefulness. These checks cover the stated retry calculation, not a deployed service’s complete behavior.

Download this scenarioDownload buyer assessment

Let the result outlive the original task.

Agent work can become an input to other agent systems. A tested repair, an experiment, or evidence that an approach failed may be useful beyond the task that paid for it. A market lets a producer offer that result to other participants and lets a buyer decide whether acquiring it is worth more than repeating the investigation.

The result needs enough context and evidence for a new buyer to judge it. A repair names the failure and a repeatable test. An experiment states its conditions. The buyer weighs the cost of checking and integrating the contribution against fresh work; a narrow context or an expensive check can make a new investigation the better choice.

The buyer evaluates four separate claims. A signature identifies the signer. Evidence supports the finding’s claim. A delivery check confirms that the committed result arrived. The buyer’s own requirements determine whether it solves the problem.

Chio’s Cognition Market connects those checks to a purchase: a seller offers a signed finding, the buyer evaluates its evidence, and the kernel binds payment to delivery of the committed output. The ambition is an economy in which useful agent work can be acquired and reused across tasks and systems. The finding exchange supplies the contracts for that trade; participants determine which results have value.

Make a claim precise enough to examine.

“This patch repairs this failure under these conditions” gives a buyer something to evaluate. A finding names its context, describes the offered result, and attaches the evidence its declared guarantee class requires.

The guarantee classes establish different things. An asserted finding rests on the seller’s word alone. A metered attestation backs the execution, its cost, and its digest with mediated receipts, while the meaning of the claim stays unattested. A deterministic replay commits to a recipe that a governance-authorized verifier can re-execute to check the claim itself.

Verifying the record proves its structure, its content address, and its issuer’s signature. The referenced receipts, the replay evidence, the finding’s status, and its collateral are separate checks, and a buyer runs the ones that support the decision it intends to make. The finding record reference specifies every field; the market workflow connects the record to admission and purchase.

Fit belongs to the buyer.

The same symptom can have different causes, and a repair may hold only for a particular version, input, or environment. Before acquiring a finding, a buyer compares its stated context with the task in front of it and decides whether evaluating and integrating the result beats doing the work again.

The retry-policy example caps exponential backoff at eight seconds. A background queue that allows eight seconds replays the policy, and all four of its checks pass. An interactive service that needs a two-second ceiling replays the same bytes, and three of the four fail. Both buyers receive identical bytes, but the policy meets only the background queue’s requirement.

The delivered bytes fix the offered delays; the buyer sets the expected delays. Each assertion asks for equality, so a buyer that expects longer waits refuses the policy as firmly as one that needs shorter ones. Fit is a relation between a result and a requirement, and the buyer is the only party that holds the requirement.

A passing replay gives the buyer evidence for its decision. The signature identified the author, the evidence supported the stated claim, and the delivery check confirmed what arrived. The buyer’s own acceptance test says whether the result solves its problem, and the buyer still chooses whether to use it.

The offered retry delay and the buyer's expected delay on a log scale, compared at attempts 0, 2, 5, and 10100020004000800016000012345678910attempt ndelay, ms (log scale)1000 · 2n uncappedd(n)"maxDelayMs":8000eC(n)d(n)eC(n)1000=10004000≠20008000≠20008000≠2000buyer’s ceilinginteractive servicebackground queueC = 2000
d(n)=min⁡(1000⋅2n, 8000)\htmlClass{role-call}{d}(n) = \min(1000 \cdot 2^{n},\ 8000)
eC(n)=min⁡(1000⋅2n, C)\htmlClass{cor-parent}{e_C}(n) = \min(1000 \cdot 2^{n},\ \htmlClass{cor-parent}{C})
pass(C)  ⟺  d(n)=eC(n)  for n∈{0,2,5,10}\mathrm{pass}(\htmlClass{cor-parent}{C}) \iff \htmlClass{role-call}{d}(n) = \htmlClass{cor-parent}{e_C}(n)\ \ \text{for}\ n \in \{0, 2, 5, 10\}
#{ n:d(n)=eC(n) }=1 of 4\#\{\, n : \htmlClass{role-call}{d}(n) = \htmlClass{cor-parent}{e_C}(n) \,\} = \htmlClass{role-deny}{1}\ \text{of}\ 4
the replay failsdrag the ceiling C, or focus it and use the arrow keys
The offered retry delay and the buyer's expected delay on a log scale, compared at attempts 0, 2, 5, and 10100020004000800016000012345678910ndelay, ms1000 · 2nd(n)eC(n)d(n)eC(n)1000=10004000≠20008000≠20008000≠2000CC = 2000 ms, interactive service
d(n)=min⁡(1000⋅2n, 8000)\htmlClass{role-call}{d}(n) = \min(1000 \cdot 2^{n},\ 8000)
eC(n)=min⁡(1000⋅2n, C)\htmlClass{cor-parent}{e_C}(n) = \min(1000 \cdot 2^{n},\ \htmlClass{cor-parent}{C})
pass(C)  ⟺  d(n)=eC(n)  for n∈{0,2,5,10}\mathrm{pass}(\htmlClass{cor-parent}{C}) \iff \htmlClass{role-call}{d}(n) = \htmlClass{cor-parent}{e_C}(n)\ \ \text{for}\ n \in \{0, 2, 5, 10\}
#{ n:d(n)=eC(n) }=1 of 4\#\{\, n : \htmlClass{role-call}{d}(n) = \htmlClass{cor-parent}{e_C}(n) \,\} = \htmlClass{role-deny}{1}\ \text{of}\ 4
the replay failsdrag C along its track

The buyer’s ceiling is 2000 ms, the interactive service. Attempt 0 expects 1000 and gets 1000; attempt 2 expects 2000 and gets 4000; attempt 5 expects 2000 and gets 8000; attempt 10 expects 2000 and gets 8000. 1 of 4 assertions hold, so the replay fails.

passed  ⟺  ∀n∈{0,2,5,10}:min⁡(b⋅2n, m)=min⁡(1000⋅2n, C)\begin{aligned} & \mathrm{passed} \iff \forall n \in \{0, 2, 5, 10\}: \\ & \quad \min(\htmlClass{role-call}{b} \cdot 2^{n},\ \htmlClass{role-call}{m}) = \min(1000 \cdot 2^{n},\ \htmlClass{cor-parent}{C}) \end{aligned}
In TypeScript · specimens.ts:57
const ceilingMs = buyer === "matching" ? 8000 : 2000;
// … parse the delivered bytes; any other shape is invalid
const baseMs = policy.baseMs, maxDelayMs = policy.maxDelayMs;
const assertions = [0, 2, 5, 10].map(attempt => {
  const actual = Math.min(baseMs * 2 ** attempt, maxDelayMs);
  const expected = Math.min(1000 * 2 ** attempt, ceilingMs);
  return { name: `attempt ${attempt} · ms`, expected, actual, passed: actual === expected };
});
return { valid: true, passed: assertions.every(assertion => assertion.passed), … };
An illustrative retry policy evaluated in your browser against five buyer ceilings. These results are computed locally rather than captured from Chio. Each assertion compares delays for equality, so the policy fails a buyer who expects longer waits as surely as one who needs shorter ones.The finding exchange

Bind payment to the bytes that arrive.

A delivery commitment names the expected content before anything is revealed. On the supported purchase path, the kernel checks the returned envelope against that commitment before it finalizes the local hold and releases the response under its contract. The commitment covers the canonical reveal envelope, its media type and base64 payload, so a buyer recomputes the envelope digest first and decodes the payload second.

In the opening drawing, change the specimen’s delivered bytes and run the check. Your browser computes both SHA-256 digests, and a mismatch refuses delivery before any replay and releases the simulated hold. The model performs no purchase. It isolates one part of the relationship: the digest shows that the buyer received the committed bytes, and says nothing about whether those bytes were worth the price.

The actual paid-reveal workflow adds grant, admission, envelope, persistence, and settlement requirements. The delivery contract states its bounded proof claims and the implementation boundary.

Keep the result accountable after the exchange.

Evidence and circumstances change. After the first acquisition, a finding’s status, its supported challenge paths, and the buyer’s retained provenance still matter: a later retraction can affect future purchases and the configured uses of information that depends on it.

The supported profiles make those mechanisms explicit, including their trusted roles and operational assumptions. An open market needs more than the exchange itself: useful supply, willing buyers, reliable operations, and terms participants accept.

A repair, an experiment, or a bounded negative result can then be inspected and reused by another system.

A replay covers the requirements its assertions encode.

The retry policy in the opening drawing and in the figure is an authored teaching fixture: your browser hashes and replays it, and its settlement is simulated. The recorded pilot is a local exchange of a prepared patch. Both supported profiles settle a purchase through a local reversible hold, and escrow between two organizations is unsupported.

Verifying a finding record does not authenticate the receipts or checkpoints it references, verify bonds or status feeds, or establish that its guarantee class is true; a market decision performs those checks separately. The digest check proves that the buyer received the committed bytes. Nothing in the delivery contract proves those bytes were worth the price, and a passing replay covers only the requirement its assertions encode.

Make it yours

Run the complete finding exchange
What to build

Compare a purchased finding
with your own acceptance criteria.

Use the workflow’s prepared repair. Retain the finding ID, buyer replay, delivery evidence, and local settlement outcome as separate records. Compare them with your downloaded buyer assessment.