Will ChenInteractive results for AI appsTask Bear and Search Agent made checklists, progress and citations part of the interface, with Julius’s designs connected to working agent flows.
Building Idyllic - Prior Iterations
August to October 2024
A generated checklist should let you check things off. It sounds obvious, but it changes what an AI application has to keep track of. The model can produce the words in a task list. The application has to preserve which tasks you completed, display nested items and let you return to the same list later.
By late summer 2024, I was separating two ways of interacting with Idyllic. You could have an open-ended conversation, or you could use an application with an interface fitted to a particular task. Both could use AI. I wanted the application to have controls and output types that made sense for the work being done.
A feed for interactive results
Task Bear was one of the designs we used to work through this. Its output was a checklist, and its screen combined several kinds of information: what the agent was doing, what it had produced, and the controls available to the person using it. A September 1 annotation divides those areas explicitly.
The feed contained agent activity and interactive results. A row could report that the agent was processing something, while a card could contain a result with its own interactions. Controls at the bottom could open a sheet for input. This gave us a common layout without requiring every application to ask for the same information or display the same kind of answer.
At this stage, I had made screens manually. Dynamically loading different app definitions into a shared layout was still work to do. The design helped specify what that shared layout needed to support: a feed, app state, settings and controls that could summon more detailed interfaces.
State belonged to the output
The checklist made the state question precise. If someone generated one list, used it, then generated another, the first list still needed to remember its completed items. In the September 19 specification, I put checklist state on the individual output item. You would scroll back to that particular result to continue checking it off.
That decision affected both the interface and the implementation. A checkbox could no longer be treated as temporary decoration around model output. It belonged to that particular output. The same specification described input controls that would disappear while an input step was active, then return when the person completed or canceled it. Each stage had to define what the person could do and where their changes were stored.
Julius and I were also using Storybook as a shared place to work on components. A component could be developed with sample data before it was connected to the running agent. That made it possible to discuss a particular checklist or input control while the execution code was changing underneath it.
Showing a search in progress
Search Agent brought a different set of requirements into the same interface. The idea was to ask questions of personal material and see an answer grounded in relevant sources. A single block of generated text would hide most of that work. The interface needed to show searches in progress, which material had been found, and how that material related to the answer.
On October 7, Julius gave me a design that separated those parts. Search themes appeared near the top. Dated source chips made the retrieved material visible. A later section presented the answer with citation markers. The text in this design is placeholder content; it shows the intended arrangement rather than an actual search result.
I connected the design to a LangGraph search flow, using Convex to carry updates back to the interface. Vector search became a tool the agent could call, and the agent reported its progress as it worked. By October 8, I had citations working. Streaming and the display of subsearch queries remained active implementation tasks.
The Search Agent card needed to communicate an unfolding operation, while a checklist needed to preserve an editable result. Supporting both gave the feed a more specific purpose. It could hold activity that was still changing alongside outputs that people would continue to use after generation had finished. That distinction would become especially useful for an application whose main interaction was a sequence of questions, with a document waiting at the end.