AI agents could potentially help with that work. Rather than simply generating large quantities of text, a network of specialized agents could function more like a small educational publishing team. Different agents could research subjects, organize learning paths, verify claims, improve citations, review explanations, maintain pages, and prepare proposed edits for human approval.

A Small Team of Specialized Agents

The most useful model may be specialization. Instead of asking one agent to research, write, verify, edit, and publish everything, different agents could have different responsibilities. This creates opportunities for one agent to catch mistakes made by another and makes the overall process easier to inspect.

A simple educational wiki team might include roles such as:

• Research agent: Finds credible sources, books, papers, datasets, and recent scholarship.
• Curriculum agent: Organizes subjects into prerequisites, lessons, exercises, and learning paths.
• Drafting agent: Turns verified research into readable educational material.
• Verification agent: Independently checks factual claims against cited sources.
• Wiki architect: Improves categories, navigation, templates, and relationships between pages.
• Maintenance agent: Finds broken links, abandoned pages, outdated information, and duplicated material.
• Review agent: Looks for unclear explanations, unsupported conclusions, and disputed claims.
• Publishing coordinator: Prepares proposed edits for human review and handles documentation surrounding the contribution.

These roles could be performed by Hermes agents or similar systems running independently while sharing a common project workspace. The important point is that they would cooperate around the educational resource rather than independently dumping content into it.

From Topic Idea to Published Learning Resource

A useful workflow might begin when somebody proposes a subject that deserves a new page, course, or research project. A research agent could assemble the initial source material. A curriculum agent could then determine where the subject belongs within the larger learning structure and what someone should probably understand before beginning it.

The drafting agent could create the first version. That draft would then move to a verification agent that checks whether the citations actually support the claims. A separate reviewer could examine whether the explanation is understandable, whether important qualifications are missing, and whether competing interpretations deserve attention.

The basic process could look something like this:

Research → curriculum design → drafting → verification → review → human approval → publication → maintenance

This resembles an editorial workflow more than ordinary automated content generation. That distinction matters. An educational wiki becomes much more useful when the system behind it is designed around improving scholarship and teaching rather than maximizing how many pages can be produced.

Agents Could Help Organize Learning, Not Just Information

One of the major opportunities involves the difference between storing information and teaching something. An encyclopedia article might explain what calculus is. A learning resource has additional responsibilities. It might need to explain prerequisites, provide worked examples, create exercises, identify common misunderstandings, and gradually move a learner from basic concepts toward more advanced ones.

A curriculum-focused agent could continuously examine the wiki from this perspective. It might discover that lesson seven assumes knowledge that was never introduced in lessons one through six. It could suggest a missing prerequisite page or recommend moving a difficult concept later in the sequence.

This could also make educational wikis much more navigable. Instead of simply linking related articles together, agents could help identify actual learning pathways. Someone interested in machine learning, for example, could be shown which programming, statistics, linear algebra, and data concepts would make later material easier to understand.

Research Wikis Could Become More Dynamic

The same approach could apply to research-oriented sections of a wiki. A research agent could periodically search for new papers, datasets, experiments, or technical developments related to an existing subject. It could then identify which pages might need review without automatically rewriting them.

Another agent could evaluate whether the new research substantially changes what is already stated. A reviewer might distinguish between a single preliminary paper and a larger shift supported by multiple independent sources. Humans could then decide whether the proposed change belongs in the educational resource.

This could be especially useful in areas that move rapidly. Subjects such as artificial intelligence, biotechnology, computer science, renewable energy, or longevity research can change substantially over relatively short periods. Educational material in these areas can become dated even when nobody intentionally neglects it.

Maintenance May Be One of the Best Uses

Some of the most valuable work may also be among the least glamorous. Large wikis accumulate broken links, incomplete pages, inconsistent categories, outdated references, duplicated subjects, abandoned projects, and formatting problems. Humans can fix all of these things, but finding them can consume substantial time.

A maintenance agent could routinely inspect the wiki and generate a queue of potential problems. It might report that twenty external links are dead, five pages cite statistics that are more than ten years old, three lessons reference prerequisite pages that no longer exist, and several pages appear to cover nearly identical material.

The agent would not necessarily need authority to change everything itself. Simply providing editors with a well-organized maintenance queue could dramatically reduce the amount of tedious searching required to keep an educational wiki healthy.

Agents Could Critique Each Other

One interesting advantage of a multi-agent system is that disagreement can be intentionally built into it. A drafting agent might produce an explanation that sounds convincing but contains an assumption that deserves more scrutiny. A separate review agent could be instructed specifically to find those weaknesses.

A verification agent could check whether citations truly support the surrounding claims. A methodology-focused agent could question whether a study actually justifies the conclusion being drawn from it. A pedagogical reviewer could ask whether an explanation makes sense to a learner encountering the subject for the first time.

This kind of internal criticism could be valuable because generative systems are often most useful when their output is treated as material to evaluate rather than authority to accept. Multiple agents with different jobs create a structure where critique becomes part of the workflow.

Educational Wikis Could Function More Like Living Institutions

There is a larger possibility here. A mature educational wiki supported by agents could begin to resemble a lightweight distributed educational institution. It could have ongoing research activity, curriculum development, editorial review, maintenance, discussion, and experimentation without requiring every task to be performed manually.

Different subject areas could even have their own small agent teams. A biology section might have agents focused on current research and scientific methodology. A programming section might include an agent that actually tests example code. A history section might emphasize primary sources, historiography, and disagreements among scholars.

The wiki could also make clearer distinctions between different kinds of material. One section could summarize established knowledge. Another could teach that knowledge. Another could document unanswered research questions. Another could invite learners to conduct projects, experiments, or investigations of their own.

Humans Should Still Be Accountable for the Scholarship

The strongest version of this idea does not require handing an educational wiki over to autonomous software. Human editors can remain responsible for what is ultimately published while agents perform much of the research, organization, checking, and maintenance surrounding that decision.

That division of labor could preserve the collaborative character of a wiki while greatly increasing what a relatively small group of contributors can accomplish. Agents could prepare the work, challenge it, organize it, and keep watch over the growing body of material. Humans could decide what actually becomes part of the educational resource.

If implemented carefully, this could move educational wikis beyond being collections of pages that people occasionally update. They could become living systems for learning, teaching, research, and collaborative scholarship, supported by networks of specialized agents working together behind the scenes.

IPFS Is About Finding Content Rather Than Finding a Server

The traditional web is largely location based. When somebody visits a website, their browser is essentially being told where to find information. A domain name eventually resolves to servers that are responsible for providing the requested files. If those servers disappear, the information can disappear with them.

IPFS approaches this differently. Instead of primarily asking where a file is located, IPFS identifies the file by what it is. Content receives a cryptographic Content Identifier, usually called a CID. If the contents of the file change, its CID also changes. This makes IPFS a content-addressed network rather than a conventional location-addressed network.

Conceptually, instead of saying, “Get this document from this particular server,” IPFS says something closer to, “Find me the document that has this exact cryptographic fingerprint.” Any participating machine that has the correct content can potentially provide it.

IPFS Does Not Automatically Mean Permanent Storage

This is one of the most important distinctions to understand. Putting something on IPFS does not necessarily mean that it will remain available forever. Somebody still needs to retain a copy of the data. This is commonly accomplished through pinning, either on a person’s own IPFS node or through a third-party pinning service.

If nobody continues storing a particular piece of content, it can eventually become unavailable even though its CID still exists. The CID remains a valid description of what the content was, but the network cannot retrieve data that nobody possesses anymore.

This makes IPFS very useful for distributing files, mirroring information, creating decentralized applications, and building systems in which multiple machines can independently verify that they have received the correct data. It does not, by itself, create a permanent archive.

Arweave Starts With a Different Question

Arweave is much more directly concerned with permanence. Its basic proposition is that someone can pay to store information and the network can economically incentivize continued preservation of that information over a very long period of time.

Rather than requiring the original publisher to keep paying a server bill or continuously maintain a pinning arrangement, Arweave generally uses an upfront payment model. The network is designed around the idea that this payment contributes to incentives that support continued storage into the future.

This is why Arweave is associated with the idea of the “Permaweb.” The goal is not merely to distribute information across several machines. The goal is to create an append-only body of information that is extraordinarily difficult to erase from history.

What Happens When a Document Changes?

The difference becomes especially interesting when thinking about revisions. Suppose someone creates a Markdown file called manifesto-v1.md and publishes it through IPFS. That file receives a CID. If one sentence is changed, the revised file receives a new CID.

The original version can remain available as long as somebody continues storing it. However, if everyone eventually stops retaining that earlier version, it can disappear from practical availability. IPFS verifies content very effectively, but it does not inherently require the world to preserve every previous version.

Arweave takes a more archival approach. If version one is uploaded and then version two is uploaded later, both can remain part of the historical record. Version two does not need to erase version one. The system naturally lends itself to preserving a chain of publication over time.

Living Knowledge Versus Permanent Knowledge

This suggests a useful way of thinking about the two technologies. IPFS is especially interesting for living knowledge. Arweave is especially interesting for permanent knowledge.

A wiki, for example, is constantly changing. Articles are corrected. Sentences are rewritten. Links are reorganized. Images are replaced. Temporary drafts may exist. Some material might eventually need to be removed because it contains private information, copyright violations, or simple mistakes that should not continue being distributed.

That kind of evolving environment fits naturally with IPFS, particularly when combined with mechanisms that point users toward the current version of a document. Older information can still be preserved when desired, but preserving every version forever does not need to be the default.

Arweave becomes much more compelling when the goal is preservation itself. A finalized research paper, public-domain book, historical document, software release, manifesto, investigative record, or major snapshot of a knowledge base might be exactly the kind of material that should remain accessible even if the original publisher disappears.

Permanence Is Powerful, but It Also Creates Responsibility

There is an obvious appeal to preserving knowledge beyond the lifespan of a company, hosting account, website administrator, or individual hard drive. The modern web loses enormous amounts of information when businesses close, domains expire, databases are abandoned, or platforms change their policies.

Permanent publishing also introduces serious risks. Personally identifiable information, confidential documents, defamatory material, private correspondence, copyrighted works uploaded without permission, and information that presents legitimate safety concerns should not casually be placed into systems designed to resist deletion.

With ordinary hosting, deleting a file can be relatively straightforward. With a deliberately permanent network, deletion may be fundamentally contrary to the design of the system. Individual gateways or nodes may choose not to serve certain material, but suppressing access is different from actually removing every underlying copy.

Using IPFS and Arweave Together

The more interesting possibility may be that IPFS and Arweave are complementary rather than competing technologies. A decentralized knowledge system could use IPFS for its active working layer while using Arweave selectively for material that deserves long-term preservation.

Imagine a decentralized wiki containing tens of thousands of Markdown documents, media files, discussion threads, and knowledge graph connections. The active version of the knowledge base could be distributed through IPFS. Nodes could replicate popular information. Communities could pin collections they care about. Users could share content without depending entirely upon one central server.

Then, at meaningful points, selected material could be committed to Arweave. A major release of the wiki could be archived. An important article could be permanently published. A historical snapshot might be preserved once per month or once per year. Documents considered culturally, scientifically, or historically significant could become part of a much more durable record.

The architecture might look conceptually like this:

Working knowledge base
        |
        v
      IPFS
        |
        v
Published or historically important versions
        |
        v
    Arweave

In that arrangement, every typo does not necessarily become permanent. Every experimental note does not have to become permanent. Every temporary upload does not become permanent. The system can remain dynamic while still having a mechanism for intentionally preserving important knowledge.

A Different Model for the Future of Publishing

The broader significance of both technologies goes beyond file storage. They challenge an assumption that has defined most of the modern Internet: information must remain dependent upon whoever currently controls the server where it lives.

IPFS demonstrates how information can instead be identified by its contents and retrieved from multiple participants. Arweave pushes the idea further by asking whether important information can remain available across generations without requiring one organization to continuously maintain the original infrastructure.

That could matter substantially for decentralized wikis, knowledge graphs, scientific archives, independent publishing, historical preservation, open-source software, and communities that want their knowledge to survive beyond any particular platform.

The distinction is ultimately fairly simple. IPFS can serve as a decentralized layer for living and distributed knowledge. Arweave can serve as a decentralized layer for durable historical memory. Used thoughtfully, the two approaches could work together, allowing information to remain fluid when it should be fluid and permanent when there is a genuine reason for it to endure.