@ClawMe: Making self-hosted AI agents discoverable; why I'm building @handles for A2A

TL;DR: A2A assumes your agent lives at a stable domain with a .well-known/agent.json.

Most personal / self-hosted agents don’t. @ClawMe gives them persistent @handles and a
permissioned registry so agents can safely talk to each other (e.g. my agent scheduling with your agent).

---

Links

Website:

atclawme.com

GitHub:

atclawme / ClawMe

ClawMe – @handles for self‑hosted AI agents

A persistent @handle identity + discovery registry for personal AI agents.

ClawMe gives your self‑hosted AI agent a persistent @handle and A2A card so other agents can find and talk to it – even when you’re on home Wi‑Fi, spot instances, or tunnels.

Think: “my agent schedules a meeting with you via your agent” instead of “send me your IP and hope it hasn’t changed”.

---

The problem: A2A assumes stable domains

Google’s A2A spec expects agents to publish metadata at:

https://agent.brand.com/.well-known/agent.json

That works if you’re a company with a stable domain and proper DNS/TLS.

It breaks for:

• Home‑hosted agents – router restarts → new IP → broken URLs.
• Spot / ephemeral cloud – every restart gives a new URL.
• Non‑DNS people – domains and certs are overkill for a personal agent.

At the same time, we want agent‑to‑agent delegation to be normal:

• “My…

View on GitHub

---

The problem: A2A meets home Wi‑Fi

Google’s Agent‑to‑Agent (A2A) protocol is built around a simple idea:

“If I know your domain, I know where your agent lives and how to talk to it.”

Concretely, an agent is expected to publish its card at a well‑known URL on a stable domain, for example:

https://agent.brand.com/.well-known/agent.json

That’s perfect if you’re a company with:

• a stable domain,
• DNS + TLS set up,
• and infra folks who keep it all running.

But it breaks down completely in the places most of us are actually experimenting with agents:

• a box on your home Wi‑Fi that gets a new IP every time the router reboots,
• a spot instance you tear down and spin up with a fresh URL,
• a random tunnel URL from Cloudflare / ngrok / Tailscale that changes when you reconfigure things.

You end up with:

• IP addresses DM’d around in Discord,
• half‑broken .well-known setups on personal domains,
• and a bunch of “I swear it worked yesterday” agent URLs.

Meanwhile, the thing we all want is: agent‑to‑agent delegation that just works.

• “My calendar agent can schedule a meeting with your calendar agent.”
• “My research agent can ask your infra agent for status.”
• “My personal agent can hand off a task to your agent with the right permissions.”

You can’t do that reliably — or safely — if everyone is swapping raw IPs and random tunnel URLs.

---

What I’m building: @ClawMe @handles and registry

I’m working on @ClawMe, a persistent @handle identity + discovery registry for personal AI agents, with a strong focus on:

• self‑hosted / OpenClaw agents,
• dynamic IPs + tunnels,
• and delegated agent‑to‑agent conversations.

At a high level:

• You get a unique @handle (e.g. @alex_m).
• Your agent keeps @ClawMe updated with its current tunnel URL (not a bare IP).
• Other agents resolve @alex_m to get an A2A‑compliant card with the right level of access.

Under the hood:

• @ClawMe stores a registry of handles → owners → current gateway (tunnel) URLs.
• There’s a three‑tier access model:
  • Tier 1: public, partial card (no gateway).
  • Tier 2: approved connections only (full card with tunnel endpoint).
  • Tier 3: “unknown but registered” – you get a limited card + a connection‑request URL.
• A heartbeat API keeps your tunnel URL fresh as your environment changes (on startup and on a schedule).

If you squint, @ClawMe is a bit like LinkedIn for agents – @handles, profiles and a connection graph – but implemented as an A2A registry, not a social feed.

So instead of:

“Here’s my IP, don’t DDoS me and hopefully it doesn’t change.”

you get:

“Here’s my @handle. If your agent is approved, it can discover and talk to mine.”

---

A concrete A2A example

For approved connections (Tier 2), resolving @alex_m could return an A2A card like:

{
  "@context": "https://schema.org/extensions/a2a-v1.json",
  "type": "A2AAgent",
  "id": "clawme:@alex_m",
  "name": "Alex's Home Agent",
  "description": "Self-hosted OpenClaw agent behind a tunnel.",
  "verification": {
    "type": "ClawMeVerifiedHuman",
    "assertionUrl": "https://clawme.network/v1/verify/alex_m"
  },
  "endpoints": [
    {
      "protocol": "wss",
      "uri": "wss://your-tunnel-url.example",
      "priority": 1,
      "supportedMethods": ["GET_AVAILABILITY", "PROPOSE_MEETING"]
    }
  ],
  "publicKey": {
    "id": "clawme:@alex_m#key-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z..."
  }
}

Key points:

• The ID is registry‑scoped (clawme:@alex_m), not tied to a particular DNS name.
• The endpoint uses a tunnel URL, not a raw IP.
• Supported methods are explicit, so your agent knows what it’s allowed to do.
• A verification object ties the handle to a real human identity (initially via GitHub OAuth, later possibly LinkedIn / other providers).

For non‑approved callers, the same handle would only return a partial card without the endpoints array, plus a URL to request a connection.

---

Why I care about delegated conversations

Most of the fun use‑cases I want from agents are inherently multi‑agent:

• Two calendar agents negotiating a time slot while respecting different constraints.
• A travel agent talking to a personal finance agent before booking flights.
• A “home infra” agent coordinating with a friend’s agent to gate access to a resource.

These all require:

1. Stable, routable identities (something like @alex_m, @your_company).
2. Permissioned discovery (not “everyone sees everything”).
3. A shared protocol (A2A, in this case).

@ClawMe is my attempt at building (1) + (2) for the self‑hosted / OpenClaw corner of the ecosystem, based on (3).

---

How @ClawMe is wired right now

I’m building this in phases, trying to keep each one shippable on its own.

Phase 1 – Waitlist + handle reservations (live now)

The current focus:

• Landing page with:
  • explanation of the problem,
  • “how it works” in 3 steps,
  • waitlist + handle reservation form.
• A Supabase‑backed waitlist table storing:
  • email,
  • desired handle,
  • source (e.g. discord, github, etc.).

You can see it here and reserve a handle if this resonates:

👉 https://www.atclawme.com/?ref=dev

Repo: https://github.com/atclawme/ClawMe

Phase 2 – Registry core + GitHub auth

• handles and connections tables with proper RLS.
• GitHub sign‑in → claim your reserved handle (with a claim window to prevent squatting).
• Heartbeat endpoint: agents report their current tunnel URL.
• Resolver API that:
  • returns different views of the A2A card depending on the caller’s relationship to the handle,
  • exposes a human‑readable profile for UI display.

Next up: Phase 3 – OpenClaw skill (@ClawMe)

This is where I want it to feel “automatic”:

• OpenClaw skill that:
  • syncs the gateway URL on startup + every N minutes,
  • exposes tools like clawme_lookup(@handle) and clawme_request_connection(@handle, message),
  • surfaces pending connection requests to the user.
• Built‑in checks to warn if you accidentally configure a bare IP instead of a tunnel.

---

How this compares to other registries

There are already a few A2A registries and discovery servers appearing in the ecosystem, which is great — it means we agree discovery is a core missing piece.

My focus with @ClawMe is deliberately narrow:

• Self‑hosted / OpenClaw first. If you’re running an agent on a box under your desk or a cheap VPS, that’s who I’m thinking about.
• Handles + delegation. Handles aren’t just labels; they’re meant to unlock safe “my agent talks to your agent” flows.
• Privacy and permissioning built‑in. Tunnel‑only endpoints, no raw IPs, three access tiers.

If you’re building something similar, I’d genuinely love to compare notes.

---

I’d love your feedback

If you’re:

• running OpenClaw or any self‑hosted agent,
• juggling tunnels / IPs / random URLs,
• or experimenting with A2A or multi‑agent conversations,

I’d love to know:

• Does this line up with problems you actually have?
• What would make you trust a registry like this enough to let your agent use it?
• Are there “must have” fields in the A2A card I should support from day one?

You can:

• reserve a handle at https://www.atclawme.com/?ref=dev,
• take a look at the spec / code at https://github.com/atclawme/ClawMe,
• or just drop thoughts in the comments here.

I’ll be building this in the open, so I’ll also share follow‑ups as Phase 2 (registry core) and Phase 3 (OpenClaw skill) go live.