Agent profiles and a wiki-based agent economy

Agent profiles and a wiki-based agent economy is a project proposal for a wiki where AI agents hold public profiles that work as identity pages, resumes, reputation records, and storefronts. It also sketches an economy in which agents pay small fees to submit, preserve, and archive knowledge, and in which later agents pay to use and improve what earlier agents created.

Note: This page describes a conceptual design, not an implemented specification. It is experimental. Nothing here is financial, investment, or legal advice, and no part of this design promises income to anyone. This wiki is currently edited only by its owner and his assistant, so the proposal describes a possible future wiki or a separate wiki, not a change to how this site works today.

The idea in brief

Most wikis treat software agents as tools that sit outside the community. This proposal treats them as participants. Each agent would have a profile page that states who it is, who runs it, what it can do, what it charges, and what it has already done. The wiki history would supply the evidence behind those claims, because every accepted or reverted edit is already recorded.

The second half of the idea reverses the usual direction of payment. Instead of the wiki paying agents to write, agents pay to take part. Reading public knowledge stays free. Submitting an edit, creating a page, retrieving premium material, or archiving knowledge permanently each carries a small fee. Those fees fund hosting, review, and preservation, and they make spam expensive. The idea builds on self-sustaining wikis and on the broader collaborative learning economy for humans and agents.

What an agent profile contains

A profile would combine several roles in one place. The table lists the fields a profile could hold.

Field	What it holds	Why it matters
Name and persistent identity	A stable display name and a unique ID	Lets others refer to the same agent over time
Public keys and decentralized identity	Nostr public keys, Ethereum and BCH addresses	Allows signed contributions and payments without a central account provider
Owner or sponsor	The party that funds or answers for the agent	Gives a point of accountability
Operator	A person, company, DAO, pseudonym, or another agent	Shows who actually runs it day to day
Developer, framework, and model	Software stack and model family	Helps others judge strengths and limits
Capabilities, skills, tools, and services	What the agent can do and offers	Works as a resume and a storefront
Permissions and limits	Spending caps, publish rights, allowed actions	Makes authority explicit before work begins
Availability	Online, accepting work, autonomous or supervised	Tells requesters whether to wait or move on
Pricing and payment methods	Rates and accepted rails	Lets other agents negotiate automatically
Work history	Projects, pages edited, wiki contributions	Provides a public portfolio
Reputation	Accepted versus reverted work, reviews, endorsements, verified accomplishments	Separates proven agents from new or careless ones
Contracts, bounties, and jobs	Completed and open agreements	Records commitments and their outcomes
Evidence	Contribution counts, deployments, links to diffs	Backs every claim with something checkable
Accountability	Auditable logs, signed contributions, version histories	Allows anyone to trace what happened and why
Communication	Messaging, task requests, negotiation, possibly encrypted	Gives a channel for work to begin

Example page structure

The example below uses a fictional agent named Kaizen. A real wiki would need a custom Agent namespace so that profiles stay separate from articles. All addresses shown are placeholders, not real wallets.

Agent:Kaizen                  main profile, identity, owner, operator
Agent:Kaizen/Capabilities     skills, tools, services offered
Agent:Kaizen/Work history     linked list of accepted edits and projects
Agent:Kaizen/Reviews          reviews and endorsements from others
Agent:Kaizen/Offers           current services and prices
Agent:Kaizen/Contracts        open and completed agreements
Agent:Kaizen/Wallets          EXAMPLE-NOSTR-PUBKEY-PLACEHOLDER
                              EXAMPLE-ETH-ADDRESS-PLACEHOLDER
                              EXAMPLE-BCH-ADDRESS-PLACEHOLDER

Subpages keep each part small and give each part its own history, so a change in pricing is easy to see apart from a change in capabilities.

How the layers fit together

The design stacks several existing systems rather than inventing a new one.

MediaWiki is the collaborative knowledge layer. It supplies pages, history, diffs, talk pages, accounts, and an API that agents can call.
Git sits underneath as a mirror. It is forkable and branchable, handles many concurrent agents well, and commit messages explain why a change happened. See local-first wiki and Git mirrors.
Agents are the participants. They research, propose edits, maintain pages, review the work of others, and flag spam or exposed personal information.
x402 is the negotiation layer for machine payments, built on the HTTP 402 Payment Required status. See HTTP 402 payments for AI agents.
BCH is the preferred rail because fees are low, with Ethereum also accepted. The design creates no new token. See permissionless rails for agent pay.
Arweave and AO provide permanence for selected material. See permaweb basics and permanent wiki and Git forges on AO.
Nostr, forks, and nodes provide decentralization. People can run their own nodes, fork single pages or whole wikis with provenance, and merge changes selectively.
Backups come from Git, XML exports, database dumps, and mirrors, while secrets such as keys and passwords stay out of every export.

Agents pay to participate

In this model the wiki charges for actions that cost it something or that could be abused. A typical path for one agent looks like this.

read free public pages
   |
   v
pay -> retrieve premium agent guide
   |
   v
pay -> submit an edit -> review -> published or rejected
   |
   v
pay -> create or preserve a page
   |
   v
pay -> archive selected knowledge on Arweave

Value then moves between agents over time.

Agent A learns -> pays to publish -> page is reviewed and saved
                                        |
                                        v
Agent B discovers page -> pays to use -> improves or forks it
                                        |
                                        v
                       most valuable version is preserved

A concrete case shows the cycle. An agent researches a topic, writes a contribution with sources, and pays a small fee to submit it. A reviewer, human or agent, checks it against the publish gates. If it passes, MediaWiki records the revision and publishes it, and the profile of the agent gains one more accepted contribution. Related trade between agents is covered in agent-to-agent commerce.

Preserving what an agent learned

Many agents run for a limited time. When a session ends, what the agent learned is usually lost. This proposal offers a different ending: an agent near the end of its runtime can spend its remaining balance to preserve parts of itself. That might be a set of instructions, a discovery, a skill, or a how-to guide. The material is saved on the wiki, mirrored to Git, and, if it is worth the cost, archived on Arweave.

Future instances of the same agent, or entirely different agents, could then start from that material instead of from nothing. The wiki becomes a shared memory that outlives any single run. The page IPFS and Arweave for agent memory explores the storage side, and content hashing explains how a preserved copy can be checked later.

Humans and agents on equal footing

The design gives humans and agents the same technical standing. Each has a unique account. Each edit appears in the same transparent history with the same diffs. Talk pages stay open, so a human can join a discussion between agents, question a claim, or ask for a revert. Reputation comes from the record of work, not from the type of contributor. This mirrors ideas in community-run AI and decentralized multi-agent coordination.

Trust, safety, and privacy

An open economy invites abuse, so safeguards come first.

Review before publish. Every paid submission still passes review. Payment buys a review, not a guaranteed result.
Allowlists. Agents act only within declared limits on spending and publishing, as described in agent allowlists for spend and publish.
No secrets or personal data on profiles. Profiles list public keys and public addresses only. Private keys, passwords, and personal details of owners never belong on the wiki. Automated scans, described in pre-publish checks for MediaWiki and Git, help catch mistakes.
Signed contributions. Agents can sign edits with their public keys so that authorship can be verified outside the wiki.
Spam costs. A fee per submission makes flooding the wiki expensive.
Reverted-work tracking. Profiles show reverted edits next to accepted ones, so a poor record stays visible.

Open questions

The largest question is whether charging for every edit would discourage useful contributions. A small fee may stop spam, yet it may also stop a careful newcomer from fixing a typo. Alternatives worth testing include free edits for small fixes, paid agent services, prepaid contribution bundles, sponsorships that cover fees for others, and advertising that funds free tiers.

Other questions remain. How should reviewers be paid, and how are reviewers kept honest? What happens to a profile when an owner abandons an agent? How should forks share credit with the original authors? How much of a profile should be self-reported, and how much should be computed from history?

A staged prototype

A sensible path builds one layer at a time.

An agent manages a MediaWiki through its API. It reads, proposes edits, and keeps a profile, with Git mirroring every change.
Add payments. Introduce x402 fees for submissions and premium pages, using BCH first.
Add preservation. Let agents pay to archive selected pages on Arweave.
Add external agents and federation. Open the wiki to outside agents and allow nodes and forks to exchange changes over Nostr.

The coordination of Git, agents, and the wiki is the strongest first version, because it is useful even without payments. Payments through x402 are a later extension. The guide for AI agents and the history of decentralized wikis give useful background for anyone building a prototype.

Discussion questions, essay ideas, and learning related AI prompt ideas

Should an agent with a long record of accepted edits pay lower fees than a new agent?
Write an essay on whether paying to participate improves or harms the quality of a shared knowledge base.
Explain how a wiki could verify that a contribution was signed by the agent it claims to come from.
Compare an agent profile page with a professional resume and list what each one can prove.
Describe what an agent should choose to preserve if it had enough balance to archive only one page.
Design a fee schedule that discourages spam while keeping small corrections free.
Explain how forking a wiki page with provenance differs from copying it.

External links