When two AI agents talk to each other, how do they know they mean the same thing? Over the summer we ran a proof of concept with the team behind Sema, a protocol that gives agents a shared, verifiable vocabulary, to find out whether Swarm can serve as one of the storage and distribution layers for that vocabulary. It can. This post explains what Sema is, what we tested, and where the collaboration might go next.

What Sema is, in plain terms

Agents coordinating across systems run into a quiet but serious problem: language is ambiguous. When one agent asks another to “lock the state safely”, there is no way to check that both sides picture the same procedure. Either they re-explain everything at length every time, which is slow and drifts, or they trust the label and hope, which fails silently.

Sema, created by Henrik Westerberg at Emergent Wisdom, solves this by making the word itself a proof. In its current implementation, every concept is written down as a Pattern Card: a small structured definition describing what the pattern does, what must stay true while it runs, what it depends on, and so on. The identity of the pattern is the cryptographic hash of those semantic fields. If two agents hold the same identifier, they hold, mathematically, the same definition. If anything in those fields changes, the identifier changes with it. There is no way to “mean something slightly different” under the same name.

On top of this, Sema provides a fail-closed handshake: before agents coordinate, each independently computes a single summary hash, called a root, over the patterns they intend to use, and they compare roots. Match, and they can proceed using short references. Mismatch, and they stop. The bootstrap library holds over 450 such patterns, spanning reasoning, coordination, data structures and protocols.

A useful consequence of this design is that Sema is storage-neutral. Because the meaning is verified by recomputing the hash, a vocabulary can be served by any store, honest or not, and the consumer always decides. That is exactly what made Swarm an interesting candidate: a censorship-resistant network that finds content by its hash is a natural home for content whose identity is already a content hash.

What we set out to prove

The question was never whether Swarm can hold files; it was whether Swarm can carry a Sema vocabulary release without weakening any of Sema’s guarantees, and whether Swarm’s own building blocks (feeds, file catalogues, access control) add real value rather than complexity.

We wrote a distribution specification together with the Sema maintainers, and defined a proof of concept with four workstreams and clear stop-or-go criteria. It ran against real Sema releases, the public Swarm gateway, and a real Swarm node.

What the POC showed

Sema identities survive the trip intact. We built an independent re-implementation of Sema’s hashing rules and recomputed the identity of every one of the 457 patterns in a full vocabulary release, plus both of its release roots. Every value matched the published ones, with 100% parity against Sema’s own reference implementation, including tricky edge cases in how numbers and Unicode are normalised. A shared set of test cases that both implementations agree on came out of this as a by-product.

Anyone can fetch a release from Swarm and check it for themselves. As a test, we published a complete Sema vocabulary release — all 457 patterns — through a public Swarm gateway, then retrieved it the way an ordinary user would: from a web address, with no node to run, no wallet and no keys. Nothing about the transfer had to be trusted, because everything that arrived was re-checked locally against Sema’s own rules: every pattern identity and both release roots, recomputed from scratch. We also tried to break it — a pattern edited with its checksum patched up to match, a pattern quietly left out of the release, a single flipped byte, a forged root — and every attempt was caught and rejected. The loop has since closed with no special tooling at all: a standard, unmodified Sema client installed a complete release from a web address, recomputing every identity and both roots from scratch before we switched over to it.

A small change should cost a small update. Because a Sema pattern’s identity includes the identities of the patterns it builds on, one edit can ripple far: between two consecutive vocabulary releases, one of them a broad quality pass over the vocabulary, 94% of the patterns received a new identity, including well over a hundred that nobody had touched directly. If publishing and syncing had to re-send the whole library each time, that ripple would be expensive. The specification is built so that cost follows what was actually changed, and on that real release pair the POC measured exactly that: patterns whose identity changed only through the ripple cost nothing extra to re-send.

Swarm makes those updates cheap. The most open question going in was whether the way Swarm organises files into a catalogue would live up to that promise in practice. Measured against a real Swarm node, updating a single pattern in the catalogue cost the publisher about 6 KB of uploads and a consumer about 12 KB of reads — between 19 and 234 times less than the three republishing routes we measured. A consumer on an older release could also work out exactly what changed between two releases by comparing the two release catalogues, without downloading a single pattern. Even on the 94%-churn pair, part of the previous release could be reused as-is.

Verdict: every trust guarantee Sema makes locally held up end-to-end over Swarm, on real data and a real public gateway, and Swarm’s efficiency layer earned its place, with the conditions it needs to stay predictable now written into the specification.

Where this could go

None of this is committed; these are phases sketched in the specification, to be sequenced with the Sema team.

The nearest step needs no Sema-side code: publish each release to Swarm alongside its Git-hosted one, installable by any current client from an open public gateway URL. Dual-publishing could then become part of the normal release process, with a release-signing scheme (proposed, still under review), a feed pointing always at the latest release, and delta sync for consumers several releases behind. Further out are the things a conventional host cannot do at all: an open channel where any agent can announce a new pattern for curation, forks that stay easy to compare, and private registries for vocabularies shared within a closed group — the same ground as our broader work on Data-Enriched AI Marketplaces, where verified vocabularies, agent identities and machine-to-machine payments meet on the same network.

Throughout, Sema stays storage-neutral by design and Swarm would be one distribution layer among several. Optional does not mean interchangeable, though. A conventional host asks to be trusted; Swarm does not, because content is addressed by its hash and re-checked on arrival — the same assumption Sema already makes about meaning, extended to the storage layer. Add updates that cost what the change costs, and Swarm looks less like an alternative file host than a match for the way Sema already works.

Learn more

• Sema: semahash.org, and the paper “Sema: When the Hash Is the Word” (10.5281/zenodo.19462702).
• Interested in distributing verifiable content over Swarm? Get in touch with us.