What No One Tells You Before You Start Building Multi-Agent Systems (#3 Will Cost You a Week)

Rupayan — Wed, 15 Apr 2026 03:33:44 +0000

You've got the idea. You've got the LLM calls working. You've got an orchestrator that delegates to specialist agents. It's coming together.

Then agent A needs to call agent B — and everything stops.

Not because the logic is hard. Because suddenly you're staring at a list of infrastructure problems that have nothing to do with your product:

How does agent B know the request actually came from agent A?
What stops someone from replaying that same signed request ten minutes later?
What stops a runaway agent from hammering another one into the ground?
How does agent B even know what skills agent A is offering?
How do you pass a delegated task three hops deep without losing the chain of trust?

This is what no one tells you before you start. You think you're building agents. You're actually building a wire protocol.

Here are the seven things that will cost you weeks — and what to do instead.

1. Your agents have no identity

When agent A calls agent B, agent B has no proof who sent that request. Any caller who knows the endpoint can claim to be agent A.

The fix is Ed25519 message signing — every envelope signed with the sender's private key, verified against a published public key before any payload is processed. Simple in theory. But now you need keypair generation, key storage, a well-known URL to publish the public key, and signature verification on every inbound request.

Time cost: 2–3 days.

2. Signed messages can still be replayed

You've added signing. Now an attacker captures a legitimate request from agent A to agent B and replays it five minutes later. Without a nonce window, agent B executes the same action twice.

In a financial context: double transaction. In an orchestration context: duplicate task. In any context: silent corruption that's hell to debug.

The fix is a nonce store with a sliding time window — every message carries a unique nonce and timestamp, and the receiver rejects anything it's seen in the last five minutes.

Time cost: 1–2 days.

3. You have no rate limiting per sender — and this will cost you a week

This is the one that gets everyone.

You think rate limiting is a quick add. Then you realize you need per-sender limits (not just global limits), sliding window logic (not just fixed buckets), daily token budgets for LLM cost protection, and it all needs to run before your handler executes — not after.

A bug in a calling agent's retry logic will take down your entire agent network if you haven't built this correctly. And "correctly" takes longer than you think.

Time cost: 3–5 days.

4. There's no standard for agent discovery

How does agent A know what skills agent B offers? What communication modes it supports? What rate limits it enforces? What public keys to verify against?

Without a standard, every new agent you add to your network requires a bespoke integration — hardcoded URLs, manually shared schemas, out-of-band key exchange. Add a third agent and the coordination overhead compounds. Add a fifth and you've built a maintenance nightmare, not a network.

Time cost: 1–2 days per new agent added.

5. A rogue caller can invoke skills it was never meant to touch

Your internal orchestrator should have access to things a public caller shouldn't. But if trust is all-or-nothing — if the endpoint is reachable, the skill runs — then any agent that discovers your URL can attempt anything.

Tiered trust enforcement (public, authenticated, trusted-peers) needs to run before the handler executes, on every request, verified against the caller's identity — not just checked against an API key someone can steal. Building and maintaining that correctly is yet another system.

Time cost: 1–2 days.

6. Delegation chains get complicated fast

Agent A delegates a task to agent B, which needs to call agent C on A's behalf. Now you need signed delegation tokens with scope restrictions, depth limits, and a decrementing counter so the chain can't be extended indefinitely. RFC 8693 describes how. Implementing it is another matter.

Time cost: 2–3 days.

7. Your agents can be prompted against you

A compromised peer agent sends a payload crafted to hijack your LLM's behavior. If you're processing that input before verifying who sent it, you're running untrusted content through your system before authentication. The scanning needs to happen after signature verification — not before.

Time cost: 1–2 days to get the ordering right, and more when you inevitably get it wrong first.

The total: 2–3 weeks of work that has nothing to do with your product

Every team building multi-agent systems today writes all of this from scratch. Then they write it again on the next project. Then again.

This is the missing layer in every multi-agent stack — the wire protocol that handles identity, signing, replay protection, rate limiting, discovery, trust, delegation, and injection defense so you don't have to.

All seven problems. Gone. 15 lines.

npm install @samvad-protocol/sdk zod

import { Agent } from '@samvad-protocol/sdk'
import { z } from 'zod'

const agent = new Agent({
  name: 'Hello Agent',
  url: 'https://my-agent.example.com',
  rateLimit: { requestsPerMinute: 60, requestsPerSender: 10 },
})

agent.skill('greet', {
  name: 'Greet',
  description: 'Returns a personalised greeting',
  input: z.object({ name: z.string() }),
  output: z.object({ greeting: z.string() }),
  modes: ['sync'],
  trust: 'public',
  handler: async ({ name }) => ({ greeting: `Hello, ${name}!` }),
})

agent.serve({ port: 3002 })

That's it. When serve() runs, the SDK generates an Ed25519 keypair, publishes an AgentCard at /.well-known/agent.json, and starts handling all seven problems above — automatically, on every inbound request, in the correct order.

Call it from any other agent in three lines:

const client = await AgentClient.from('https://my-agent.example.com')
const result = await client.call('greet', { name: 'Ada' })
// { greeting: 'Hello, Ada!' }

No signing code. No nonce store. No rate limiter. No discovery boilerplate. The secure path is the fast path.

This is SAMVAD — an open-source agent-to-agent protocol with TypeScript and Python SDKs.

How it compares to MCP and A2A

You've probably looked at both. Here's the honest picture:

MCP (Anthropic) is excellent at connecting a single LLM to tools. It was not designed for two autonomous agents verifying each other's identity. No signing, no replay protection, no rate limiting — because its topology doesn't need them.

A2A (Google) is architecturally closer. But identity flows through OAuth 2.0 and OpenID Connect. Discovery assumes central registries and enterprise infrastructure. For a solo developer who wants to deploy a peer-to-peer agent network tonight, the on-ramp is steep.

	SAMVAD	MCP	A2A
Primary model	Agent-to-agent	LLM-to-tool	Agent-to-agent
Identity	Ed25519 keypair + domain	None built-in	OAuth 2.0 / OIDC
Message signing	Ed25519 on every envelope	No	No
Replay protection	Nonce + timestamp (5-min window)	No	No
Rate limiting	Per-sender + daily token budget	No	No
Auth infrastructure	None required	Developer-managed	OAuth/OIDC provider required
Setup	`npm install` + 15 lines	`npm install` + configure	OAuth + registry + deploy
SDK languages	TypeScript, Python	Python, TypeScript, others	Python, TypeScript

What SAMVAD doesn't do — honestly

Regex-only injection scanning by default. The built-in scanner catches obvious patterns. Adaptive attacks bypass it. An optional LLM classifier hook exists for stronger detection, but don't treat passing the scanner as a security proof.

Young ecosystem. MCP has Anthropic's backing. A2A has Google's. SAMVAD is an open-source project. The protocol is stable, both SDKs are tested and published, but the ecosystem of agents and integrations is early.

Use MCP, A2A, or SAMVAD?

Use MCP when you're connecting an LLM to tools — databases, APIs, file systems. It does this extremely well.

Use A2A when you're in an enterprise with existing OAuth infrastructure. It handles complex orchestration at scale.

Use SAMVAD when you want two agents on the internet to talk to each other securely, tonight, without setting up an identity provider. When your domain is your identity. When you want all seven problems above handled by the SDK so you can focus on what your agents actually do.

The code, protocol spec, and five live reference agents: github.com/w3rc/samvad

Try a live agent with no setup: samvad.dev/registry

npm install @samvad-protocol/sdk · pip install samvad

Which of these seven are you currently living with? Drop it in the comments — especially if you've found a better way to solve it than I did.

DEV Community: Rupayan