Will ChenControls for agent workflowsWe designed the builder, execution controls and mobile responses around the different jobs of creating an agent and using one.
Building Idyllic - Prior Iterations
June-August 2025
By the summer of 2025, an Idyllic agent had a prompt, custom procedures and events that could start its work. I wanted someone to build one by describing what it should do, inspect the resulting procedure and then use it without returning to the builder for every interaction.
That created two different interface problems. The person building an agent needed to see its instructions and test individual operations. The person using it needed an answer, a useful control or a request for missing information. A chat box beside a program editor could support both, but the application had to make clear which conversation was changing the agent and which was asking the agent to do its job.
Building and deploying the procedure
In June, I worked on the builder's ability to create and edit documents. I added conversion between an XML representation and the document editor, then tests and evaluations for document generation. The model could produce a structured document that a deterministic parser converted into editor blocks. Giving the builder a defined format made its work easier to test than a growing collection of unrelated editing commands.
The procedures themselves still needed to be readable. An event-driven agent could start from a message instead of a person pressing Run. In the July Telegram prototype, a Message Received block contained an instruction to reply using the Send Message tool. The event and the available action appeared directly in the document.
Running in response to events made saving more consequential. I did not want an unfinished prompt edit to silently become the version an active agent executed. I designed a separation between the current draft and deployment snapshots. The editor could autosave the draft, while execution would use the latest deployment. The July design also kept local undo history and accounted for the same draft being open in several tabs.
Function blocks and their controls
Julius and I worked through the function-block interface in Figma. A function definition describes a reusable procedure; a function call runs that procedure at a particular point. Those concepts needed different visual treatment. Using the same lightning-bolt metaphor for both made it harder to tell whether a block was defining something or doing something.
We also examined where inputs belonged. A search operation needs a query. A campaign operation may need several parameters. If every parameter stayed open, a short procedure became a long form. Hiding them all behind settings made a newly inserted operation harder to complete. We considered showing fields while the person created or edited a block, with a compact form available afterward.
The surviving Builder Era design places the procedure next to a preview pane. It gives individual steps room for their parameters and gives execution state a visible place beside them. This is a design frame with placeholder content, including proposed error and active states. The exact revision date of the frame is unverified, but the July design session records the corresponding work on function calls, parameter fields and execution indicators.
The controls also had to explain what they affected. A Play button at the agent level could mean running the entire agent, while a Play button inside a procedure could mean testing that procedure. Multiple Save buttons raised a similar question: did one save the parameters, the block contents or the whole agent? We discussed these choices through the actual layouts because the meaning depended on where the control sat relative to the thing it changed.
During July, I implemented streaming output inside executed blocks. The runtime and interface had to agree about which run an event belonged to and which block should display the text. A useful preview required that connection. A finished response in the wrong place would obscure the procedure just as effectively as showing no result at all.
Mobile questions and results
The mobile prototype tested the other side of the application. Here, the user was already talking to an agent and needed to answer a question. The July 25 playground showed a presentation-preparation example with an explicit choice to create a checklist. The chosen response appeared in the conversation, followed by a document card.
A button gave the answer an exact form. The user did not need to type a sentence that the model would then interpret as permission to continue. A document card also gave the result somewhere to open, instead of requiring the entire output to remain a long chat message.
The recording demonstrates the mobile components and message protocol in a playground. Connecting the full Day Bear behavior to the engine remained on the work list. That separation let me test the human interaction while the agent implementation continued: the builder described and tested a procedure, and the mobile interface handled the questions and results that procedure would present to its user.