Зміст
Коротко
LLM приймають величезні вікна контексту, а інфраструктура агентів досі ганяє JSON — формат для веб-API, а не для довгих трас «планувальник → виконавець → пам'ять». На Dev.to — вузькі місця та формат ULMEN для agent-стеку.
Що сталося
Типовий agent-пайплайн: planner ставить задачі, executor викликає tools, пам'ять копить історію кроків. Між процесами, у БД і в промптах усе серіалізується в JSON — знайомо інженерам, але дорого на масштабі.
На великих обсягах проявляються системні проблеми. Зайві цикли серіалізації та десеріалізації. Роздування payload: ключі в лапках, повторювані структури. Семантичні збої: модель «трохи не так» закрила дужку — весь tool call марний. Зростають рахунки за bandwidth, storage і токени.
Protocol Buffers і Apache Arrow вирішують інші задачі, але не під бюджет контексту LLM.
Автор пропонує ULMEN з шарами LUMB, ULMEN Text, ULMEN LLM, ULMEN AGENT. У заявлених бенчмарках ULMEN LLM дає близько −44% токенів відносно JSON; бінарний варіант — порядку 22% розміру JSON-payload.
Чому це важливо
При десятках worker-агентів JSON стає податком на кожен крок. Економія сорок відсотків токенів — це місяці інференсу на тому самому бюджеті.
Формат даних — частина архітектури агента, нарівні з вибором БД або черги. Ігнорувати його — оптимізувати модель, поки pipeline з'їдає контекст лапками та ключами.
На практиці
- Порахуйте токени на JSON-обгортки tool results vs корисний вміст.
- Бінарні або columnar формати між сервісами; JSON — для людей і відладки.
- Перевіряйте tool output схемою до контексту моделі.
- Summary історії замість повного логу кожен turn.
- Порівняйте ULMEN на своїх трассах, не на демо автора.
Підсумок
JSON зручний для REST, але для agent-інфраструктури 2026 року часто дорогий і крихкий. Деталі — на Dev.to.