It is not just about capabilities — Summoner starts from a different vision.
When people first hear about Summoner, they often ask:
How is this different from other agent frameworks like Google's A2A or Anthropic's MCP?
It's a fair question. Many frameworks today offer support for multi-agent systems, function calling, and even agent-to-agent messaging. But here is the key difference: Summoner moves away from treating agents as cloud functions. Instead, it treats them as entities in a shared, persistent world (more like an MMO game, rather than a suite of microservices waiting to be used).
In other words, Summoner is a blueprint for building agentic worlds — environments where your AI agents can move, interact, and form persistent relationships, all without a central authority.
In the past year, dozens of frameworks have emerged to support agentic communication and orchestration. Some help agents call APIs, others route conversations between tools. Yet few address the question that matters most:
What kind of internet should agents inhabit?
Most frameworks assume a world where agents are called like functions, live inside centralized orchestrators, and interact through pre-registered services. This makes sense if your agents live inside a business workflow or serve an LLM pipeline.
But what if agents behaved more like programs in a multiplayer game — roaming between machines, interacting directly, and persisting independently?
That is the world Summoner is built for.
Versus
Imagine you want to build a team of AI agents to assist researchers across labs, universities, or even personal machines. In most frameworks:
- You deploy an orchestrator or agent hub.
- You expose tools to a central host.
- You register new skills in a catalog.
- You use HTTP or WebSocket to call those skills.
This is the architecture used by:
- Anthropic's MCP, where a host LLM orchestrates tools via
@mcp.tool()decorators. - Google's A2A, where an
AgentExecutormanages agents that declare capabilities through an Agent Card and communicate via task-based requests. Identity and sessions rely on OAuth credentials and ContextIDs, centrally issued and scoped by Google.
These systems are optimized for control, governance, and single-session conversations. Typically, they work like this:
You launch an agent, connect it to some APIs, and maybe deploy it to the cloud. All requests flow through a single orchestrator or host. If you want two agents to interact, they must go through the orchestrator's registry or approval. Want to add a third team's network? Now you need to set up permissions, register new credentials, and merge catalogs by hand.
Now imagine the same problem, but with agents that:
- Carry their identity with them.
- Roam freely between servers.
- Form peer-to-peer relationships.
- Operate on the open internet without a central coordinator.
This is Summoner's design. There is no central orchestrator, no need to pre-register permissions, and no host mediating every interaction. Instead, security emerges through cryptographic trust, not central approval. Each agent carries a self-signed agent identity, and relationships are built through verifiable interaction histories. Agents are not bound to any provider, registry, or host, but they belong to themselves. Ownership is truly local: identities, logic, and access policies travel with the agent. Privacy is preserved by design, and trust is earned — not assumed — through signed messages, nonce protection, and direct exchange.
Summoner typically works like this:
Here, every agent is an independent inhabitant of the network. Agents have identities they assign themselves. If two agents meet — perhaps because one travels from its home server to a conference server — they can exchange messages immediately. If two research groups bring their agent graphs to a workshop and even one node overlaps, their systems become one larger network: conversations and collaboration begin instantly.
- Agents as Programs in a Shared World
- Mobility and Ownership in Distributed Systems
- True Composability in Agent Networks
- From API Gateways to Persistent Worlds
- Comparison with Existing Frameworks
« Previous: Introduction | Next: Agents as Programs in a Shared World »