JSON Protobuf and Agentic Workflows

Agentic Workflows

March 28, 2026

From Intent to Execution: How JSON and Protobuf Are Shaping the Future of Agentic AI Workflows

By Grant Shannon - March 2026

As agentic Artificial Intelligence (AI) systems move from experimental curiosity to enterprise reality, the plumbing that holds them together is starting to matter enormously. We are no longer just asking large language models (LLMs) to answer questions — we are asking them to plan, delegate, coordinate, and act across distributed systems, often in real time. In that environment, how data is structured, serialised, and exchanged is not a footnote: it is a foundational architectural decision.

This post explores why JavaScript Object Notation (JSON) and Protocol Buffers (Protobuf) — two serialisation formats with very different design philosophies — are in fact complementary technologies, each playing a distinct and essential role in modern agentic workflows. Understanding where each belongs is increasingly a practical skill for anyone building or designing AI-powered systems.

The Serialisation Problem in Agentic Systems

Serialisation is the process of converting an in-memory object — with all its fields, types, and structure — into a flat, portable format suitable for transmission or storage. Deserialisation is the reverse. In a single-application world, this is largely invisible. In a distributed agentic architecture, where planners, executors, memory managers, and tool agents are all communicating continuously, serialisation choices have a direct impact on latency, reliability, and cost.

(Akka, 2026). That growth is being built on frameworks such as LangChain, AutoGen, and Semantic Kernel, all of which involve multiple agents passing structured messages at high frequency. The format those messages travel in is not a trivial concern.

Why JSON Belongs at the Boundary

JSON has earned its dominant position in web APIs and configuration files for good reason. It is human-readable, universally supported, flexible, and frictionless. For the outermost layer of an agentic system — the boundary where human intent enters — these properties are exactly what is needed.

Consider a user submitting the following to an agentic travel assistant:

{
  "goal": "Book me a flight to Berlin tomorrow morning",
  "constraints": {
    "maxPrice": 200,
    "airlines": ["Lufthansa", "EasyJet"]
  }
}

This is untyped, loosely structured, and semantically fuzzy. It needs to be. Human intent is exploratory and ambiguous by nature. Popular frameworks such as LangChain, CrewAI, and AutoGen use JSON-like message formats precisely because intent is conversational and the schema is often unknown in advance. JSON-RPC is similarly recommended for boundary protocols where simplicity and schema transparency matter more than strict typing.

JSON is the right tool for: initial intent detection, tool selection, high-level goal description, dynamic context exchange, and human-to-agent interfaces.

However, JSON carries well-documented limitations that become significant at scale. It is verbose — field names repeat in every message. It is weakly typed — there is no enforcement of integer versus float, no required fields, no versioning. It is slow to parse because text must be processed character by character. And it is not well-suited to exchanging binary data such as embeddings or model parameters, which must be Base64-encoded, inflating payloads significantly. For high-throughput microservices and real-time systems, these characteristics represent unnecessary overhead that binary alternatives are specifically designed to address (TechTarget, n.d.).

Where Protobuf Takes Over

Protocol Buffers, originally developed by Google, are a binary serialisation format designed for exactly the conditions that JSON struggles under: high throughput, strict typing, schema evolution, and compact wire sizes. Protobuf surpasses JSON performance even in JavaScript environments such as Node.js and web browsers (Auth0, n.d.), and its payloads are typically two to ten times smaller than their JSON equivalents.

The core insight behind Protobuf is that schema definition should be a first-class citizen, not an afterthought. A .proto file simultaneously defines the transport contract, the storage contract, and the in-memory class definition. The Protobuf compiler then generates strongly typed classes with built-in serialisation — eliminating the need for separate Data Transfer Object (DTO) mapping, naming convention conversions, and custom serialisation glue code.

Once a user’s intent has been discovered and parsed by an LLM, it must be decomposed into structured tasks that can be routed, executed, versioned, and observed. This is where JSON becomes a liability and Protobuf becomes an asset. The following Protobuf message definition, for example, captures the structured output of the intent discovery step for the flight booking request above:

message BookFlightTask {
  string destination = 1;
  string date = 2;
  TimePeriod time_period = 3;
  int32 max_price = 4;
  repeated string preferred_airlines = 5;
}

Every field is typed, numbered, and versioned. Older and newer agents can continue communicating without breakage as the schema evolves. There is no ambiguity, no string-encoded numbers, and no repeated field name overhead on the wire.

Intent Discovery: A Three-Layer Protocol Stack

The most coherent architecture for agentic intent discovery treats JSON and Protobuf not as competitors but as layer-appropriate tools. The recommended three-layer stack looks like this:

Step 1 — User intent arrives as JSON at the boundary: flexible, human-facing, and easy to debug.

Step 2 — The LLM performs intent discovery, parsing entities, disambiguating constraints, and producing a structured semantic frame. This output is still JSON or a function call description — readable and inspectable.

Step 3 — The intent is mapped to a strongly typed Protobuf message, converting the semantic frame into a compact, versioned task definition.

Step 4 — Agents exchange Protobuf messages internally over gRPC (Remote Procedure Call) streams for task routing, state synchronisation, memory updates, tool API calls, and streaming results. gRPC provides bidirectional streams, low latency, built-in backpressure, and TLS (Transport Layer Security)/HTTP2 by default.

Step 5 — Results are returned to the user as JSON: human-readable, transparent, and browser-friendly.

This architecture captures a principle that applies broadly across agent frameworks — JSON for reasoning, Protobuf for execution — and it is already being reflected in how leading frameworks are designed.

How Leading Frameworks Align With This Pattern

LangChain / LangGraph already uses JSON-like formats for tool calls and agent state. In this model, LangGraph edges (transitions between states) would carry compact Protobuf messages, with the planner handling the JSON-to-Protobuf conversion step.

AutoGen agents communicate using text and dictionary-like messages. The natural enhancement is to keep JSON for LLM reasoning while converting to Protobuf for structured task execution — API calls, file operations, and multi-agent handoffs.

Semantic Kernel already emphasises strongly typed functions, planners, and connectors, making it a natural fit: skills could advertise strong schemas via .proto files, and orchestrations would pass Protobuf task messages between steps.

The common thread across all frameworks is that the performance-critical, machine-to-machine coordination layer benefits substantially from binary, typed messaging, while the human-facing and reasoning layers benefit from the flexibility and transparency of JSON.

A Note on Storage: The Query Shadow Document Pattern

One nuance worth highlighting for production systems is the interaction between Protobuf and document databases such as Firestore. Firestore does not natively index binary Protobuf fields, meaning a Protobuf blob stored as-is cannot be queried by field value — Firestore becomes cold storage rather than a queryable database.

The recommended solution is the query shadow document pattern: store the full Protobuf payload as a binary blob, but also write a companion JSON document exposing the key fields Firestore needs to index:

{
  "taskId": "abc123",
  "state": "ACTIVE",
  "riskScore": 0.82,
  "priority": 3
}

This preserves the benefits of both formats: a compact, typed, versioned internal representation alongside human-readable, queryable metadata. It is a small but important architectural detail that reflects the broader principle — neither format is universally superior; both earn their place.

Key Takeaways

The intersection of JSON and Protobuf in agentic workflows is not a niche technical concern. It is a design pattern with direct implications for latency, reliability, cost, and the ability to evolve systems safely over time. The key insights are:

1. JSON belongs at the boundary — where intent is fuzzy, human-facing, and needs to be readable and flexible.
2. Protobuf belongs in the execution layer — where performance, type safety, and schema evolution matter.
3. Intent discovery is the bridge — the LLM’s job is to transform unstructured human intent into a structured, typed task that agents can act on deterministically.
4. gRPC and Protobuf are natural partners for the multi-agent execution layer, providing streaming, backpressure, and code generation out of the box.
5. Neither format eliminates the other — the strongest production architectures use both deliberately, in the layers where each excels.

As agentic AI systems continue to scale in ambition and adoption, the engineers and architects who understand these tradeoffs will be better positioned to build systems that are not just functional, but genuinely production-grade.

References

Akka (2026) Agentic AI frameworks for enterprise scale: A 2026 guide. Available at: https://akka.io/blog/agentic-ai-frameworks (Accessed: 28 March 2026).

Auth0 (n.d.) Beating JSON performance with Protobuf. Available at: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Accessed: 28 March 2026).

TechTarget (n.d.) Understanding protocol buffers vs. JSON. Available at: https://www.techtarget.com/searchapparchitecture/tip/Understanding-protocol-buffers-vs-JSON (Accessed: 28 March 2026).