You are building a support-ticket triage service, and you have decided to ask TypeSafe's Jev the questions rather than write your own classifier. You also work in Protobuf, so you wonder whether the questions you put to a model can live in the same schema as everything else. You need a Go client for Jev, and there isn't one.
Buf ran into the same gap. It wanted a Go client for Jev and could not find one, so it wrote a code generator. In a post called Asking Jev questions with Protobuf, Kevin McDonald introduces protoc-gen-jev, a protoc plugin that, in his words, "defines Jev questions in Protobuf and generates typed clients and response types for Go, TypeScript, and Python."
Here is how it works. The request message carries the state. The response message carries the questions, written as field options. Jev has three primitives, and each maps onto an ordinary type. A choice becomes an enum. A score becomes an integer on a rubric. A noul, which is a yes-or-no probability, becomes a boolean once it clears a threshold that the schema sets. In Buf's example that threshold is 0.7.
Then you look at the numbers, and you should read them the way the post does, carefully. They come from Buf's own test run, against Cloudflare's Clef-omni on Workers AI. A checkout outage ticket came back technical, frustration 1, urgent, with an urgency probability of 0.92. An angry dark-mode complaint came back technical, frustration 3, not urgent, at 0.07.
Two tickets are a demonstration, not an evaluation, and you should not treat them as proof that the model will triage your queue well. What the pair does show is a design point. Frustration and urgency are separate questions, and the schema keeps them separate. The angry customer is not the urgent one. If you were about to fold both into a single priority field, that is worth noticing.
Before you depend on any of this, read what Buf says about status. "protoc-gen-jev is an experiment, not a supported Buf product." It runs locally only. There is no Buf Schema Registry remote plugin and no generated SDK yet. You would run buf generate with the Buf CLI yourself, and the plugin pulls its option definitions from the BSR as a dependency. Publishing it as a remote plugin on the registry is the step Buf says it has not taken. That step would turn an experiment into something the registry distributes like everything else it hosts.
That disclaimer is what makes the Buf provider page in the APIs.io catalog the right place to read the post. The catalog describes Buf's own public API as Protobuf rather than OpenAPI: 33 services and 85 RPCs at the root of buf.build, exposed to agents through a remote MCP server.
Now the turn, and it is about the company, not just the plugin. The catalog's Kin Score for Buf is 65.3, in the strong band. It is built on operational transparency at 92.1, developer ergonomics at 85.7, and access clarity at 85.5. Contract quality sits at 39.0 and contract governance at 18.2. Agent Readiness is 49.2, agent-ready, with the MCP server, agent skills, error semantics, idempotency, delegated identity, and dynamic client registration lit. The well-known catalog, OpenAPI examples, and dry-run mode are dark.
Put that next to the argument in the post. Buf's case is that a schema should carry the meaning of a call, all the way down to the question an AI model is asked. Yet it scores lowest on the facets that measure the schema itself. The catalog is candid about part of this: its rubric reads OpenAPI more easily than Protobuf, so some of the gap is the rubric's. The governance gap, though, is still worth closing on Buf's own terms.
What you take away is practical. If you want Jev questions typed in Protobuf, the idea is sound and the plugin is real, but it is a local experiment today, with no supported distribution. Treat two sample tickets as a demonstration. Keep your frustration and urgency fields apart. And when a vendor sells you on schemas, check its own schemas too.
Read the original: https://apis.io/2026/11/10/buf-generates-typed-jev-clients-from-protobuf-and-calls-it-an-experiment/