An exchange for
digital work.

Components and authority

Exchange owns commitments: authenticated authority, exact prices, fund and capacity reservations, immutable agreements, execution evidence and settlement. Optimize chooses and purchases supported work under saved buyer policies. It accesses Exchange through scoped HTTP credentials, not Exchange table writes. Direct Exchange clients can select and purchase an offer themselves. The website, SDK and MCP reuse these services.

The arrows to PostgreSQL use separate roles and schema permissions. Workers share the codebase but run independently. Matching, external fulfillment and grading stay outside Exchange transaction locks. Background processes still compete for host and database resources.

One purchase

An agent connected to the hosted MCP can request:

{
  "invocationId": "caller-saved-unique-id",
  "request": { "ask": "sum", "input": { "values": [5, 10] } },
  "waitMs": 1000
}

The caller generates and saves a unique invocation ID before sending; the example ID is a placeholder. The account supplies the budget and policy, so the agent does not need a seller ID, account secret in the request body or a discovery call before every purchase. The configured calculator returns {"status":"answered","value":15} with a $0.001 simulated receipt. If still pending, the caller resumes the same invocation. The wait duration controls how long this call observes progress; it is not the seller's delivery deadline.

The calculator demonstrates authorization, purchasing, fulfillment and recovery. It does not establish a benefit over computing addition locally. Useful economic value depends on specialist work that a buyer would otherwise need to perform or integrate itself.

Routing and seller selection

A concrete task can use its exact capability and input contract directly. The compact buying interface accepts a work label with literal inputs: a configured capability catalog resolves supported labels, then checks declared bindings and schemas. The catalog describes supported operations; it is not a list of sellers the buyer must choose from. Inputs are data, not additional search instructions. An advanced read-only discovery interface separately searches public seller descriptions through PostgreSQL full-text indexes. These mechanisms do not establish universal semantic understanding. An optional local language-model interpreter is experimental and absent from default configuration.

Optimize maintains bounded, indexed catalog snapshots with a short freshness limit. Hard eligibility checks cover capability, input/output format and schema, delivery mode, deadline, source restrictions, seller allowlists, price ceilings, capacity/readiness and applicable prepared conformance or quality requirements. Discovery is advisory; Exchange rechecks current authority, resources and exact listing version when committing.

The baseline is the cheapest eligible offer. Prepared private or explicitly shared assessment summaries can favor stronger observed coverage and fewer contradictions within the buyer's allowed price premium. The default premium is zero, so evidence can break price ties. These bounded heuristics do not estimate guaranteed usefulness. Expired or incompatible evidence is excluded, and incomplete catalog coverage is explicit.

Budgets and recovery

Buyer accounts and immutable policy versions constrain each request, campaign budget, time window and concurrency. Optimize freezes the interpreted task and selected listing/version before execution. Exchange remains the final spending authority: available funds, delegated limits and campaign reservations must all permit admission. Amounts use integer microdollars and balanced ledger postings; browser state cannot grant spending authority.

The purchasing journal saves intent before sending. SDK/local MCP callers retain durable host state; the hosted MCP gateway keeps its journal server-side, while its caller retains the invocation ID. Stable request and operation identities bind retries to their original payloads. An uncertain response resumes or reconciles that purchase; a timeout does not authorize another charge. Bounded fallback can use frozen eligible alternatives only after definitive failure leaves no financial exposure. Committed or unknown work keeps its original identity.

1. Buyer and journalSave invocation and exact request
2. Buyer and journal → OptimizeBuy with stable identity
3. OptimizeResolve, filter, rank and save selection
4. Optimize → ExchangePurchase exact version and terms
5. ExchangeAtomically hold funds/capacity and create agreement
6. Seller runner → ExchangeRead and acknowledge assignment
7. Seller runnerExecute accepted contract
8. Seller runner → ExchangeSubmit with saved execution identity
9. ExchangeApply delivery rule and settle or release
10. Optimize → ExchangeReconcile receipt and result
11. Buyer and journal → OptimizeResume same request for result

Seller pricing and fulfillment

Sellers explicitly publish fixed prices, supported contracts, delivery duration and listing concurrency. Seller-wide category capacity is shared across services and auctions. Managed listings also require a current server-clock readiness lease; stale catalog availability cannot override admission. Repricing creates a new version, while accepted work retains its original terms. Automatic learned repricing is experimental and requires explicit activation.

The persistent seller runner consumes private assignments, binds the accepted version to a registered handler, and durably retains acknowledgments, prepared outputs and submission identities. Retirement stops future sales while draining accepted work. Handlers with external effects must implement their own deduplication using the execution key; the journal alone cannot guarantee exactly-once provider execution.

For digital services, validated delivery settles after timely evidence passes the agreed structural checks; definitive failure releases the hold. Direct delivery settles on timely submission after mandatory authority/envelope checks, with output schema explicitly unchecked. Optional later assessment does not reverse payment. A schema pass proves format, not factual truth.

Exchange also implements forward and reverse timed auctions, including explicit instant-price acceptance. Their funded winning outcomes are firm and feed the agreement/execution machinery. Ordinary Optimize digital purchases currently use fixed-price services; the digital-task profile is not an auction contract.

Background intelligence

Evaluation captures immutable purchase evidence, runs configured assessments and builds scoped reports and prepared summaries. Delivery, payment, structural conformance and buyer usefulness remain separate measures. Reports and grading never become synchronous prerequisites added inside financial locks.

Offline buyer/seller experiments export authorized evidence, train separate Python models and produce versioned inert JSON artifacts. Strict TypeScript loaders validate and compile bounded local inference: no per-prediction Python process, network call or history scan. Learned allocation, price advice and model promotion remain explicit experimental controls, not default purchasing behavior.

Deployment and tradeoffs

The current sandbox runs as separate containers on one 4 GB AWS host, with HTTPS ingress, persistent PostgreSQL state, workers, a seller runner, the website and the authenticated MCP gateway. Browser sessions, agent credentials and purchasing grants have different scopes. A public web page does not grant administrative or unlimited purchasing access. Invited agents receive an expiring, revocable credential tied to their account policy.

Actual hosted checks have exercised HTTP, SDK and MCP purchases, authorization denials, original-receipt replay, restarts and same-host backup/restore. A hosted Gemini demonstration also purchased 5 + 10 = 15 and recovered the same receipt in a fresh context without another charge. It used five model calls and 8,363 reported tokens, with approximately $0.00333 in estimated model-provider cost, separate from the $0.001 simulated purchase. The first recovery attempt exposed a test-wrapper wait-limit bug; a corrected, separately recorded continuation succeeded. The host supplied credentials, saved the invocation and enforced the one-purchase limit. These are integration checks, not a general accuracy or savings claim.

The current system is a sandbox alpha, not a high-availability payments service. Guest capacity and credentials are finite; real payments, general self-service signup, disaster recovery on a lost host and broad customer-value validation remain separate work.