The Data Consumption Gradient: How Changing Document Formats Can Improve LLM Agent Performance

[#1]

Disclaimer: This is a practitioner's observation, not a scientific study. No chunking, vector databases, or technical optimisation was applied. Just an end user noticing a pattern.

The Data Consumption Gradient: Changing Document Formats Can Improve LLM Agent Performance

Have you ever noticed that when working with an AI/LLM tool not all documents are processed at the same speed? For example, you set up an agent that references certain documents for context. When running prompts or queries that require the agent to parse the documents, there can sometimes be noticeable discrepancies in the results. Your gut instinct tells you that it is not the tool itself, but rather the time it takes to process the documents provided.

Well, when processing documents, I have noticed that AI/LLM-powered tools have difficulties, or take noticeably longer, processing scanned PDFs and PowerPoint slides compared to plain text files. To make sense of this, I developed a non-scientific mental model that I find to be useful: a car driving up a hill.

The Car on a Hill

Imagine a car moving along a road. As it approaches a hill and the gradient increases, the driver needs to make adjustments such as shifting to a lower gear and pushing down the accelerator harder, using more fuel just to maintain the same speed. At some point, depending on the engine size and capacity, the car begins to slow down. Even more fuel is consumed. Push it far enough and the car could stall. There's a trade-off between speed, fuel consumption, distance covered, and the gear being used.

I am applying this mental model to how LLM-powered tools process documents, specifically from the user's perspective: what happens after you click the upload button and attach a file.

The Problem with Dense Documents

The solution is simpler than you might expect. For instance, if you have a scanned PDF that is highly dense, with lots of content and complex formatting, one alternative is to convert it before use. This is especially worth thinking about when the document is going to be used as a reference document for a tool that will be called on time and time again and any graphics in the document are not material to the context being provided. For example, an agent that advises on a specific topic, ranging from descriptions of rose varieties to regulations in a specific field.

Instead of feeding the agent those heavy source documents in their original formats, first convert them to a text-based format. This reduces the need for time spent pre-processing the documents and parsing the content. The format I recommend is Markdown.

Why Markdown?

Markdown is perfect for documents that are already structured with headings, sections, and lists. It is a presentation shorthand of documents making it far lighter. Like HTML, it uses simple symbols to mark headings, lists, and emphasis, but without tags. You can drop a Markdown document into different tools, templates, and contexts, and it will respect the hierarchy: H1, H2, font usage, italics, and so on.

Crucially, a Markdown file is also markedly smaller in size. You can take a PDF that is multiple megabytes and bring it down to a few hundred kilobytes — with the same textual content. For text-based documents the context is not lost. That's the key point.

This improves the efficiency of the AI tool or agent you are using, and you use fewer resources. Remember the car going up the hill? The greater the gradient, the more fuel consumed, the lower the gear, the less efficient it is per kilometre travelled. Use Markdown documents, and you are on a much flatter road — more efficient, better results, and contextually you will actually see an improvement in output quality.

The Resource Budget Problem

Here is why this matters practically. Developers and tool creators often set a processing limit — for example, let us say a document may be processed for a maximum of 15 seconds, and beyond that point, processing stops or times out. You get whatever context was covered within the set time period.

Think of it as having a 5-litre fuel tank and a fixed distance to travel. The person on a flat road covers the full distance. The vehicle travelling on a 30° gradient burns through that same 5 litres before reaching the destination. The resource limit is the same; the ground covered is not.

You do not consume resources indefinitely just to process documents. There is always some limit. And the amount of context you extract from a file depends entirely on how efficiently the tool can read it. Using Markdown or plain text formats means you are on the flat path: much more efficient, less pre-processing, more context extracted, fewer resources (including time) used overall.

The Data Consumption Gradient

When this idea struck me, I did some research to see if there was an existing term for it. ‘Parseability’ is the closest one that I came across but it does not seem to quite fit. The data consumption gradient is what I am calling it.

The greater the gradient, i.e. the heavier and more complex your source document, the higher your resource cost. And this raises an interesting follow-up question: what pushes the gradient to the negative? What document characteristics or tool configurations could take you from flat ground to actually going downhill, that is, using less energy than baseline without changing anything about your system? Converting to a simpler document format as discussed here is part of the answer. It is a question I am continuing to think about.

Either way, some key things to do are:

1. Set your baseline: get a good feel for the performance of your agent or tool when running on a flat surface.

2. Take measurements: record the time processing time for various prompts/requests/queries. Assess the quality of the responses (arguably subjective, keeping in mind the probabilistic nature of AI), and

3. Tweak the source format.

Try It Yourself

I have been testing this with various tools, including Rovo, and the difference is real. If you are setting up an agent with multiple source documents:

• Convert all sources to Markdown

• Run before-and-after contextual tests with the same queries

• Compare the completeness and accuracy of the responses

Is this the most efficient way of doing it? I do not know. Does it work? Yes it does.

See for yourself. The difference may surprise you.

Thanks for reading.

[Nabeel awan]

The Markdown comparison is particularly interesting because it highlights something that is easy to overlook: document format can affect the quality of an agent's input before the LLM even gets to the actual reasoning stage.

The “car on a hill” analogy also makes the concept easy to understand. A complex scanned PDF may contain the same information as a Markdown file, but extracting that information can involve additional processing for OCR, layout, tables, images, and other document elements.

One thing I would be interested in testing is whether the improvement comes primarily from reduced file size or from the simpler document structure. Those aren't necessarily the same thing. A small PDF with complicated layouts could potentially be harder to process than a larger plain-text document.

It would also be useful to compare Markdown with other structured formats such as HTML or clean TXT files while keeping the actual textual content identical. That could help isolate whether Markdown itself provides an advantage or whether the main benefit comes from removing unnecessary presentation and layout information.

The before-and-after testing approach seems like the most practical takeaway. Rather than assuming a format will perform better, teams can measure processing time, retrieval completeness, and answer accuracy using the same questions against equivalent source material.

The idea of a “data consumption gradient” is an interesting mental model, particularly for agents that repeatedly work with a relatively stable knowledge base.

[farhan faisal]

This is an interesting perspective on how document formats can impact LLM performance. The comparison of AI processing to a car climbing a hill is a simple way to explain how complexity increases resource usage. Converting heavy documents into cleaner formats like Markdown can definitely help improve readability, reduce unnecessary processing overhead, and provide more focused context for AI agents.

As AI adoption grows, optimizing the way we prepare and structure information will become just as important as the models themselves.

[Michael_C_Weihrauch]

This article touched home in many ways. Your "car driving up a hill" analogy is relatable and spot-on. Now, add a dirty windscreen to the picture. My experience with what I would consider a simple PDF of a form that is two or three pages long with no images can still make the drive difficult. I am a non-programmer, and initially could not understand why the LLM could not reliably extract the data from what appears to my eyes as obvious. What I learned is that in addition to OCR, "flatten" the PDF, losing context in the process. One would expect that a form with two date fields, for example, would be interpreted:
Start date:
23.8.2026
Due date:
5.11.2026

But in reality, when flattened, may be seen as:
Start date:
Due date:
23.8.2026
5.11.2026

The context is lost and a query for the due date often results in the first date the LLM comes across, which in this case would be incorrect. We need tools that understand and retain context, else the destination will remain a distant blur. In the end,t he LLM might have the engine power to process the text, but without context it cannot clearly see the "lines on the road" that connect different data points together.