Will ChenDocuments that run AI proceduresI worked on a document editor that could execute AI instructions and show the results beside the steps that produced them.
Building Idyllic - Prior Iterations
March-May 2025
I wanted to write a research procedure in a document and run it from the same page. The document would contain the instructions and the material they operated on. After a run, I should be able to inspect the results beside the steps that produced them, change a step, and run the procedure again.
The appeal came from how much work already fit into a document. A page could hold background notes, references and a sequence of questions. But an ordinary page did not say which paragraphs were instructions, what information each instruction could use, or where a generated result belonged. Those details determined whether the page described a procedure or actually executed one.
The Idyllic 2.0 design below combined structured information with action controls and a chat composer. It shows the intended experience: work remains visible on the page while the person asks for an operation on it. This is a product mockup from the surviving design file. Its copy describes the ambition; the frame itself does not establish that the program ran.
Context at each step
In March, I separated the document editor from the representation the executor used. The editor gave people familiar blocks and headings. Underneath, the program formed a tree of operations, so a section could contain a sequence of steps and a step could refer to a tool or an object. The editor changed that structure instead of leaving the runtime to guess the meaning of arbitrary page layout.
The difficult part was deciding what each step knew. In a research procedure, a search needs the query entered earlier. An analysis step needs the search results. The next step should receive the results that belong to its part of the procedure, rather than an undifferentiated transcript of everything that has happened in the application.
I represented that available information as a context scope. When the executor entered a section or an event handler, it established the context for the work inside it. Executed steps contributed their requests and results to the context used by later steps. A phrase inside an instruction could also ask AI to fill in a value from the information available at that point.
The March visualization made those rules inspectable. Each row shows an operation, the context before it ran, its output and the context afterward. In the search example, the input step adds a query. The search step adds document results. A later operation receives both. These were development tests with example data. I still needed to inspect the actual messages sent to the model to verify that they followed the context rules.
The execution movie
That table helped me work on execution semantics, but it exposed too much machinery for someone using the document. A person waiting for a report needed to know which work had completed and what was happening now. They also needed a way to inspect details when a step produced something unexpected.
Julius designed a compact execution display that we called the “movie.” It presented the run as changing rows with status indicators and expandable content. The expandable areas mattered because a search result and a generated document do not need the same fixed layout. Each operation could show its own useful detail while the surrounding display retained a consistent structure.
I connected a rough implementation of his design to a demo executor on April 10. That distinction mattered during development. The interface let us try the pacing and inspect how operations appeared before the new execution specification was complete. We could discuss a running presentation of the work while I continued implementing the rules underneath it.
The generated document
Creating the final document introduced another dependency. A chat response could say that it had run the prompts, but an artifact card needed an actual document to open. Citations also needed to point into that document. On April 20, I changed executeDocument so it created a new document, applied Julius's improved artifact design and connected citations to the generated result.
I also chose sequential execution for the document prompts. Earlier outputs could then contribute to later work, which made the order of the document meaningful. The exact rules for how prompts used headings and surrounding context were still being refined. At that point, the chat itself remained local and its persistence still needed work, so creating an artifact did not yet establish the complete storage model for every conversation.
By May, I was refining how references appeared as inline pills. An object or document could sit inside an instruction as something the user could recognize, while the executor retained a reference it could operate on. The visible page, the program structure and the generated artifact each had a distinct job. The next implementation problem was keeping those representations consistent as people and agents edited them.