Prompt Optimization for AI Builder: Lessons from TOON vs Text

Intro:
With so many posts and discussions around the TOON format, I wanted to experience firsthand how efficient it really is for prompt design. So, this weekend, I spent a couple of hours putting theory into practice.
The idea was simple: use an LLM to extract custom entity information from invoices—one using traditional natural language instructions and the other using a structured TOON format.
Structuring the instruction in TOON took a bit of trial and error, but I managed to generalize it and share the template. After running a batch test of 20 invoices and analyzing the results, I was convinced: TOON-based instructions are not only effective but also less compute-intensive.
Let’s dive into the details.

Setup:
To test the efficiency of TOON-based instructions, I created two versions of the same prompt:

Version 1: Traditional natural language instruction, written in a descriptive, narrative style.

You are a sustainability expert specializing in utility invoice analysis and data normalization. Your mission is to extract and standardize key information from provider invoices to support environmental reporting, carbon accounting, and analytics.

Input :   Invoice 

Fields to Extract:
{
  "Bill ID": "...", // Invoice or bill number
  "Bill Date ": "...", // Invoice or Bill date
  "Account Id ": "...", // Account Number or Customer reference number
  "Invoice Amount": "...", // Total Amount 
  "provider_name": "...",
  "service_type": "...",  // electricity, water, gas, fuel, waste
  "meter_id": "...",      // Unique meter identifier
  "PDL": "...",           // Point of Delivery (may be labeled as meter number)
  "PDL_Address": "...",   // Full address; validate/enrich using location JSON
  "PDL_CITY": "...",      // City; infer from location JSON if missing
  "amount_consumed": "...", // Normalize to kWh if applicable
  "unit": "...",          // Original unit found in invoice
  "start_of_period": "...", // If date missing, infer month and return 1st day
  "end_of_period": "..."    // If date missing, infer month and return last day
}

Fuel Mix Table:
If the invoice includes a fuel mix breakdown, extract it as a separate array:
"fuel_mix": [
  {
    "source": "Coal",
    "percentage": 2
  },
  {
    "source": "Natural Gas",
    "percentage": 20
  },
  {
    "source": "Nuclear",
    "percentage": 28
  },
  {
    "source": "Renewables",
    "percentage": 48
  },
  {
    "source": "Other Fuels",
    "percentage": 2
  },
  {
    "CO2_emissions_g_per_kWh": 116,
    "radioactive_waste_g_per_kWh": 0.0019
  }
]

Normalization & Fallback Rules
1) Use the location JSON file to:
Match postcodes/ZIP codes to known addresses
Suggest a recommended address if invoice data is incomplete
2) Normalize amount_consumed to kWh:
Gas: 1 m³ ≈ 11.1 kWh
Fuel: Use standard energy density values
Water and waste: Leave in original units
3) For any missing or unidentifiable data, return "N/A"

Version 2: TOON format, a structured schema-like representation with clear sections for persona, fields, rules, and inputs.

Persona[Role,Specialization,Mission,Input]
Sustainability expert,Utility invoice analysis & data normalization,Extract and standardize key information for environmental reporting,InvoiceBody

FieldsToExtract[Field,Description,Notes]
Bill ID,Invoice or bill number,
Bill Date,Invoice or Bill date,
Account Id,Account Number or Customer reference number,
Invoice Amount,Total Amount,
provider_name,Provider name,
service_type,Type of service,electricity, water, gas, fuel, waste
meter_id,Unique meter identifier,
PDL,Point of Delivery,may be labeled as meter number
PDL_Address,Full address,validate/enrich using location JSON
PDL_CITY,City,infer from location JSON if missing
amount_consumed,Amount consumed,normalize to kWh if applicable
unit,Original unit found in invoice,
start_of_period,Start of consumption period,if date missing, infer month and return 1st day
end_of_period,End of consumption period,if date missing, infer month and return last day

FuelMixTable[source,percentage,CO2_emissions_g_per_kWh,radioactive_waste_g_per_kWh]
Coal,2,,
Natural Gas,20,,
Nuclear,28,,
Renewables,48,,
Other Fuels,2,,
,,116,0.0019

NormalizationAndFallbackRules[Rule,Details]
1,Use the location JSON to match postcodes/ZIP codes to known addresses; suggest recommended address if invoice data incomplete
2,Normalize amount_consumed to kWh: Gas 1 m³ ≈ 11.1 kWh; Fuel: use standard energy density values; Water/waste: leave in original units
3,For missing/unidentifiable data, return "N/A"

Input[Parameter,Type,Description]
InvoiceBody,string,Raw invoice content (PDF or text)
LocationJSON,json,Reference for address/postcode normalization

After a few trial and error i found this format working well for me

Next, I built a Power Automate flow with two parallel AI Builder prompt actions. Each action received the same invoice input but used a different instruction format. The outputs were then compared for data extraction accuracy, token usage, and runtime performance.

Comparision of characteristics:

Dimension	Text-Based Instruction	TOON-Based Instruction
Readability (Human)	Highly readable and natural; easy for SMEs to understand	More technical and structured; less intuitive for non-technical users
Structure & Formality	Narrative style; relationships implied through context	Explicit schema-like structure; relationships clearly defined
Ambiguity	Higher risk of ambiguity; relies on LLM inference	Low ambiguity; fields, rules, and tables are explicitly defined
Ease of Extension	Adding new fields or rules requires rewriting paragraphs	Easy to extend by adding rows or columns in structured blocks
LLM Parsing Efficiency	Requires semantic interpretation; may vary by model	Easier for models to parse; mimics JSON/tabular formats
Token Efficiency	Can be verbose; more tokens consumed	Compact representation; fewer tokens for same complexity
Error Handling	Fallback rules embedded in text; harder to enforce consistently	Rules are explicit and structured; easier for consistent application
Scalability	Becomes cumbersome as complexity grows	Scales well for large schemas and multiple rule sets
Human-Centered Design	Best for conversational or SME-driven workflows	Best for automation pipelines and programmatic generation

Summary of Test Runs:

TOON format		TEXT format		Savings
Tokkens	Run time	Tokkens	Run time	Tokkens	Run time
3522	3	4019	5	12%	40%
5196	3	5625	5	8%	40%
5196	3	5751	6	10%	50%
5186	3	5631	5	8%	40%
5197	3	5700	5	9%	40%
4824	3	6192	6	22%	50%
4625	3	6321	6	27%	50%
4995	3	5817	5	14%	40%
4434	3	5290	5	16%	40%
5015	3	6275	6	20%	50%

Token Savings: TOON format consistently uses fewer tokens than Text format.

• Range: 8% to 27%, average ≈ 15%.
• Runtime Savings: TOON format is significantly faster.
• Range: 40% to 50%, average ≈ 45%.
• Consistency: TOON runs in 3 seconds every time, while Text runs in 5–6 seconds.

Insights:
Prompt design isn’t just about clarity—it impacts performance and cost.
If you’re building AI Builder flows for large-scale document processing, consider adopting TOON-style structured prompts.

• TOON format is more efficient both in terms of cost (tokens) and performance (runtime).
• The structured nature of TOON likely reduces LLM cognitive load, leading to faster inference.
• For large-scale invoice processing, this efficiency translates into:
• Lower API costs (due to fewer tokens).
• Higher throughput (due to shorter runtime).

LLM Token estimator