Contents
In brief
LLMs accept huge context windows, yet agent stacks still shuffle JSON — built for web APIs, not long planner → executor → memory traces. Dev.to covers the pain points and ULMEN as an agent-oriented encoding.
What happened
Typical flow: planner tasks, executor tool calls, growing memory — all JSON between processes, databases, and prompts.
At scale:
- Extra serialize/deserialize on every hop.
- Bloated payloads: quoted keys, repetition, no sharing.
- Semantic fragility — one bad bracket ruins a tool call.
- Higher bandwidth, storage, and token bills.
Protocol Buffers and Apache Arrow solve other problems; they are not tuned for LLM context budgets and agent-specific semantics.
ULMEN (Ultra Lightweight Minimal Encoding Notation) splits into LUMB, ULMEN Text, ULMEN LLM, ULMEN AGENT — binary exchange, human text, compact model-facing views.
Author-reported benchmarks: ULMEN LLM ~44% fewer tokens vs JSON; binary ~22% of JSON payload size.
Why it matters
With many workers and long tool traces, JSON is a per-step tax. Saving ~40% on intermediate representations is inference budget, not micro-optimization.
Even if ULMEN never becomes a standard, the lesson stands: data format is agent architecture, like picking a DB or queue.
In practice
- Measure tokens spent on JSON wrappers vs useful tool content.
- Use binary/columnar formats machine-to-machine; keep JSON at human/debug boundaries.
- Schema-validate tool output before it enters the model context.
- Summarize history instead of replaying full logs each turn.
- Evaluate ULMEN or peers on your traces, not demo numbers alone.
Takeaway
JSON is great for REST; for 2026 agent infra it is often expensive and brittle. Read the Dev.to post for ULMEN details and benchmarks.