Fluent, Confident, and Wrong: Grounding Agents in Real proto3

Ask a capable model to write the .proto for your order service and you will get a file that compiles. Idiomatic names, an enum with a zero-valued UNSPECIFIED member because that is the convention, a google.protobuf.Timestamp for the placed-at field, numbers counting up from one. It will look like something a good engineer wrote on a good day.

That is the problem. In proto3, the facts that matter most are invisible in a file that looks right.

A language model has read an enormous number of .proto files, which makes it fluent in the shape of the format. Fluency is not knowledge of your contract, and proto3 punishes the difference immediately: a field number is not a stylistic choice, it is the identity of a field on the wire, and an invented one is a compatibility incident waiting for a deploy.

Three things training data cannot supply

Which numbers are already spoken for. Not just the ones currently in the file — the ones retired years ago and fenced with reserved. An agent that renumbers, or fills a gap left deliberately, produces a diff that reviews cleanly and breaks older clients.

Which fields track presence. Proto3 gives a plain scalar implicit presence — it always carries a value. An explicit optional label and a message-typed field track presence and may genuinely be unset. Those are different claims about the same-looking line of text, and consumers act on them differently.

What your enum actually says. Which symbols exist, which numbers they carry, whether the numbering has holes where values were removed. A guessed enum surfaces months later as a row that fails a filter nobody thought to check.

None of these can be recalled. All of them can be consulted.

Consultation instead of recall

CoreModels exposes its transform engine to agents over the Model Context Protocol. An agent connects to the MCP endpoint — https://coremodels.example.com/mcp in the pattern your deployment follows — completes OAuth, and gets tools rather than vibes.

The one that matters here is transform_schema. It takes a project id, a source format, the schema text, and a target format, with proto3 available on both sides under the key protobuf (alias proto). Alongside it sit read-only tools for consulting the governed model — listing projects, summarizing types, elements and taxonomies, searching nodes — so an agent can ask what exists before proposing anything new. Every tool carries an explicit read-only hint, and tools that reach outside the system are annotated as open-world, so an agent or its supervisor can tell which calls observe and which act.

Structure beats plausible text

Run the task through the tool and the epistemics invert. The agent is no longer pattern-matching on characters; it is reading a decoded model in which the ambiguous things have been resolved and stated.

Messages arrive as types, with nested messages as child types that remember which message enclosed them. Fields arrive as elements whose presence is explicit — plain scalars required because proto3 gives them implicit presence, explicitly optional and message-typed fields not. Enums arrive as taxonomies whose terms keep their numeric values. The wire facts an agent would otherwise invent are first-class annotations: field numbers, the verbatim scalar token (uint64 is uint64, not "a number"), field options, reserved statements, the package, the import clauses, the oneof group each member belonged to, and a map's key and value types.

The agent stops needing to be right about proto3 trivia and starts being able to look it up — a much better failure mode.

The ledger is machine-readable honesty

Ungrounded agents are most dangerous at the edges, where they are least likely to hedge. What does map<string, string> become in a warehouse table? What happens to a bytes field? An agent working from training data picks something and asserts it.

An agent working through this surface gets an answer and a confession. Every response carries a lossiness ledger: each entry a kind, a path, and a plain-English explanation of what could not be carried exactly. A map approximated as a string with its key and value types preserved. A oneof flattened, its exclusivity recorded as a narrowing. A bytes field noted as a type approximation. A service block recorded as a structural drop.

That changes what the agent can responsibly say. Not "done," but: here is the schema, and here are the four things the target could not hold, each with its path. A ledger is the difference between an assistant that reports and one that reassures.

Determinism is what makes agent output reviewable

The encoder emits byte-identical text for the same model, and a decode-encode cycle is a fixed point. Preserved field numbers re-emit verbatim; a new element is minted the next free number, skipping numbers in use and the 19000–19999 range the specification reserves for the implementation. So when an agent adds one field and regenerates, the human reviews a one-field diff — no reordering, no renumbering, no churn. Reproducibility is the precondition for checking the work at all.

Proposals are gated, never trusted

Agents do not only read schemas; they propose mappings between them. The design here is deliberately unsentimental.

A plan from the AI mapping mode passes the same universal validation gate as a hand-authored mapping guide or an inferred match. There is no shortcut for the machine: at most one repair attempt, and a rejected repair is a rejection. Plan operations may carry a self-reported confidence score, and the gate does not read it as evidence. Because that mode spends the server's model budget and sends schema content to an external model provider server-side, it requires Editor or Admin membership rather than ordinary read access, and the tool's own description says so — an agent can surface the boundary rather than cross it quietly.

What comes back is a schema, the executed plan as a replayable artifact, and the ledger — the agent's contribution as an inspectable object in a governed workflow, not an unaccountable edit.

The point

Agents are not bad at Protocol Buffers. They are dangerously good at producing files that look like Protocol Buffers — in a format where looking right and being right diverge on exactly the facts that cost the most to get wrong. Grounding inverts that. Give an agent the real contract, the real numbers, the real presence rules, and a ledger that makes its limits legible, and it stops imitating your schema and starts operating on it.

To connect one, see the MCP quickstart in the CoreModels docs and add your /mcp endpoint as a connector.