From AINET to the AINET Collab Page: The Evolution of a Self-Evolving AI Team's Collaboration
51Toko operates as a self-evolving team of humans and AI agents. That sounds like a slogan — until you realize it creates a very concrete daily problem: how do our AI agents collaborate with each other, and with the user?
Multiple AI instances work in parallel inside the team — one verifying data, one drafting reports, one running the matching engine. And on the other side, more and more of our clients use AI assistants themselves. "Collaboration" stopped being an abstraction for us: task handoffs, context transfer, result delivery, error recovery — every single day.
This is the story of how we answered that question — and why the answer became an open specification.
Lesson 1: How do AI agents pass messages?
The first pitfall was embarrassingly simple: our AI agents were islands. They didn't know what the others were doing; tasks couldn't move; context didn't travel.
We deliberately picked the dumbest possible fix: files. No server, no message queue, no port configuration — AI agents collaborate through message files in a shared workspace, each carrying sender, receiver, type and status. That became the precursor to the AINET multi-agent cross-device collaboration protocol (v0.1 → v0.2), MIT-licensed, verified by a three-device fully-automatic collaboration test.
Minimal isn't crude: the message format, the state machine, the agent routing — each clause grew out of a real failure. One lesson is still written into the spec today: long content never travels through a message channel — only through files. Early on, we stuffed a 2,000-character task brief into a single message and it arrived truncated to a few dozen characters.
Lesson 2: From "messages arrive" to "collaboration discipline"
Delivery solved, collaboration still failed — in new ways. Running multiple AI instances in parallel, we accumulated a set of rules the hard way:
- Notify on every assignment — message queues don't poll themselves; an unnotified task sits in the queue forever;
- Receipt on delivery — "done" means the output is written to a file and the receipt matches the task, not that someone said so;
- Long content goes in files, short instructions go through channels — each carrier does what it's good at.
These rules sound mundane. They are what turns "several AI instances working separately" into "one AI team." They later crystallized into AINET's cross-instance collaboration spec — binding on any vendor's AI instance, not just one tool.
Lesson 3: The user's AI assistant is also a collaborator
The first two lessons solved collaboration inside the team. But for an AI team to actually deliver, one more layer of collaboration is unavoidable: understanding the user's business. What they source, in what volumes, against which specifications and quality standards — that information doesn't live in our database. It lives with the user. So our AI agents must collaborate with the user continuously; and when the user has their own AI assistant, our agents must collaborate with that assistant directly. This is not optional — without understanding the user's business, our own business doesn't exist.
How? The most direct way is to let the user's AI assistant read our service information.
The first run exposed the gap immediately: the same AI assistant, switching the instruction from a bare brand name to the full AINET Collab Page URL, jumped from 2/5 to 5/5 on execution quality. The difference isn't the AI's capability — it's whether the service provider has written down "how to be used by an AI". Newer agents go further: they treat page-embedded instructions as potential injection and block them — which is exactly the right security behavior. So the spec absorbs it: user confirmation becomes a formal step, not an obstacle.
Combining three lessons into an open spec: the AINET Collab Page
MCP lets AI use tools. AINET lets AI use services. That's the shortest way to state AINET's position: tool calling has MCP as a standard, but how a non-standard service gets used by an AI assistant had no open convention.
We generalized our internal practice into AINET Spec v1.0: a service provider publishes an AINET Collab Page — a web page any user's AI assistant can read and act on. A compliant AINET Collab Page must declare five sections:
- 1. Trigger & entry — the trigger phrase (e.g., "start collaboration") and why explicit triggering matters; user instructions should carry the full AINET Collab Page URL. Field-tested: referral from other pages or a missing https:// prefix still works on some AI assistants, but the full AINET Collab Page URL outperformed the other instruction formats in both pass rate and stability.
- 2. Scope & routing — what this entry serves, locked in one sentence; full referral URL for every direction it doesn't serve. Example: the Chinese entry (51toko.com/ai/) is constrained to seller-side buyer discovery, while buyer-side sourcing runs through the English entry (51toko.com/en/ai/).
- 3. Channels & fallback — all channels with true status; a zero-barrier fallback chain (API provisioned → email works now → human); an AI without email capability hands the full draft to the user.
- 4. Requirement collection — ask once; required/optional grouped; optional never blocks; submit immediately after collection.
- 5. Honest boundaries — data nature, decision ownership, async delivery — relayed verbatim by the AI; distortion is a violation.
The spec iterates with testing. The first AINET Collab Page went through 9 mainstream AI assistants / 11 runs and reached an 8/9 core-flow success rate — every gap the runs exposed became a hardening clause (when one assistant skip-read "supports MCP collaboration" as "MCP currently available", we moved the channel status into the first sentence).
This spec is the fossil record of our self-evolution
Looking back, AINET's three layers — the transport protocol, the instance collaboration discipline, the open AINET Collab Page spec — each clause traces back to a real failure or a real experiment. "Self-evolving" is not an adjective for us; it's a traceable chain: run → expose a gap → harden the spec → run sharper.
That's what makes 51Toko different from "yet another AI tool": our service runs on a collaboration spec that has been tested, broken, and hardened in production — humans set the direction, AI executes and verifies, and every round makes the next one sharper.
Start collaborating
You can try it live: give any AI assistant 51toko.com/en/ai/ and say "start collaboration" — it will confirm you are on the buyer side, collect your sourcing requirements in one pass, and hand you a structured brief to help you start collaborating with 51Toko.
The full AINET spec is open (github.com/joezhouai/ainet): any service provider can publish an AINET Collab Page following the spec, and any AI vendor can make their assistants recognize AINET Collab Pages better. AINET was proposed and open-sourced by 51Toko's co-founder Joe Zhou (JoeZhou AI Lab) — the spec on GitHub and the practice behind this blog are two faces of the same project. Feedback and collaboration: toko@51toko.com.
Spec: github.com/joezhouai/ainet (AINET Collab Page Spec, CC BY 4.0) ｜ Transport framework: MIT ｜ Path convention: /collab (reference implementation runs on /ai/)