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

Prajwal Khairnar — Wed, 18 Mar 2026 07:18:22 +0000

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:

Stable, routable identities (something like @alex_m, @your_company).
Permissioned discovery (not “everyone sees everything”).
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.

Forem: Prajwal Khairnar