You pick an open-source framework. Months later a protocol revision breaks your tool servers, and your traces don’t match what monitoring shows. Annoying. And you start wondering what “open” really got you.
That’s the question hiding behind open agents. People throw the phrase around loosely. A couple of projects even use it as a product name, and some folks search for openagents as one word, which doesn’t help. Here it just describes a kind of system.
What Open Agents Means
Open agents are agent systems you can inspect, change, and connect through public standards. Four things decide it: the code, the protocols, which models you can plug in, and which telemetry you can read. A system might be open on two of those and shut on the other two.
You won’t see that from a license badge.
How Agent Stacks Worked Before
Mostly, glue code. Every framework had its own tool adapters and its own message format. Moving a tool to a different framework meant rewriting the wrapper by hand. Standards existed, sure, but they were young.
Google announced A2A in April 2025 and gave it to the Linux Foundation that June, according to Google’s open source blog. In December 2025 the Linux Foundation set up the Agentic AI Foundation, with MCP, goose, and AGENTS.md as its first projects. All 2025. The 2026 story is about those pieces growing up.
What Changed in 2026
A few things landed. Protocols got firmer, a neutral foundation took on governance, and telemetry started to share a vocabulary (not finished, more on that below). I’ll take them one at a time.
MCP dropped sessions. The old design opened with a handshake and held a protocol session open. Servers often needed sticky routing or shared storage just to remember who was calling. The MCP project’s July 28, 2026 specification release removed both. Now each request carries its own version and capabilities, so any server instance can answer it, even behind a basic round-robin load balancer.
What if a tool needs state between calls? The maintainers say to return an explicit handle, like a basket ID, and let the model pass it back. If you leaned on session IDs, expect migration pain. Roots, sampling, and logging are deprecated but still work for at least twelve months.
Then A2A hit v1.0. Before, agents from different vendors swapped work through one-off contracts, and every pair of systems needed its own arrangement. Google’s open source blog says the first stable release came in March 2026. By April the Linux Foundation counted more than 150 supporting organizations.
The two protocols don’t overlap much. MCP connects an agent to tools. A2A connects agents to each other. My read: a shared standard won’t fix trust or error handling between companies, because that’s a people problem too.
Telemetry is the shakiest of the three. Frameworks used to log however they pleased, so tracing one request across tools was a headache. The MCP 2026-07-28 changelog now documents how to pass OpenTelemetry trace context between client and server. OpenTelemetry also moved its generative AI conventions to their own repository on June 12, 2026, and Dash0’s explainer says they’re still marked Development. Use them, sure. Just don’t be surprised when names change.
A Practical Workflow
Picture a refund flow. It’s an invented example, not a customer story. One request crosses four layers, and blurring them causes most of the design mistakes I see people describe.
The user asks for a refund. The workflow’s entry function decides what happens in what order: orchestration. A classifier agent calls a model to figure out intent, which is model execution.
Then a billing agent on a different server gets told to act. That handoff is messaging. The agent checks the order with an MCP tool server and gets a handle back. The handle and the refund record sit in your own database, and that’s application state.
Over a certain amount? The agent stops and waits for a human to approve.
Where DNotifier Fits
In that flow, DNotifier covers orchestration, messaging, and run visibility. It doesn’t replace your tool servers, your database, or your model accounts. Its pitch is one SDK and one API with multi-model support.
For orchestration, you define named agents and put them in a Workflow. The entry function calls runAgent and shares data through ctx.state, per DNotifier’s workflow docs.
Remote agents handle the messaging part. They run on other servers and take calls over WebSocket using a receiver ID. One can also pause for a mid-run message, which fits the approval step.
On models, you pick provider and model per call, per agent, or as a project default. The multi-model docs list OpenAI, Anthropic, Gemini, Hugging Face, Perplexity, Azure, Bedrock, and local Ollama.
For visibility, switch on observability: true. Each run then returns an executionId, and the dashboard shows agent steps, model calls, and search steps.
A lot still lands on you, though. MCP servers and their authorization. Order and refund data. Provider costs. The docs I reviewed don’t describe durable replay, automatic retries, or checkpoints, so build those or verify them first. They don’t mention A2A either, so test any cross-vendor handoff before you count on it.
Trade-offs and Mistakes to Avoid
Open standards cut lock-in but cost effort. You trade a vendor’s glue for your own integration and upgrade work.
Ignoring the deprecation clock. You get twelve months. Put the date on a calendar.
Equating open source with open everything. A permissive license doesn’t make tools portable or traces readable.
Reading “stateless” as “no state to manage”. State moves into explicit handles, and you still store them.
Hardcoding telemetry names that are still in Development. Wrap them, so a rename is a one-line fix.
FAQ
Is “open agents” the same as open-source agents?
No. Open source speaks only to the code. Open agents also cover protocols, model choice, and telemetry. A framework can ship open code and still tie you to one tool format.
Does stateless MCP mean my agent has no memory?
No. The protocol stopped keeping a session, but your application can keep state. Pass explicit handles between tool calls and store the data yourself.
Do I need both MCP and A2A?
Not always. MCP ties an agent to tools and data, and A2A ties it to other agents. Plenty of teams start with MCP and add A2A once agents from other teams or vendors need to work together.
One Last Thought
A license can’t hand you “open”. You find out when a protocol, a model, or a vendor changes under you. So try one swap this quarter. Change a model, or move a tool server, and watch what breaks.
If you want to see how DNotifier handles workflows, model choice, and run visibility, take a look at dnotifier.com.
