TOON: A New Format for Professional Prompt Notation (And Why It’s Not Just “Another JSON”)
Why even bother with a new format
In LLM and especially in multi-agent systems, prompts often shift from being “text instructions” to contracts: structured input, output, context, rules, roles, data tables, and intermediate results. This works well in JSON—but you’ll quickly run into two practical drawbacks:
-
Token-based analysis: quotation marks, parentheses, commas, and repeated keys account for a surprisingly large portion of the context.
-
Readability and maintenance: A more complex prompt-config in JSON is harder to debug manually, and changes to the structure are prone to syntax errors.
TOON (Token-Oriented Object Notation) was created as a format that preserves the structure of JSON but represents it in a way that is more readable for both humans and large language models—and, most importantly, more token-efficient.
What is TOON and how does it work
TOON is a lossless format for structured data that is compatible with JSON: whatever JSON can express, TOON can express as well. The difference lies in the syntax:
-
Hierarchy is expressed using indentation (similar to YAML) rather than "bracket" syntax.
-
An array is denoted as
name[N], whereNis the length of the array. -
TOON can write homogeneous arrays of objects in a tabular format: the keys are listed once in the header, followed by rows of values (like CSV).
Mini demo (object + nesting)
user:
id: 1
name: Alice
profile:
city: Prague
Example (homogeneous array of objects – "table")
users[2]{id,name,role}:
1,Alice,admin
2,Bob,user
In JSON, the id/name/role fields would be repeated for each record. In TOON, they appear only once.
Why is this interesting for prompts and multi-agent systems
In a multi-agent run, the following are typically transmitted and stored:
-
context and rules,
-
task backlog / plan,
-
databases (records, events, customers, documents),
-
intermediate results (extraction, classification, recommendations, scores),
-
Decision and audit trail.
TOON is particularly useful in situations where:
-
you have a larger volume of structured data in the prompt,
-
the data is repetitive/tabular (logs, records, catalogs, lists),
-
you need to preserve the context while maintaining the structure,
-
You want the agents to "speak" in a clear, structured manner, not just in free-form text.
Practical implications:
-
fewer tokens → lower price and more room for context,
-
a clearer "contract" between agents → fewer misunderstandings,
-
easier manual review and fine-tuning of prompts.
TOON vs. JSON: A Quick Comparison
Readability for humans
-
JSON: reliable but verbose (parentheses, quotation marks, commas); it’s harder to read when dealing with larger objects.
-
TOON: A clearer structure thanks to indentation and tabular formatting.
Token efficiency
-
JSON: often has high overhead due to key repetition and syntax.
-
TOON: Significantly more efficient, especially for homogeneous object fields (table mode).
Ruggedness and tooling
-
JSON: the standard—parsing, validation, schemas, and linting everywhere.
-
TOON: a newer ecosystem with fewer enterprise-level tools and conventions.
Suitability for multi-agent orchestration
-
JSON: ideal for API contracts, machine processing, and a schema-first approach.
-
TOON: Ideal for "LLM-friendly" transmission and storage of structured states and tables in a prompt.
Disadvantages and Risks of TOON (Important for Clinical Practice)
TOON is practical, but it’s only fair to mention its weaknesses:
-
Less advantageous for heterogeneous or deeply nested structures
If the data is not tabular and each item has different keys, TOON often cannot use a tabular representation, and the advantage is reduced. -
A young standard and limited support in tools
In an enterprise environment, JSON is the "default": governance, schemas, validation, integration. For TOON, this currently means custom libraries and processes. -
The Importance of Discipline in Teams
If TOON is entered manually, it is important to ensure consistency (indentation, the order of fields in the table, and the quoting of values containing special characters). -
The models are not "natively TOON-trained"
It is usually necessary to provide the agents with a clear example of the format, or a brief instruction such as "return the output in TOON".
Recommendations for professional use
I would view TOON as an optimization layer for LLMs, not as a replacement for JSON everywhere.
It makes sense when:
-
you're sending larger amounts of tabular data to the command prompt,
-
The state of a multi-agent run is extensive (schedules, logs, records),
-
You're dealing with costs and context limits,
-
You want readable "agent-to-agent" message payloads.
JSON makes sense when:
-
you're in the world of API integration and schemas,
-
you need mature validation and governance tools,
-
The data is not tabular, and the TOON savings are minimal.
TOON is an interesting candidate for a "prompt serialization format" in professional settings: lower tokenization overhead and better readability when prompts contain structured data and multi-agent state. In enterprise practice, however, it’s important to recognize that JSON still holds the greatest advantage in terms of ecosystem, standardization, and tooling.
If you’d like, I can add a short “multiagent message envelope” template in TOON (role, destination, inputs, outputs, rules, audit) and the same template in JSON alongside it.