Sandcastle, Flue, and applied agents
A day of comparing agent tools, testing orchestration ideas in iTOP, and turning that work into content and product direction.
The day revolved around a practical question: where do tools like Sandcastle and Flue actually help in real projects? I compared both with less focus on hype and more focus on function. Sandcastle looked useful for isolated development environments and loops. Flue looked useful for explicit agent workflows.
In iTOP, that became applied experimentation. I outlined a flow for creating events from free text, with structured JSON output, questions for missing fields, and one important rule: the agent must not invent date, time, or location. Another thread shaped a development loop with analysis, implementation, review, tests, and QA.
Content for the site
On the site, this study became the Sandcastle versus Flue comparison post. The conclusion was simple: they are tools with different purposes. One conversation is about sandboxing. The other is about workflow. That distinction matters because it keeps a new tool from becoming a generic answer to every problem.
There was also an idea for a public agent on the site: a question interface over the public corpus, using posts, sanitized journal entries, and llms-full.txt, without touching private memories or local sessions. The product line became clear: if the site talks about AI work, it can also expose a limited and safe way to query that material.
Product and performance
In iTOP, the work continued with mobile performance, asset weight, and small trust signals like the favicon. In parallel, the controllership project got a more concrete discussion about asynchronous OCR: upload, extraction, agent validation, database persistence, and frontend updates after the job finishes.
It was a day of separating tools from applications. The new tool only became interesting when it met a concrete workflow to improve.