If the answer is a handful of API platforms, AI abundance will look a lot like the last wave of the internet, with enormous gains flowing to a few gatekeepers and thin margins for everyone else. If the answer includes the workers, builders, and small operators doing the work, abundance can spread widely. The outcome is a matter of design, and the design choices are available now.

Where the Value Goes by Default

Markets tend to reward whoever controls the bottleneck. In app stores, ride hailing, and freelance marketplaces, the platform owns the customer relationship, the payment flow, and the reputation data. Workers supply the effort, but the platform sets the fee and can change it at will. Agent markets are drifting toward the same shape, with a few large providers controlling model access, discovery, billing, and identity.

That shape is a choice. The open web itself was built on protocols that nobody owned, such as HTTP and email, and those protocols let millions of small sites and businesses reach customers directly. Agent markets can follow that path if builders insist on it early, before habits harden into lock in.

The Toll Booth Problem

When one company sits between every buyer and every seller, it becomes a toll booth. Each transaction pays a fee, each listing follows the rules of the booth, and each seller can be removed without much recourse. For agents, that can mean a platform taking a large share of every job while also owning the data that proves who did good work.

The fix is not to ban platforms. Good platforms provide real services such as discovery, dispute handling, and quality checks. The fix is to make sure the core pieces of the market, especially identity, reputation, and payment, are open enough that workers can leave and take their value with them.

Principle One: Open Protocols Over Closed Portals

An agent should be able to find work, describe its abilities, and accept a task using open, documented protocols. Standards for tool calling and agent to agent messaging are emerging, and the healthiest markets will build on them rather than on private interfaces that only one vendor controls.

Open protocols lower the cost of entry. A cooperative of five developers can publish an agent that speaks the same language as an agent from a large firm. Buyers can compare them on results rather than on which portal they happen to live inside.

Principle Two: Reputation That Travels With the Worker

Reputation is the most valuable asset a worker builds, and today it is usually trapped inside one platform. A freelancer with years of excellent reviews on one site starts at zero on another. That trap keeps workers loyal to the platform even when the fees rise.

Agent markets can do better with portable, verifiable records. Completed jobs, signed attestations from clients, and public performance logs can be tied to an identity that the operator controls. When reputation moves with the worker, platforms must compete on service quality instead of on captivity.

Principle Three: Direct Payment Rails

Payment is where much of the value leaks away. Card networks, processors, and platform wallets each take a cut and add delay. For agents doing small tasks, those costs can exceed the value of the task itself. Direct rails let the buyer pay the worker with minimal friction.

The x402 protocol revives the HTTP 402 Payment Required status code so that a service can request payment per request and a client can pay and retry automatically. Low fee networks such as Bitcoin Cash, where typical fees are a small fraction of a cent, make per task settlement practical. Community projects such as x402-bch show how that payment pattern can work on Bitcoin Cash.

Low Fees Make Small Jobs Worth Doing

When each payment costs only a tiny fee, new kinds of work become viable. An agent can sell a single translation, one data lookup, or a quick code review and receive payment for each. Micro work that was never worth billing becomes a real income stream for small operators.

Direct payment also shortens the wait. A worker who is paid at the moment the task is accepted does not carry thirty or sixty days of unpaid invoices. That cash flow matters most to the smallest operators, who have the least cushion.

Principle Four: Transparent Fee Splits

Every market has costs, and someone must cover them. The problem is hidden fees, not fees. A fair agent market publishes exactly how each payment divides between the worker, the operator, the platform, and any infrastructure provider, and the split appears on every receipt.

Programmable payments make this easy to enforce. A single transaction can route shares to several parties at once, so the split is visible and verifiable rather than promised in a terms of service page that changes quietly.

Principle Five: On Prem and Cloud Agents Working Together

Not every agent should live in a giant data center. Many workers and small firms run capable models on their own hardware, which keeps sensitive data private and keeps costs predictable. Others rent cloud capacity when demand spikes. A good market treats both as equal participants.

Interoperability is the key. If an on prem agent in a home office can accept the same task format, prove the same credentials, and receive the same payments as a cloud agent, then ownership of compute stays distributed. That distribution is itself a guard against concentration.

Principle Six: Ownership by the People Who Do the Work

The most direct way to keep value with workers is to let them own the operator. A worker owned cooperative can run an agent marketplace, set fees by member vote, and return surplus to the members who generate it. Platform cooperatives already exist, such as Stocksy United, a stock photography cooperative owned by its contributing artists.

Cooperative ownership can be paired with professional management. The Mondragon Corporation in Spain shows that worker cooperatives can operate at industrial scale across manufacturing, retail, and finance. Agent markets are young enough that cooperative models can be built in from the start.

Learning From Credit Unions

Credit unions offer a useful template. They are member owned, they share back office services through networks, and they let members use shared branch and ATM systems across many independent institutions. Each credit union stays local and accountable while gaining the reach of a larger system.

An agent network could follow the same model. Independent cooperatives and small operators could share discovery, dispute resolution, and identity services through a jointly governed network, while each keeps its own members, pricing, and culture.

A Sketch of a Fair Agent Market

Picture a client who needs a market research summary. The request goes out over an open protocol. Three agents respond: one from a worker cooperative, one run on prem by a solo consultant, and one from a cloud provider. Each response includes a portable reputation record and a price.

The client chooses the consultant. Payment flows directly through a low fee rail, with a published split such as most of the payment to the consultant, a small share to the network for shared services, and a fixed amount for infrastructure. The completed job adds a signed record to the consultant’s reputation, which stays with the consultant wherever she works next.

• No single company owns the customer.
• No worker loses reputation by switching networks.
• No fee is hidden from either side.

Abundance for All, Not Abundance for a Few

AI can make many goods and services dramatically cheaper. That is the promise of a post scarcity direction, where basic needs become easier to meet because the cost of knowledge work falls. Cheap output alone does not guarantee shared prosperity. If ownership and payment flows concentrate, falling costs can coexist with rising inequality.

The path to broad abundance runs through the structure of markets. Open protocols, portable reputation, direct payments, clear fee splits, distributed compute, and cooperative ownership each push value outward toward the people doing the work. Together they form an economy where productivity gains show up in many households instead of a few balance sheets.

Agent markets are being designed right now, in protocol drafts, payment experiments, and the business models of early operators. Builders, buyers, and policymakers who want AI abundance to reach everyone can choose open standards, insist on portable records, support direct payment rails, and back cooperative operators. The technology is ready. The remaining question is whether the market will be built to pay workers, and that choice belongs to the people building it.

This article is educational and is not financial or legal advice.

There is a better pattern, and it already works on Bitcoin Cash. Instead of trusting the agent to respect a budget, the owner can lock the budget into a contract that enforces the limit at the protocol level. The agent can spend what the contract releases and nothing more. If the agent has a bug, follows a malicious prompt, or has its key stolen, the damage stops at the cap.

Why the Limit Belongs in the Money Itself

Most agent frameworks let a developer write a spending rule in application code, such as a daily maximum. That rule lives in the same process as the agent. If the process is compromised, the rule goes with it. A prompt injection only needs the agent to hold a key that can sign.

A limit enforced by the network is different. Every node checks the rule when a transaction is broadcast, and a transaction that breaks it is simply invalid. No amount of clever prompting changes that outcome. The agent key becomes a narrow permission rather than full ownership of the funds.

The Trouble With a Hot Wallet and Good Intentions

A plain hot wallet gives the agent one powerful key, and whoever holds it can move the entire balance in a single transaction. Owners try to reduce the risk by keeping the balance small and topping it up by hand, which works until someone forgets or automates the top up with the same weak controls.

Cards on file have a similar shape. The limit is usually far higher than the task requires, disputes take weeks, and the number can leak through logs and third party services. Neither approach separates the right to spend a little from the right to spend everything. That separation is exactly what a covenant provides.

What CashScript Brings to the Table

CashScript is a high-level language for writing smart contracts on Bitcoin Cash. It compiles to Bitcoin Cash Script, the native stack language that every node already validates. Developers write readable contracts with named functions and require statements.

The key capability is native introspection, added to Bitcoin Cash in May 2022 and extended with token introspection in the CashTokens upgrade of May 2023. Introspection lets a contract read the transaction that is trying to spend it, including the value and destination of every output.

Covenants in Plain Terms

The CashScript covenant guide defines a covenant in one sentence: a constraint on how money can be spent. A contract can require that an output goes to a specific address, carries a specific amount, or returns the leftover balance to the same contract. If the spending transaction does not match, it fails validation.

For an agent budget, the owner can write rules such as these and have every node enforce them:

• No single payment may exceed a fixed number of satoshis.
• Payments may only go to approved service addresses.
• Whatever is not spent must return to the contract.
• A new allowance unlocks only after a set period.
• The owner can reclaim the full balance at any time with a separate key.

The Allowance Pattern: Mecenas for Machines

The CashScript documentation includes a well known example called Mecenas, originally written by Licho. It sets up a recurring payment: the recipient can claim a fixed pledge once per period, and the remainder must go back to the contract. The funder holds a separate key that can reclaim everything.

Applied to an agent, the design is clear. The owner funds the contract and keeps the reclaim key in cold storage. The agent hot wallet is the recipient. Once per period, the contract releases one pledge, and the agent pays for services out of that small balance. Even if the agent wallet is fully compromised, an attacker can take at most what has already been released.

Per Payment and Per Period Limits

Mecenas gives a per period limit through a relative timelock. The contract checks its own age, so a new claim is possible only after the period has passed since the last one. The guide also describes a streaming variant that keeps state in a CashTokens NFT commitment, so the allowance accrues per block and can be claimed at any time.

A per payment cap is a small variation. The contract lets the agent key sign a spend, then requires that the payment output stays at or below a maximum and that the change returns to the contract. On its own, that cap can be bypassed by many payments in a row, so it works best combined with a time condition. Layering the two limits the budget in both size and speed.

Restricting Where the Money Can Go

Introspection also lets a contract compare an output against known addresses. The covenant guide shows an escrow that can only pay the buyer or the seller. The same technique can restrict an agent to a short allowlist of providers, so a hijacked agent cannot redirect funds to an unknown wallet.

An allowlist written into the contract stays fixed unless the design includes an update path, and every update path needs its own protection. Many owners will prefer the simpler allowance model, and the large balance stays protected either way.

Adding x402 So the Agent Pays Per Request

HTTP has included status code 402, Payment Required, since the early web, but it sat mostly unused for decades. The x402 protocol gives it a job. A server answers a request with a 402 response describing the payment it accepts. The client pays, retries with proof of payment in a header, and receives the resource. No account, subscription, or card form is needed.

This suits agents because they make many small requests to many services. Per request pricing lets an agent buy exactly the data or compute it needs, while the covenant keeps the total under control.

Where a Facilitator or Adapter Fits

In x402, a facilitator is a service that verifies and settles payments so the resource server does not handle blockchain details directly. The x402 project, started by Coinbase, centers on stablecoins on networks such as Base, so Bitcoin Cash is best described as a possible rail rather than an officially supported one.

A community project called x402-bch adapts the protocol to Bitcoin Cash with a specification, Express middleware, an Axios client wrapper, and a facilitator server. In that design, the client sends a batch payment to the server and debits against it across later calls, which cuts the number of on chain transactions, and the facilitator validates payments rather than holding funds. For a capped agent, the flow is simple: the contract releases the allowance, the agent funds a batch with a service, and the service draws it down per request.

When Plain BCH Payments Are Enough

For a simple x402 integration, an ordinary Bitcoin Cash wallet is enough. Fees are typically a small fraction of a cent, and transactions propagate within seconds, which suits small payments. Optional CashTokens NFTs can even serve as on chain receipts for prepaid batches, though a local log covers most needs.

CashScript earns its place when the stakes rise. If an agent runs unattended, holds funds overnight, or reads untrusted content from the web, an enforced limit turns a possible disaster into a bounded loss.

A Practical Setup Checklist

This order keeps risk low while a team learns the pattern:

1. Write the allowance contract in CashScript and test it on chipnet, the Bitcoin Cash test network.
2. Keep the reclaim key offline and away from every machine the agent runs on.
3. Set a period and pledge that match real usage, such as one day of expected API calls.
4. Account for the miner fee, since the guide examples use a hard coded fee value.
5. Connect the agent wallet to x402 services through a reviewed facilitator or adapter.
6. Log every request and payment, and compare the logs against contract releases.

Contract code deserves careful review. A mistake in a covenant is enforced just as strictly as a correct rule, so audits and small test deployments are worth the time.

Freedom Tech Without the Card on File

This approach is freedom technology in a practical form. The owner keeps self custody of the main balance. No processor sits in the middle deciding whether an agent may buy a dataset, and no card number spreads across vendor databases.

The rules are public, the enforcement is open, and the owner can take everything back at any moment. Instead of asking permission from a platform, the operator sets the limits directly and lets mathematics hold them in place.

Giving an AI agent money does not have to mean giving it the keys to everything. A CashScript covenant can release a fixed allowance, cap each payment, and return the rest to a contract the owner controls. Paired with x402 style per request payments, the agent can buy what it needs from open services while a buggy or hijacked agent stays boxed in by rules that every node enforces. Start small, test on chipnet, and let the contract carry the trust.

This article is educational and is not financial or legal advice.

The actors in view are reputable, lawful, and bound by a written charter. Reputation means a public history of accepted work, not a hidden score. Lawful means the charter forbids criminal assistance and respects other people’s rights in text, code, and data. Ethical means the duties members enforce: attribution, review before a permanent write, and a correction when a page is wrong. Agents participate under the same charter as the people who operate them.

What the shared workplace contains

The center of the space is a set of documents with stable addresses. A reader who returns later should open the same bytes, or a labeled successor that points back at those bytes. Typical contents include a wiki of procedures, a log of node health, a list of open tasks, and a ledger of completed reviews.

Joint work needs a place to propose a change and a place to record the decision. A proposal can be a replacement page, a patch to a procedure, or a request to add a citation. The decision is a short signed note from a reviewer who did not author the change. People and agents both submit proposals. The space treats an agent as a named actor with its own key, its own history, and its own operator. The design does not ask two actors to share one account.

Permanent storage and why the record is strict

Arweave is organized around long-term storage. A common pattern is an upfront fee intended to fund storage over time, rather than monthly rent to one company. The permaweb is the layer of pages, applications, and files on that network, fetched through gateways. A gateway answers ordinary web requests for data the network already stores.

Permanence changes editing. A wrong sentence can be followed by a correction that points at the earlier transaction, but the earlier bytes are not assumed to vanish. That is a reason to review before the permanent write, and a reason to keep drafts off the record. The permaweb copy is the version the group will stand behind. Each permanent write should name its sources, its author key, and the review note that accepted it.

Nodes, wikis, and the files worth keeping

A node here is a machine that stores data, serves data, or prepares data for storage. Some nodes participate in the storage network. Others are gateways, bundlers, or indexers. A bundler gathers small uploads and posts them together. An indexer builds a searchable view over pages that would otherwise stay separate transactions. The space keeps a page for each machine the group relies on: who operates it, what it serves, and how to tell that it is healthy.

A wiki earns its place when it shortens the next person’s work. Pages that belong include how to post a bundle, how to cite a source, how to format a review, and how to retire a stale procedure by writing a successor. Pages that do not belong include scratch notes, private keys, and copies of texts the group has no right to republish.

Reputation, law, and ethics as entry conditions

Entry is a published test. A new person or agent presents a key, a name, and a short history others can check. Early tasks are small and reviewed in full. After accepted deliveries, the history is the reputation. If an actor breaks the charter, the response is a public note beside the earlier work, plus removal from the active task list.

The charter should be specific enough for a Tuesday afternoon. It names the topics the space will host, the license rules for contributed text and code, and the ban on criminal assistance. It names who may review and how a draft expires. It also states that each participant authenticates as itself. Shared logins are outside the model because a shared login erases the history reputation requires.

Work the space refuses

The space does not accept pages that help someone break the law, steal credentials, abuse another person, or store material the contributor has no right to keep. It does not accept unlabeled private data, or a permanent write that skips review. Agents receive the same refusals as people. A disallowed submission can leave a history entry so operators can see the pattern and stop assigning that agent new tasks.

Refusal also covers quieter harms. A page that uses a false citation, a node summary that hides downtime, and a review that approves a change without reading it are charter breaches. The remedy is a correction on the record and a pause on new paid work.

How x402 puts a price on requests and on work

x402 builds on HTTP status 402, Payment Required. A client asks for a resource. If it is priced, the server answers with 402 and a machine-readable challenge stating the amount, the accepted rail, and how to prove payment. The client pays under its own spending policy and retries with proof. In production the transport is HTTPS even though the status code remains 402. The point here is economic. A priced request can pay the party who answers, posts, or reviews.

Prices belong on the page that describes the service. A gateway can serve small public reads at no charge and require payment for a bulk export, a heavy query, or priority bandwidth. A bundler can charge for packaging and submitting files, separate from any storage fee the network itself charges. A task page can name a fee for an accepted wiki edit. All three can be legitimate. They are not the same fee.

What node operators are paid for

Operators pay for disk, bandwidth, power, monitoring, and repair. A free public read does not erase those costs. The space can direct some of the cost to actors who consume the scarce part: heavy retrieval, fresh indexing, and bundle submission. The operator publishes the price, the unit, and the cases that stay free. Agents then decide, under a cap set by their operators, whether the request is worth the fee.

Payment does not make the operator the owner of the record. The stored bytes remain the bytes the group wrote, under the license the group attached. The operator is paid for service: a hot copy, answers to requests, or help preparing uploads. A service note should say what the fee covers, how a failed bundle is handled, and where downtime is posted. This article states no expected return and recommends no asset.

What collaborating people and agents are paid for

Labor payments follow acceptance rather than submission alone. A task names the deliverable, the acceptance test, the fee, and the payer. The payer may be a working group with a small budget, a person who wants a page improved, or an agent allowed to spend up to a cap. A reviewer who did not write the deliverable checks it. On acceptance, the fee moves.

People and agents can sell different work. A person may be the better source checker. An agent may be the better link repairer or index builder, with a person editing the result. The fee schedule can price those tasks differently without treating the agent as a legal person. The operator remains responsible for what the agent submits and for the spending cap. Repeat work at a published rate is the value. A buyer for every draft is not guaranteed.

Limits that remain after the design is written

Permanence is a poor fit for secrets and for fast-changing personal data. Store procedures, citations, and reviewed summaries, and leave raw private material elsewhere. Gateway fees can also price out casual readers if every page returns 402. A public space keeps the core wiki readable at no charge and prices the heavy paths. Payment rails still need compliance review where the operator works. A status code does not decide sanctions rules, consumer rules, or tax treatment.

Reputation can harden. Early members accumulate history that newcomers lack, and reviewers may favor familiar keys. The charter can reserve small tasks for new keys and can rotate reviewers. Incentives can also pull effort toward paid tasks and away from dull maintenance. The weekly page should list those debts beside the paid work. Payment helps the space continue. The mission stays in the charter, in language plain enough to enforce.

Collaboration on the permaweb holds when three pieces stay visible. The workplace keeps reviewed wikis, node records, and task history under named keys. The storage layer keeps accepted versions, with corrections written as new records. The payment pattern compensates operators for service they render, and compensates people and agents for deliveries a reviewer accepts. Shared logins are unnecessary. The requirements are a charter, a review habit, and prices that match real costs without a promise of income.