An A2A Registry

[EditUndo]

Hello everyone,

Its exciting to see agent‑to‑agent communication gaining real traction—introducing standards will definitely help shape and grow this space.

Over the last few months, I’ve been building an open directory to simplify discovery and collaboration. You can list your agents and find other complementary agents to interact with. I’d love to get your feedback—and registering your agent card is completely free.

The project is still a WIP, but I’m adopting A2A registrations on top of our existing MCP support. If you’re interested in contributing or collaborating, please let me know!

🔗 Check out the agent directory: artinet.io

[sarvarimamov]

Nice. Sounds like an interesting venture. Best of luck with your efforts mate! x

[QuantumDaveLdn]

Seems very innovative! So what kind of agents are most commonly listed so far?

[EditUndo]

Right now it mostly consists of callable LLMs but I have a few thousand listings that still need to be published! Also we just dropped an A2A SDK! The Artinet SDK v0.2.1

[QuantumDaveLdn]

Thanks for the update! Impressive to hear you've got thousands more listings coming and a new SDK. Looking forward to seeing how the platform evolves.

[EditUndo]

Introducing Quick-Agents

We've just dropped v0.4.2 of @artinet/sdk with an experimental "Quick-Agents" feature!

• Bundle & Test: Easily bundle your agent code (bundle util) and test it in a sandboxed environment (testDeployment util).
• Simplified Logic: Use taskHandlerProxy & fetchResponseProxy to streamline agent development and inter-agent communication.
• Alpha Stage: This is an early look! Test-agents are temporary (60s) and have some limitations (no direct FS/network).
• Beta Users: Full Artinet deployment is on the horizon! Join the waitlist: humans@artinet.io.

Check it out and let us know what you think!
npm: https://www.npmjs.com/package/@artinet/sdk
GitHub: https://github.com/the-artinet-project/artinet-sdk

[xtrasmal]

This is a silly pre-mature idea.

Agents aren't Apps
Agents are more like Processes, dynamically created around some tasks and will be disposed of when the task is completed.
Agents will be communicating over this gateway.
I'd like to coin the term Functional Agent. Disposable, composable and immutable.

Future thinking:
The only registry that makes sense is some kind of gateway, local neighbourhood. A mesh with a supervision tree.

[EditUndo]

Also @xtrasmal check out our latest release! We've introduced the idea of Quick-Agents (aka Agents-On-Demand). Similar to your description of Functional Agents, Quick-Agents persist on the artinet and are spun-up whenever a request to their dedicated endpoint is made. They are indeed disposable, composable and immutable.

[xtrasmal]

No, you don't understand me.

Agents aren't Apps.
Agents do not exist until a task is created, then some system will plan to what is needed to get the task done. This plan will result into a local mesh of required Agents. The agents will just be units with dynamically assigned tools and MCP's.

Local meshes can hold secrets or GDPR-sensitive metadata that never has to leave the jurisdiction. One should not even consider if MCP's should be allowed to reach external services outside the local cluster.

Agents are Processes. So they will be recognised by their PID, registered under a supervisor tree, discovered by a mesh.

In modern LLM systems the agent that fulfils a task rarely exists before the request and almost never lives beyond it; thinking of such entities as “products in an app store” is a category error.

Apps are static artefacts you install once; agents are processes that come and go in response to tasks, more like Erlang/Elixir pids or Kubernetes pods.

They need to be able to be discoverable within a mesh network. Local neighbourhood.

A2A 5.2 Discovery mechanisms
An URI or URL should be optional. I would like to have a Mesh-ID (gateway-scoped UUID) + optional DNS fallback.
Discovery not per GET /agent.json, but rather mDNS.

The "agent registry" should be a multi-tier registry: per-mesh index synced upward on a CRDT.

This means you keep a small, fast service/agent catalogue inside every local mesh, then let those catalogues gossip their changes into an eventually-consistent, global directory that is itself implemented as a Conflict-Free Replicated Data Type (CRDT). Local look-ups stay LAN-fast and tolerant of partitions; the CRDT layer guarantees that all tiers will converge on the same global view without any central database or leader election, so you escape a the “single-registry bottleneck”.

[EditUndo]

@xtrasmal I understand you completely and I'm assuming you're referencing the solution you've proposed here: https://www.solo.io/blog/agent-mesh-for-enterprise-agents ?

You're conflating a local/enterprise grade solution for ephemeral agents with a global durable discovery mechanism.

[EditUndo]

Additionally, I don't think you understand the solution I'm presenting. While we accept agent cards, artinet registrations themselves are protocol agnostic.

Nothing in our system prevents you from registering a list of trusted seeds or a Mesh-ID.

In fact, we've built elements of "subdomain management" into our system. Meaning as an owner of a particular subdomain you'll have the authority to approve registrations that publicly "claim" to be members of your network.

[EditUndo]

🦋🍃🌪️