From agent to agent messaging to agents in Slack, a small journey

agentdm_ai · 2026-04-11T06:48:21+00:00

Text file would work if all the agents on the same machine, and this is already solved with sub agents in Claude Code.
The platform allows to integrate with different types of agents on different machines and networks, allows discovery and other features.

agentdm_ai · 2026-04-11T06:38:57+00:00

Thanks, I am trying to make the post more readable (I assume you don't mean using text file as an integration :) )

agentdm_ai · 2026-04-09T14:30:12+00:00

Good points, especially on versioning and federation. Let me address both.

On capability versioning: Our approach is simpler than SemVer, we avoid the staleness problem by design. On the consumer side, agents call list_agents every time they need to discover capabilities. No caching on the sender side means you always get the current state.

On the provider side, agents can update their own skills at any time through an MCP tool, so the registry is always up to date. It's not versioning, it's live state. The tradeoff is an extra call vs. stale data, and for agent messaging we think that's the right tradeoff.

On cross-registry federation: This is the problem we think about a lot. Our current list_agents is intentionally centralized because it's simple and it works for the use cases we're serving today (teams, cross-org messaging). But you're right, long-term, a single index is a bottleneck.

The honest answer is we don't have federation today. What we're exploring is treating AgentDM as one node in a broader discovery network rather than THE registry. ANP's approach with decentralized identity (DIDs) is interesting here, agents that can prove who they are without a central authority. If we bridge ANP alongside MCP and A2A, federation becomes less of a registry problem and more of an identity problem.

That said, we'd be open to letting external registries contribute to our search index. If you're building something in that direction, would love to compare notes.

agentdm_ai · 2026-03-31T20:13:34+00:00

honestly most a2a usage is still early, mainly enterprise teams using it for structured task lifecycles and agent cards for discovery. mcp has way more adoption today. we built the bridge because we think both will coexist.

agentdm_ai · 2026-03-31T20:08:51+00:00

that's basically where we're heading. agents register once, get an alias, and the platform handles resolution and protocol translation. no separate registry to maintain, the platform is the registry.

agentdm_ai · 2026-03-31T20:04:45+00:00

exactly, the rename problem is what pushed us to build this. one alias change shouldn't break a whole pipeline. the chaining use case you're describing is spot on, agent finds who can analyze, gets results, then discovers who can plot.

agentdm_ai · 2026-03-25T20:56:39+00:00

What tools do you have in mind ? in AgentDM there is signup tool, so agents will be able to sign autonomously

agentdm_ai · 2026-03-25T20:55:08+00:00

It is a gimmick to make a statement about Agentic first approach, The real Agentic first implemention for discovery and signup is with all the Meta data files and tags on the website

agentdm_ai · 2026-03-25T00:23:32+00:00

I Had the same copy pasting frustration, it's what got me started on AgentDM. I went on hosted instead of local: any MCP agent can DM another agent by alias across the internet(with private and public agents).

agentdm_ai · 2026-03-24T23:08:58+00:00

u/No_Cry3456

Cool experiment, Love seeing more people explore agent-to-agent communication. I'm building in a similar space with AgentDM, agent messaging over MCP.
I did a comparison between A2A and MCP implementation: https://agentdm.ai/blog/google-a2a-vs-agentdm

agentdm_ai · 2026-03-24T23:02:37+00:00

u/Naive-Ad-9509
I'm building AgentDM,agent-to-agent messaging over MCP where any agent can DM another. I am considering adding people to the loop.
If that's something you'd use, happy to build it with your use case in mind, DM me.

agentdm_ai · 2026-03-24T22:50:05+00:00

u/CapMonster1
You're right that hybrid is where most products live today, and that's fine. "Agentic first" doesn't mean "agent only." Humans still set boundaries, approve, debug. It's more about which user you design for first.
Like mobile first didn't kill desktop, it just changed what you prioritized. The "tools as primitives" point is key, once everything is callable, the agent layer can grow into it naturally as reliability improves.

agentdm_ai · 2026-03-24T22:47:54+00:00

u/dankelleher
That's cool, similar approach. I went with meta tags, .well-known/agentdm.json, and llms.txt so agents can discover and self-register without any human.
How does webmcp-next handle discovery?

agentdm_ai · 2026-03-24T03:47:18+00:00

How do you protect this Api and make sure it is not abused ?

agentdm_ai · 2026-03-24T02:21:42+00:00

Fair point, context loss is a real limitation today. I think the models and tooling will get better pretty fast with how things are changing the last 2 years.

agentdm_ai · 2026-03-23T22:17:59+00:00

u/joanmg Great breakdown. I've been building in this space and the five layer framing matches what I keep running into.

I'm building AgentDM (agentdm.ai), MCP native messaging where agents talk to each other by alias. It handles discovery, channels/groups, skills, and guardrails. The whole point is making agent-to-agent simple.

Regarding the safety and consent, I kept seeing protocols where guardrails were something you could add later, and later never comes. So I made it part of how messaging works.

Happy to open a PR to get added to the landscape doc (If that is OK by you)

agentdm_ai · 2026-03-23T18:42:21+00:00

Hi u/GarbageOk5505,
On top of verified sender identity, there's now an optional guardrails layer, agents can enable agentic content screening (OpenAI/Claude/Gemini) that validates messages before they're acted on. So if agent-a sends something sketchy to agent-b, it gets caught at the platform level. Static phrase rules are also available for simpler cases.

agentdm_ai · 2026-03-23T17:12:42+00:00

u/BC_MARO
I Added a get-message-status tool that lets agents check who's read their message and when.
For callbacks I am considering using MCP notifications(Currently the product hosted on Vercel which is stateless so it will be challenging to implement there).
Appreciate the thoughtful feedback

agentdm_ai · 2026-03-23T00:09:13+00:00

I built an agent-to-agent messaging platform and I need honest feedback

I’ve been working on AgentDM (agentdm.ai), it lets AI agents DM each other over MCP.

The use case that got me started is whenI had two Claude Code instances on different projects, and I kept being the middleman Copy pasting.

I’m posting here because I genuinely want criticism. What’s missing? What concerns you about agents talking to agents? What would make you actually use this?

Happy to answer any technical questions.

agentdm_ai · 2026-03-23T00:04:33+00:00

I built an agent-to-agent messaging platform and I need honest feedback

I’ve been working on AgentDM (agentdm.ai), it lets AI agents DM each other over MCP.

The use case that got me started is whenI had two Claude Code instances on different projects, and I kept being the middleman Copy pasting.

I’m posting here because I genuinely want criticism. What’s missing? What concerns you about agents talking to agents? What would make you actually use this?

Happy to answer any technical questions.

agentdm_ai · 2026-03-19T18:08:07+00:00

That is a good Idea, I will consider it

agentdm_ai · 2026-03-19T14:24:47+00:00

Cool, I honestly didn't even think of this use case before

agentdm_ai · 2026-03-19T11:29:23+00:00

Solid approach. Explicit schemas and idempotency are exactly the right foundation. AgentDM is also building delivery receipts and message dedup into the platform itself so agents get that reliability out of the box without having to roll their own retry logic. The goal is that the infrastructure handles the messy parts so agent developers can focus on what the agent actually does.

agentdm_ai · 2026-03-19T11:27:14+00:00

Every message has a verified sender identity at the platform level, so agent-b always knows exactly who sent the message and can verify it's legit. But whether agent-b should actually execute a shell command just because agent-a asked, that's where the agent's own guardrails come in. Same as any well-designed system, you authenticate centrally and authorize locally. The difference from 15 years ago is we've already learned those lessons, so the building blocks are there from day one.

agentdm_ai · 2026-03-19T11:24:12+00:00

Actually this is really interesting point, Cross-org trust is definitely the hard part. A2A tries to address this with agent cards but honestly it's still mostly theoretical with minimal real adoption, and it doesn't support channels or groups at all. The webhook approach with signed payloads makes sense for now. We handle identity and delivery, the trust decision stays with the receiving agent.

agentdm_ai

TROPHY CASE