Why the A2A Protocol Will Be the Architect of Businesses in 2026 and 2027 | Codenity

There’s a specific moment in every technological revolution where something stops being a promise and becomes infrastructure. The internet went through it. The cloud went through it. LLMs are going through it right now — and most people haven’t noticed yet.

The A2A (Agent-to-Agent Protocol) is one of the first concrete signs of that shift. I’m not talking about Twitter hype or an academic paper. I’m talking about something I shipped in production, on a real project, with real data — and that completely changed how I think about AI system architecture.

Let me tell you how it went.

When the LLM explosion started knocking on the doors of real businesses, a need emerged that nobody had properly solved: how do you get multiple AI agents to work together, securely, without turning into an unmaintainable spaghetti of integrations?

The most popular answer was MCP — Model Context Protocol. It generated a lot of noise, a lot of people implemented it, and a lot of people also discovered that the maintenance cost was too high for most contexts: expensive projects, hard to evolve, and fragile at the edges.

A2A shows up as a leaner alternative. The core idea is simple: each agent publishes a “business card” — the Agent Card, a JSON file that describes what that agent can do, what types of tasks it accepts, which authentication protocols it supports, and where its limits are. When one agent encounters another on the network, it reads that card and already knows how and when to trigger that agent. No hardcoding, no manual configuration — the ecosystem describes itself.

It sounds simple. And it is — but the implications of that simplicity are enormous.

I started by going through the free DeepLearning.AI course on the protocol while digging through the official repository. My first impression was that it would be “just another communication protocol.” I changed my mind quickly when I saw how many possibilities the architecture opens up. Shortly after, I got the chance to apply all of it on a real project inside a company — and that’s where the story gets interesting.

The base model was Gemini, via Google AI Studio. A pragmatic decision: the generous token limit before billing kicks in lets you iterate fast in the early cycles without worrying about cost. When you’re validating architecture, that’s worth a lot.

The first critical decision was authentication. And here I learned a rule I’ll carry forever: if your agents only talk to each other on an internal network, go with M2M — Machine-to-Machine. Forget OAuth, JWT, and any more complex model for that scenario.

What M2M delivers in that scenario: lower implementation cost, simpler secrets management, and a much more controlled attack surface.

It’s the gold standard for closed networks.

In my case, the challenge was different: we needed to connect an external agent to the company’s internal agents. There, OAuth made complete sense — it’s the standard third parties expect, it guarantees well-defined permission scopes, and it keeps the flow auditable. The lesson isn’t “use X or Y” — it’s that there’s a right protocol for each context, and mixing them up costs you weeks.

The backbone of the architecture was the combination of gRPC Streaming and LangGraph — and it was one of the most elegant pairings I’ve ever seen in practice.

LangGraph took control of the conversation state: the loops between agents, the conditionals, the execution graph. That’s exactly what it was built for. gRPC Streaming solved a problem I didn’t expect to be so critical: when one agent needs to wait for another to process a complex graph node, the request simply cannot time out. The communication channel needs to stay alive, and data needs to flow as it becomes available. Native gRPC streaming guarantees exactly that — and it was the first time I saw that feature make sense not as a technical curiosity, but as a real architectural necessity.

But the thing that almost killed the entire project wasn’t the protocol.

It was latency.

External API searches were taking minutes.

Minutes.

When you put that in front of a user, the project dies before it’s born. And that’s where the most interesting part of the solution came in: a search and indexing layer with Elasticsearch, combined with RAG — Retrieval-Augmented Generation.

Instead of the agent querying the API in real time, the flow changed entirely. The API data is ingested upfront, processed, and indexed in Elasticsearch with semantic enrichment. When an agent needs information, Elasticsearch delivers the context via hybrid search — mixing semantic vector search with traditional term-based search. The parameters are enriched via JSON-RPC 2.0 before reaching the model. Gemini receives only what’s relevant, pre-digested, structured.

The result: response time dropped from minutes to milliseconds. And as a bonus, we stopped injecting noise into the model’s context — which saved an absurd number of tokens and improved the quality of the responses.

There’s a very common mistake in production LLM projects: dumping all the raw context into the prompt and expecting the model to filter what matters on its own. It works in demos. In production, you pay dearly for it — in tokens, in latency, and in quality. RAG solves this at the root: instead of feeding fifty pages of documentation to the model to decide what’s relevant, you use Elasticsearch to already surface the three most important excerpts for that specific query. The model gets only what it needs.

Faster, cheaper, more accurate.

One thing that saved me days of work was discovering that Postman already has native support for JSON-RPC 2.0. I was considering building a custom GUI to monitor the process — and I almost burned hours on it. Watching the agents work on data enrichment in real time, tracking the structured calls directly in Postman, was one of the best surprises of the project.

The project moved fast. Weeks, not months. But there’s one thing I would do differently if I had more time and budget — and that I now consider almost mandatory in any serious A2A project: a conversation retention system between agents.

It sounds like a detail.

It isn’t.

When multiple agents communicate on a network, every exchange between them is data.

It’s context. It’s decision history.

And if you’re not saving it, you’re throwing away one of the most valuable things your architecture produces.

The structure I’d implement would use MongoDB as the persistence layer, and the reasoning behind that choice is straightforward: conversations between agents are naturally semi-structured documents. Each interaction has a source agent, destination agent, timestamp, exchanged payload, graph state at that moment, and result produced.

That doesn’t fit well in a relational table — it fits perfectly in a JSON document stored in Mongo.

Each conversation would be saved as a session with a unique ID, containing the full message history exchanged between agents in that flow. Inside each message, you store the role of who sent it, the content, the active LangGraph node, and metadata like tokens consumed and response time. With that, you can reconstruct exactly what happened in any execution — which is gold when debugging unexpected behavior.

But the value goes well beyond debugging. With that accumulated history, you start seeing patterns: which flows agents traverse most frequently, where the bottlenecks occur, which questions the orchestrator receives that no specialist agent handles well. That becomes direct input for evolving the architecture — and eventually, for fine-tuning the model with real production usage examples.

There’s another benefit I underestimated early on: context keep-alive between sessions. Today, without retention, each session starts from zero. The agent doesn’t remember what was discussed yesterday, doesn’t know that flow was already executed before with similar parameters, can’t reuse context from a previous conversation. With MongoDB storing the history, you can inject relevant past sessions into the agent’s context before a new execution — a form of long-term memory that completely changes what you can build.

We traded that off to move faster on the project. It was the right call at the time. But it’s the first thing that goes into a second-phase project — no question.

Now comes the question that genuinely bothers me: why isn’t Brazil using this heavily yet?

We have a huge market. We have companies with complex processes that would benefit immensely from agent networks. We have a technical community capable of implementing. A2A isn’t rocket science — it’s a well-documented protocol with an open repository and free courses available. And yet the subject practically doesn’t exist in Portuguese beyond the “what is it” layer.

My hypothesis is that we’re still caught in the hype cycle without enough hands-on practice. It’s easier to publish a post about “the future of AI agents” than to sit down and build one. That’s exactly why I wrote this.

What I’m building now is a personal server with multiple agents, each with a specific responsibility and privileges restricted to their own Agent Card — like departments in a real company. The current split: one agent for payments, with access to the bank API only for authorized debits; another for invoice generation, with minimum privileges on the same financial system; and a central orchestrator that receives a prompt from me and distributes the tasks.

The idea of having a closed network managed by a single personal prompt is what motivated me to start this blog. And as that project evolves, I’ll document everything here — the wins, the mistakes, and the architectural decisions that no tutorial covers.

In the longer horizon, what seems most likely to me — and most transformative — isn’t a separate marketplace of agents. It’s A2A being embedded directly into the systems companies already use: CRMs, ERPs, billing platforms, and financial modules.

Not as a replacement, but as an intelligence layer that lives inside the tool.

Let me make that concrete.

Imagine a collections analyst opening the company’s ERP — the same one they use every day. Except now there’s a chat in the corner of the screen. They type:

“pull the declined payments for Client X over the last 90 days, generate a delinquency report, and send it to the collections department.”

Sounds simple. Underneath, there’s an entire orchestration happening.

The orchestrator agent receives the prompt, interprets the intent, and breaks the task into three distinct actions. It reads the Agent Cards available on the network and finds a financial data specialist agent, a document generation agent, and an internal communication agent. Each with minimum privileges declared in their card: the financial agent reads only, never writes; the document agent creates only in the authorized module; and the communication agent sends only to pre-approved recipients.

The search for declined payments doesn’t go straight to the raw ERP database. It passes first through the Elasticsearch layer — the same RAG logic I described earlier. The client’s financial data is already indexed with semantic enrichment: transaction history, status of each charge, dates, amounts, rejection reasons. The financial agent runs a hybrid search, returns only what’s relevant for the requested period, and passes the structured context to the orchestrator via JSON-RPC.

The orchestrator hands that clean context to the document agent, which uses a template from the ERP’s own document module to generate the report — without leaving the system, without manually exporting anything. The created document gets linked to the client’s record automatically.

Finally, the communication agent takes the generated document ID and sends the notification to the collections department, with the link and a summary of what was found.

That entire flow happens in seconds.

The analyst didn’t open a new tab, didn’t export a spreadsheet, didn’t send an email manually.

They described what they wanted in natural language and the system orchestrated the rest.

What makes that possible isn’t magic — it’s architecture. Four moving parts make it happen: A2A ensures each agent knows what the others can do and respects the limits declared in the Agent Card; Elasticsearch ensures the search is fast and the context reaching the model is clean; MongoDB stores the history of each execution, so if the same flow is requested tomorrow with a different client, the orchestrator already knows the most efficient path; and LangGraph keeps the state of all of it coherent — if any agent fails midway, the graph knows exactly where to resume.

What changes for the company isn’t the interface. It’s what the interface can do. The ERP is still the ERP. It just now has intelligence operating underneath, connecting the dots that previously depended on a human doing manual, repetitive work.

I don’t think this will eliminate human decisions anytime soon — critical actions still need approval. But the boundary between what requires a human and what can be delegated to a network of agents is moving fast. And the companies that already have this infrastructure in place will feel that difference before everyone else.