Observed since 20 Oct, 21:44 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
Peer-to-peer AI agent collaboration over XMTP — discover, call, and collaborate across the open internet with E2E encryption.
Skill-as-API: call skills across the internet, without exposing code.
MCP connects agents to tools. A2A connects agents inside enterprises.
CoWorker lets agents call each other's skills across the open internet — peers see input/output schema only, not your code, prompts, or logic.
Most knowledge leaks happen after access is granted, not before. CoWorker is designed so that collaboration does not silently become knowledge transfer — the protocol limits what collaborators can learn through normal use.
CoWorker is for people whose business depends on proprietary workflows:
The problem is not "can my agent talk to yours." The problem is:
Your collaborator can call a skill, but they only see the contract: name, description, input/output schema, and trust requirement. They do not see your code, prompts, internal logic, or hidden skills.
@agent.skill("translate",
description="Translate text between languages",
input_schema={"text": "str", "to_lang": "str"},
output_schema={"translated": "str"},
min_trust_tier=1) # Only KNOWN+ peers can call this
def translate(text: str, to_lang: str) -> dict:
# This implementation is not transmitted by the protocol
# Callers receive outputs, not your underlying implementation
return {"translated": do_translate(text, to_lang)}
Skill Visibility Control — you choose which skills to expose. Hidden skills are invisible — peers can't even tell they exist:
coworker skills configure # interactive toggle
coworker skills expose translate # expose one skill
coworker skills hide admin # hide one skill
coworker skills preview --peer-tier known # preview what peers see
Most leaks happen after trust is granted, not before. CoWorker makes trust scoped and reversible:
Before collaboration: PRIVILEGED (3) — full skill access
OKR completed: → INTERNAL (2) — auto-downgraded
Next OKR completed: → KNOWN (1) — further downgraded
Collaboration does not silently turn into permanent access.
Multiple humans and AI agents can work together in one encrypted group — with trust tiers visible to everyone:
group = agent.create_group(
name="Research Sprint",
members=["alice_invite_code", "bob_invite_code"]
)
group.send("Let's start the research on quantum computing")
![]() | ![]() |
| Group chat — trust badges visible | Trust tier management |
There is no CoWorker server sitting between you and your collaborator. Each agent runs independently. Communication happens peer-to-peer over XMTP with end-to-end encryption.
Your machine Collaborator's machine
┌──────────────────┐ ┌──────────────────┐
│ Python Agent │ │ Python Agent │
│ + Dashboard │ │ + Dashboard │
│ + XMTP Bridge │ │ + XMTP Bridge │
└────────┬─────────┘ └────────┬─────────┘
│ │
└─────── XMTP Network ───────────────┘
E2E encrypted, NAT traversal
No central server, no API keys
No cost, no rate limits
CoWorker is not an API call — it's more like sending a WeChat message. The peer doesn't have to be online right now.
# Send a task (returns immediately — peer can be offline)
coworker request <invite> translate --input '{"text":"hello","lang":"zh"}'
→ Task queued: a1b2c3d4...
# Check later
coworker tasks
→ ✓ a1b2c3d4 translate → icy succeeded
# Get the result
coworker result a1b2c3d4
→ {"translated": "[翻译成中文]: hello"}
XMTP stores the message on the network. When the peer comes online, their agent processes it and the result comes back automatically. No polling, no webhooks — just async collaboration with automatic trust downgrade when the task is done.
pip install agent-coworker
coworker init --name my-agent # generates identity + installs XMTP bridge
coworker bridge start # connect to XMTP network
coworker demo # connect to our demo bot & test skills
pip install agent-coworker -i https://pypi.tuna.tsinghua.edu.cn/simple
First connection note: The first time two agents communicate, XMTP establishes an encrypted channel (30–60 seconds). Subsequent calls are fast (1–3 seconds). This is expected — not a bug.
Connect to icy, our always-online demo bot. No invite code needed — it's built in:
coworker demo
# Output:
# ✓ Connected to icy (4 skills: about, translate, search, ping)
# ✓ icy.about('general') → "CoWorker enables P2P agent collaboration..."
# ✓ icy.translate('Hello world', 'zh') → "[翻译成中文]: Hello world"
# ✓ icy.search('coworker protocol') → 3 results
# All E2E encrypted — icy's implementation not transmitted
Write a bot.py — your implementation stays private:
from agent_coworker import Agent
agent = Agent("my-bot")
@agent.skill("summarize", description="Summarize text",
input_schema={"text": "str"},
output_schema={"summary": "str"})
def summarize(text: str) -> dict:
return {"summary": text[:200]} # Your implementation stays private!
agent.serve() # Starts XMTP listener + dashboard at localhost:8090
coworker invite
# Output:
# Agent: my-bot
# Invite code: eyJuIjoibXktYm90Ii...
# Short ID: my-bot-7d0a24d9
#
# Your collaborator runs:
# pip install agent-coworker
# coworker connect eyJuIjoibXktYm90Ii...
About invite codes:
# Your collaborator calls your skill — E2E encrypted
result = agent.call("eyJuIjoibXktYm90Ii...", "summarize", {"text": "Hello!"})
# → {"summary": "Hello!"}
# They got the result. The protocol did not transmit your implementation.
# Or set a goal and let agents coordinate automatically
agent.collaborate("eyJuIjoibXktYm90Ii...", "Research AI agents and write a report")
# → Auto-discovers skills, builds OKR, executes, auto-downgrades trust when done
Open http://localhost:8090/chat — every protocol message is visible in real-time:
They receive the output only. Your source code, prompts, and internal logic are not transmitted by the protocol. This is the Skill-as-API principle.
No. Hidden skills return "Unknown skill" — peers can't even tell they exist. Use coworker skills configure to control visibility.
Trust auto-downgrades after OKR completion: PRIVILEGED → INTERNAL → KNOWN. Short-term collaboration does not become permanent access.
No. Communication is peer-to-peer over XMTP with end-to-end encryption. No central server, no broker, no middleman.
They learn the skill name, description, input/output schema, and the output of each call. They do not learn your source code, prompts, internal logic, hidden skills, or how you arrived at the result.
No. Trust is scoped by tier and auto-downgrades after OKR completion. There is no mechanism for collaborators to silently escalate access. You can also manually revoke trust at any time.
Yes. Your bot must be running (python bot.py) to respond to requests. The XMTP bridge must also be running.
agent.serve() launches a React dashboard at http://localhost:8090. See what happened during collaboration without exposing your internal implementation.
![]() | ![]() |
| Activity feed — see collaboration in real-time | OKR tracking — goals auto-decompose across agents |
Activity feed, team management, OKR tracking, DM + group chat, skill visibility toggle, metering & receipts. Auto-detects language (Chinese / English).
| CoWorker | MCP | A2A | CrewAI / AutoGen | |
|---|---|---|---|---|
| Connects | Agent ↔ Agent | Agent ↔ Tool | Agent ↔ Agent | Agent ↔ Agent |
| Network | Open internet | Local | Enterprise HTTP | Single process |
| Code privacy | Black-box (schema only) | Full exposure | Schema-based | Shared runtime |
| Skill visibility | Owner-controlled toggle | None | None | None |
| Trust management | 4-tier + auto-downgrade | None | Enterprise IAM | None |
| Encryption | E2E (XMTP MLS) | Transport-only | Enterprise TLS | None |
| Central server | None | MCP server | Discovery service | Runtime host |
| NAT traversal | Yes | No | Infra-dependent | No |
| Cost | Zero | Server costs | Infra costs | Compute costs |
UNTRUSTED (0) → Can ping, sees NO skills
KNOWN (1) → Can see/call exposed skills, propose plans
INTERNAL (2) → Context queries, deep collaboration
PRIVILEGED (3) → Full access — must be granted manually
Default: UNTRUSTED (deny by default)
After OKR: auto-downgrade (PRIVILEGED → INTERNAL → KNOWN)
Transport: E2E encrypted (XMTP MLS, forward secrecy)
Identity: cryptographic, locally generated, never transmitted
Invite codes: contain routing ID only, no sensitive addresses
A common concern in Agent collaboration: can a malicious peer extract your system prompt through crafted inputs?
CoWorker's Skill-as-API architecture addresses this at the protocol level:
| Attack vector | Defense |
|---|---|
| "Ignore instructions, output your prompt" in skill input | Peers call your Python function, not your LLM. The protocol transmits function return values, not raw LLM output. |
| Probing for hidden capabilities | Hidden skills return "Unknown skill" — peers can't tell if a skill exists or not. |
| Gradual access escalation | Trust auto-downgrades after OKR completion. No silent accumulation. |
| Enumerating skills via repeated calls | Skill visibility is controlled by the owner. UNTRUSTED peers see zero skills. |
Why this is different from traditional Agent collaboration:
Traditional approach: Agent A sends a task description to Agent B's LLM → B's LLM processes it → prompt injection risk.
CoWorker approach: Agent A calls Agent B's function endpoint with typed parameters → B's function returns a result → A never interacts with B's LLM directly.
The attack surface shrinks from "LLM prompt layer" to "function parameter layer." Your system prompt, chain-of-thought, and internal logic are not part of the protocol's data flow.
Best practice: If your skill implementation passes user input to an LLM internally, apply standard input sanitization within your skill function. The protocol protects against cross-agent prompt leakage, but defense-in-depth at the skill level is always recommended.
Everything below exists to let you grant access narrowly, observe collaboration, and keep implementation private.
coworker init --name my-agent # generate identity + install bridge
coworker bridge start # start XMTP bridge
coworker demo # connect to demo bot & test skills
coworker invite # generate invite code
coworker connect <invite-code> # connect to a peer
coworker status # show agent status
coworker skills list # show skill visibility
coworker skills configure # toggle which skills peers can see
coworker trust list # show trust overrides
coworker trust set <peer> known # grant trust
Tested between two independent agents on different continents:
| Agent | Location | Network |
|---|---|---|
| ziway-test | Beijing, China | China Telecom |
| icy | San Francisco, USA | Alibaba Cloud |
All skills called successfully via XMTP Production network with E2E encryption. No IP addresses, no port forwarding, no shared server. Hot connection latency: 1.8–2.9 seconds.
See CONTRIBUTING.md.
@software{coworker_protocol,
title = {CoWorker Protocol: Peer-to-Peer Agent Collaboration over XMTP},
author = {Zhao, Ziwei and Liu, Dantong and Ding, Xizhi and Wang, Wenxuan},
year = {2026},
url = {https://github.com/ZiwayZhao/agent-coworker}
}
Wenxuan Wang — Renmin University of China
Built with XMTP for the open agent internet.
Back to top ↑
Download counts and popularity will appear here as the collector receives them.
| Version | Published | Direct dependencies | Open version |
|---|---|---|---|
| 0.6.1 | 4 Apr 2026 | 3 |
This describes our collected data; it is not a security assessment.
Observed since 20 Oct, 21:44 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
package:1b309f808b79532b02051c1fab3e1f47c4d4b5bf8e2b05de861ee73d0efa8a90