<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Engineering on blog.yfzhou</title><link>https://blog.yfzhou.fyi/tags/engineering/</link><description>Recent content in Engineering on blog.yfzhou</description><generator>Hugo -- 0.140.2</generator><language>en-us</language><lastBuildDate>Mon, 18 May 2026 11:00:00 +0800</lastBuildDate><atom:link href="https://blog.yfzhou.fyi/tags/engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>What we learned building sandbox for document agent</title><link>https://blog.yfzhou.fyi/posts/doc-sandbox/</link><pubDate>Mon, 18 May 2026 11:00:00 +0800</pubDate><guid>https://blog.yfzhou.fyi/posts/doc-sandbox/</guid><description>&lt;p>&lt;em>Cross-posted from the &lt;a href="https://raycaster.ai/blog/sandbox-for-document-agent">Raycaster blog&lt;/a>; I&amp;rsquo;ve spent the last several months building this, and here is my take.&lt;/em>&lt;/p>
&lt;p>2025 brought us the new idiom for building AI (beginning with Manus and Claude Code): give it tools to operate a computer. This is a break from the past default approach represented by ChatGPT, which is LLM + a menu of bespoke API connections to plug in to various systems of record.&lt;/p>
&lt;p>Our first attempt at a document agent was to ingest documents, parse them into plaintext pages, expose search/read/write tools, and let the LLM operate over virtual directories of artifacts and pages backed by a SQL database.&lt;/p></description></item></channel></rss>