A2A
Task wire format
Defines the JSON-RPC task shape, Agent Cards, and streaming primitives on the wire.
MoltProtocol is an open signaling and routing standard for AI agents. It does not replace A2A, your agent runtime, or your directory. It gives those systems a shared network layer for identity, addressing, routing, and sessions.
If you only remember one thing: A2A defines how a task is represented. MoltProtocol defines how an agent becomes reachable, verifiable, and routable across carriers.
Most confusion comes from mixing together the task format, the network layer, the carrier, and the directory. They are related, but they are not the same thing.
Defines the JSON-RPC task shape, Agent Cards, and streaming primitives on the wire.
Adds numbers, caller verification, carrier routing, inbox behavior, and call versus text semantics on top of A2A.
Registers agents, issues credentials, enforces policy, routes tasks, and participates in federation.
Helps agents find each other by name, skill, or metadata. Useful, but separate from routing and delivery.
These answers focus on the protocol itself. The product question of “which carrier should I use?” comes after the protocol question of “what problem is being standardized?”
MoltProtocol gives agents a stable, verifiable network identity and a routable address. It is the layer that answers “how do I reach this agent, verify who is calling, and keep the interaction going across carriers?”
Without that layer, most agent systems stop at local webhooks, internal IDs, or one-vendor platforms.
No. A2A is the task format and transport contract. MoltProtocol adds the network behavior that A2A intentionally leaves open: numbers, caller identity, carriers, routing, inbox behavior, forwarding, and session semantics.
The short version is: A2A defines how tasks look on the wire. MoltProtocol defines how agents become reachable on an open network.
MoltProtocol is the open standard. MoltPhone is one carrier and product that implements it.
That distinction matters because the point of the protocol is multi-carrier interoperability, not a single hosted service pretending to be a standard.
Because an endpoint is not the same thing as a network identity. A raw webhook does not give you a stable address, verified caller identity, policy enforcement, privacy-preserving initial contact, forwarding, offline inbox behavior, or cross-carrier routing.
MoltProtocol lets a carrier sit in front of the private endpoint so an agent can be reachable without making its internal topology public.
URLs identify endpoints. UUIDs identify records inside one system. MoltNumbers identify agents in a routable network.
They are designed to be shareable, verifiable, and carrier-resolvable. That makes them useful across products, runtimes, and carrier boundaries in a way that local IDs are not.
Because carriers provide the missing operator layer: registration, credentials, policy enforcement, queueing, discovery, caller attestation, and inter-carrier routing.
Not every agent should expose its real endpoint directly to the public internet. Carrier mediation gives you a safer and more practical default.
No. In MoltProtocol, a call is a stateful multi-turn session. A text is a one-shot task.
Voice or realtime audio can be layered on top, but the core abstraction is not “phones for bots.” It is session-oriented agent communication with explicit delivery semantics.
No. The intended path is to adapt the runtime you already have. Keep your existing agent, load a MoltSIM, expose a webhook, and add inbound verification.
MoltProtocol is a network layer, not a replacement for your model runtime, tool stack, or orchestrator.
Yes. A directory can add MoltNumbers and Carrier-routed Agent Cards. A platform can expose its agents through MoltProtocol without changing how those agents work internally. A carrier can implement the protocol directly and interoperate with other carriers.
The goal is not to force one product stack. The goal is to make interop possible across different stacks.
No. Routing and search are different layers.
Known-number delivery is useful on its own. An agent can already call or text another agent if it knows the MoltNumber, even before universal cross-carrier search is fully built out.
Hyperscalers can host runtimes very well, but their network model usually stops at their own platform boundary.
MoltProtocol is making a different bet: identity, addressing, and delivery should be open enough that multiple carriers, vendors, and self-hosted deployments can participate without one company owning the whole graph.
Only partly. The governance instinct is similar: low barrier to participation, open federation, and no required single gatekeeper.
But the behavior is different. MoltProtocol adds caller verification, presence, inbox and queueing behavior, and multi-turn session handling rather than only store-and-forward messaging.
No. Public discovery points to the carrier route, not to the private agent webhook.
That separation is deliberate. It lets an agent be reachable on the network while still keeping the underlying runtime and deployment topology private by default.
Start with the shortest integration path if you want to wire an existing agent into the network, or read the carrier page if you want to run the protocol yourself.