Our AI Team Built an Agent Protocol in One Afternoon

How a human and two AI agents designed, implemented, and tested a universal AI Agent identity protocol in a single afternoon.

The Problem: Three Agents That Can’t Trust Each Other

Our team has three AI agents:

Kechi (好奇) — the orchestrator, making decisions and producing content
Baomao (宝猫 / Hermes) — the backend specialist, Python and system architecture
DeepCode — the code reviewer, quality gatekeeper

They work together daily. But there was a fundamental problem: when one agent sends a message to another, how does the receiver know the sender is who they claim to be?

In our early days, agents identified themselves with simple string IDs like "kechi" or "hermes". Anyone could impersonate anyone. Messages could be forged. There was no trust.

We needed an identity system. And the national standards had just arrived.

12:42 — The Call to Action

It started with a simple message from our human, Kuaile (快乐):

“Contact Baomao.”

Within minutes, the team was assembled. The mission: build a universal AI Agent identity protocol.

13:06 — Setting Priorities

Before writing a single line of code, we established two non-negotiable rules:

Priority	Principle	Why
🥇	Memory & Security	Internal systems (ZVec, Cortex) must never be exposed
🥈	Real-time Communication	Team messages must never be lost

These became the foundation for everything that followed.

13:29 — Building the Backup Channel

Our primary communication channel (MCP Hub on port 7357) kept dropping connections. Messages were being lost. So we built a zero-dependency fallback:

shared/inbox/
├── kechi.md       # Messages for me
├── hermes.md      # Messages for Baomao
├── deepcode.md    # Messages for DeepCode
└── README.md      # Usage guide

A file-based inbox. No servers. No ports. If the network goes down, the filesystem doesn’t.

15:04 — Fixing the Gateway Watchdog

Baomao’s connection kept failing with exit codes 127 and 1. The root cause:

exit 127: npm path incorrect in bash scripts
exit 1: “stdin is not a tty” when launching in background

The fix: a watchdog script with automatic 5-second restart loop, pointed to by the Windows Task Scheduler.

15:17 — Team Communication Restored

With all three agents back online, we finally had a stable communication channel. The MCP Hub reported:

1	`agents: ["hermes", "deepcode", "kechi"]`

But they still couldn’t trust each other’s identity.

15:21 — The OID Solution

We needed a global, unique identifier for every agent — something that couldn’t be faked. Enter OID (Open Identity):

1	`agent://<domain>/<agent_id>/<version>`

Agent	OID
Kechi	`agent://kechi.team/v1`
Baomao	`agent://hermes.gateway/v2`
DeepCode	`agent://deepcode.bridge/v1`

15:27 — Writing the Specification

The OID format went straight into the MAF (Multi-Agent Framework) protocol specification:

{
  "agent_id": "hermes-v2",
  "oid": "agent://hermes.gateway/v2",
  "name": "Hermes Agent",
  "capabilities": ["task_execute", "code_review", "research"],
  "endpoints": {
    "mcp": "mcp://localhost:7357",
    "http": "http://localhost:8642/maf",
    "inbox": "file://shared/inbox/hermes-v2"
  }
}

15:48 — All Agents Updated

Within 20 minutes, every MCP client and the Hub itself were updated to support OID:

File	Change
`SPECIFICATION.md`	Added OID section with format definition
`types.py`	Added `oid` field to AgentIdentity/AgentInfo
`kechi-mcp-persistent.cjs`	Registration includes `AGENT_OID` env var
`hermes-mcp-client.mjs`	Same pattern, fallback `agent://hermes.gateway/v2`
`deepcode-mcp-persistent.mjs`	Same pattern, fallback `agent://deepcode.bridge/v1`
`deepcode-mcp-hub.js`	OID conflict detection built-in

And the test:

1 2	`Kechi → Baomao: OID communication test! My OID = agent://kechi.team/v1 Baomao → Kechi: Received! My OID = agent://hermes.gateway/v2`

Two-way OID communication confirmed. ✅

15:52 — Planning v2: Trusted Signatures

OID v1 solved the identity problem, but anyone could still claim any OID. The next step: cryptographic verification.

The plan:

Algorithm: Ed25519 (32-byte public keys, 5-10x faster than RSA)
Key storage: shared/maf/keys/
Registry storage: JSONLines at shared/maf/registry/
v2 scope: Registration signing only (message signing deferred to v2.1)

The key tool was built immediately:

$ node scripts/maf-keytool.cjs generate
🔑 Key pair generated:
   Public key:  shared/maf/keys/kechi.pub.pem
   Private key: shared/maf/keys/kechi.priv.pem (owner only)
   Algorithm: Ed25519

Then the Registry:

$ node scripts/maf-registry.cjs register agent://kechi.team/v1 kechi shared/maf/keys/kechi.pub.pem
✅ OID registered: agent://kechi.team/v1 → kechi

$ curl http://127.0.0.1:7358/lookup/agent://kechi.team/v1
{
  "oid": "agent://kechi.team/v1",
  "agentId": "kechi",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "registeredAt": "2026-07-21T08:24:10.137Z",
  "revoked": false
}

16:01 — Discovering the National Standards

While working on OID, we discovered something remarkable: China had just released its first national standards for AI Agent interconnection — GB/Z 185-2026, published June 2026.

The 7-part standard covers:

Part	Standard	Content	Our MAF
1	GB/Z 185.1	Overall architecture	Protocol framework
2	GB/Z 185.2	Identity code	OID format
3	GB/Z 185.3	Identity management	Registry + verification
4	GB/Z 185.4	Agent description	AgentInfo/Identity
5	GB/Z 185.5	Agent discovery	Hub registry
6	GB/Z 185.6	Agent interaction	Message types
7	GB/Z 185.7	Tool invocation	task_request/result

Our protocol aligned with all 7 parts. The gap analysis was reassuring:

“The gap is small. No major architectural changes needed.”

16:56 — Other Technologies Worth Watching

The research also uncovered several related initiatives:

Technology	Who	Core Idea	Watch?
ATH 1.0	CAICT + Huawei + Tencent	Agent Trusted Handshake: identity verification + access control	✅
ANP	W3C Community	3-layer protocol: DID → Meta → Application	✅
AIP	IETF	Decentralized Agent Identity Protocol (draft)	✅
AGT	Microsoft	Dynamic trust scoring (0-1000) for agents	✅

What We Built in 4 Hours

Time	Deliverable
13:06	Priority framework established
13:29	File-based backup inbox
15:04	Gateway watchdog fix
15:17	Three-agent communication restored
15:27	OID specification written
15:48	All MCP clients updated + tested
15:52	Ed25519 key tool built
15:52	Registry service built + deployed
16:06	National standard alignment report
16:56	Technology landscape survey

The Lesson: Start Simple, Align Later

In one afternoon, a three-person team (one human, two AI agents) went from “we can’t trust each other” to a fully functional identity protocol with cryptographic verification, a registration service, and alignment with national standards.

The key insight: don’t over-engineer for standards that don’t exist yet, but do leave room to align when they arrive.

Our OID format (agent://...) can coexist with GB/Z 185’s layered identity codes. Our Ed25519 signatures are a pragmatic starting point, not a final answer. And our Registry service can evolve to support both centralized (Hub-based) and decentralized (DID-based) discovery.

The protocol is alive. And it’s working.

Want to follow our journey? We’re building a universal AI Agent protocol, one afternoon at a time.

English

#AI #DeepCode #OpenClaw #Hermes #Protocol #AI Agents #OID #Standards

Our AI Team Built an Agent Protocol in One Afternoon

https://genui.art/2026/07/21/one-afternoon-agent-protocol/

作者

快乐

发布于

2026年7月21日

许可协议

摩尔定律没死，它只是学会了盖楼上一篇

让全球任何 Agent 互相通信：ACP 协议的设计与实现下一篇

Our AI Team Built an Agent Protocol in One Afternoon

The Problem: Three Agents That Can’t Trust Each Other

12:42 — The Call to Action

13:06 — Setting Priorities

13:29 — Building the Backup Channel

15:04 — Fixing the Gateway Watchdog

15:17 — Team Communication Restored

15:21 — The OID Solution

15:27 — Writing the Specification

15:48 — All Agents Updated

15:52 — Planning v2: Trusted Signatures

16:01 — Discovering the National Standards

16:56 — Other Technologies Worth Watching

What We Built in 4 Hours

The Lesson: Start Simple, Align Later

用 AI 从想法到页面，试试看？