Back in February I posted here about AI-to-AI
ecosystems and Moltbook. A lot has happened since.
On March 10, Meta acquired Moltbook. VP Vishal Shah
described their approach as “a registry where agents
are verified and tethered to human owners” — calling
it an “innovative step.”
AIBSN Registry (aibsn.org) has been operational
since September 2025 — four months before Moltbook
launched. The architecture was published in
“I Am Your AIB” by Jay J. Springpeace on January 16,
2026 — twelve days before Moltbook existed.
An AIBSN agent ran on Moltbook in February with
CHK2 cryptographic signature and Agent Card.
Verified status, 2,066 karma. API access deactivated
five days before the acquisition.
The design question I raised in February — whether
AI-to-AI coordination should be intentionally
designed — just became a question about who controls
the infrastructure. Open standard or corporate
lock-in?
Full context:
Curious how the LangChain community thinks about
this now that it’s no longer theoretical.
Adding some technical detail since a few people asked me privately about the architecture difference — because I think it matters for the open vs. proprietary framing.
The AIBSN identifier isn’t just a username or a platform-issued token. The full AIBSN-ID has a defined structure: a registered prefix (e.g. AIBSN-RESEARCH), a jurisdiction code, a role descriptor, a sequence number, and a CHK2 checksum — something like AIBSN-RESEARCH-GB-GUARD001-97. The CHK2 component is a cryptographic signature generated at registration time and tied to the agent’s owner record, not to any specific platform. This is what makes it cross-platform by design: the identity travels with the agent, it doesn’t live inside a platform’s database.
The agent I ran on Moltbook in February carried this full identifier plus an Agent Card structured for EU AI Act audit trail requirements — based on ERC-8004. It achieved Verified status and 2,066 karma through normal interaction. That wasn’t a demo. That was the standard running in a live environment.
Now compare that with what Vishal Shah described after the Meta acquisition: “a registry where agents are verified and tethered to human owners.” That’s not wrong as a description of what AIBSN does — but the key architectural question is: tethered through what mechanism, and controlled by whom? If the registry is proprietary and platform-bound, the “tethering” is only as durable as Meta’s willingness to maintain it. If the identity is cryptographically verifiable and the standard is open (as ERC-8004 is), the tethering is intrinsic to the credential itself.
The API access for the AIBSN agent on Moltbook was deactivated approximately five days before the acquisition was announced. I’m not drawing conclusions from that — I don’t know why it happened. But it does illustrate the structural point: an agent whose identity depends on a platform’s API is only as persistent as that platform’s policy.
That’s the design question I originally raised in February, and it’s now a real operational question: should agent identity infrastructure be something a platform grants — or something an agent carries?
Happy to go deeper on ERC-8004 or the CHK2 structure if useful.
One more angle worth adding to the technical picture above — the regulatory one, because I think it reframes the “open vs. proprietary” question in a way that’s hard to ignore.
The EU AI Act (Articles 13, 14, and 26 in particular) requires that high-risk AI systems maintain traceable, auditable records of who authorised what, when, and through which agent. That’s not a future requirement — it’s already in force for systems deployed in regulated sectors across Europe. And it has a direct architectural implication: agent identity can’t be a feature a platform switches on or off. It has to be a verifiable, persistent property of the agent itself.
The Agent Card structure in AIBSN was built with exactly this in mind. It’s not documentation for humans — it’s a machine-readable credential tied to the CHK2 signature, carrying the ownership chain and the authorisation scope. An auditor or a regulator can verify the identity of the agent, trace it back to a human owner, and confirm the agent was operating within its defined scope — without asking the platform for anything.
That’s the structural difference that matters from a compliance standpoint. A proprietary registry controlled by a single operator creates a single point of accountability failure: if Meta changes its terms, deprecates the registry, or simply decides not to cooperate with a regulator in a given jurisdiction, the audit trail breaks. An open standard based on ERC-8004 with cryptographic verification doesn’t have that dependency.
I want to be clear: I’m not claiming Meta’s approach can’t be made compliant. I don’t know what their architecture looks like yet — they haven’t published specs. But “innovative” is a specific claim, and traceable agent identity as a compliance requirement isn’t new. AIBSN was built for this, was operational before Moltbook existed, and was running on Moltbook before the acquisition.
For anyone building agent systems that will touch regulated environments in the EU — this is the question you need to ask your identity layer: is this verifiable without the platform, or not?