<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2602.05447/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2602.05447/feed.xml" rel="self" type="application/rss+xml" /><item><title>Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale — mentioned by KingMob</title><link>https://news.ycombinator.com/item?id=46999484</link><guid isPermaLink="false">urn:hackerpapers:mention:2602.05447:46999484</guid><pubDate>Fri, 13 Feb 2026 06:13:58 GMT</pubDate><description>&lt;p&gt;Intriguing, but I wonder if they&amp;#x27;ve looked at whole-conversation token usage, though, and not just short tasks. I just saw a [paper](https://arxiv.org/pdf/2602.05447) that investigated similar aspects of TOON (which aims to reduce JSON tokens), and they found that even though TOON itself reduced the number of tokens, LLMs were less familiar with it, and thus spent even more tokens trying to decipher it, or making mistakes (see section 4.5, figures 6 and 7). From the paper: &amp;gt;Unlike Markdown, where each grep hit simply returned more text, TOON&amp;#x27;s overhead was driven by a combination of output…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2602.05447/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CL</category></item></channel></rss>
