Workflow Studio Has Been Rebuilt

Workflow Studio has been rebuilt. The old version worked. You could build workflows in it, publish them, run them, and get real work done. But over time, a more annoying problem became obvious: too much of the building process was happening outside the builder itself. You would write a prompt somewhere else, come back, paste it in, test it, realize it needed changing, and bounce out again. If you wanted Composer to generate a workflow for you, that happened on a different screen. If you were building a loop, one of the parts of a workflow where a small mistake can quietly ruin everything, you configured it through a settings panel and basically had to hold the iteration logic in your head. None of those things were individually catastrophic. Together, they made the product feel more fragmented than the workflows people were trying to build. That was the problem we wanted to remove. The new Workflow Studio is much more opinionated about one thing: if you are building a workflow, the important work should happen where the workflow is. ## Composer belongs on the canvas Composer used to feel too separate from the thing it was helping you create. You could describe what you wanted and have a workflow generated, but moving between the generation experience and the actual builder introduced a strange break in the process. That distinction never made much sense. If an AI system is helping you build a workflow, it should be able to see the workflow you are already working on. It should understand the existing graph, the steps you have already added, and the structure in front of you. You should not have to repeatedly explain the same context just because you moved from "generate" mode into "edit" mode. So Composer now lives directly inside the canvas. You can describe what you want while looking at the workflow itself. Composer can build from scratch, but more importantly, it can continue from where you already are. It can extend an existing workflow, modify steps that are already there, and work against the graph you are currently editing. That changes the role of Composer quite a bit. The useful version of AI-assisted building is not just "type a sentence and get a workflow." That is impressive the first few times, but real workflows rarely arrive fully formed from one prompt. You build something, inspect it, change your mind, add another branch, realize one step needs to happen earlier, discover an edge case, and keep iterating. The assistant needs to participate in that process rather than restarting it every time. That is what moving Composer into the canvas is really about. Less generation as a separate event, more AI assistance as part of the normal building loop. ## Some things deserve more than a settings panel Loops were another obvious problem. Iteration is one of those features that looks simple right until the workflow becomes useful. "Run these steps for every item" sounds straightforward. Then you start dealing with where the loop begins, what belongs inside it, how data moves between iterations, what gets collected, what happens when one item fails, and what the workflow should do after the loop finishes. At that point, hiding everything behind a few fields in a side panel stops being elegant and starts being hostile. The previous Studio treated loops too much like ordinary configuration. The new version gives them their own editor because they are not ordinary configuration. They change the structure and execution model of the workflow. ```docsgraph loop ``` That distinction matters as workflows get larger. A builder should not optimize purely for how clean it looks when there are five nodes on the screen. It has to stay understandable when the workflow has enough logic that you can no longer keep the whole thing in working memory. The loop editor is part of that shift. Complex parts of the workflow should get interfaces designed around the complexity they actually contain instead of being compressed into generic settings panels because it makes the UI look simpler in a screenshot. ## Prompts are part of workflows We made a similar decision around prompts. Prompt Studio is gone. For a while, Edgaze had a separate product experience around creating and publishing prompts. It was intended to provide an easier entry point into the platform, but it created the wrong abstraction. Prompts became something separate from workflows when, in practice, prompts are usually one component inside a larger system. A good prompt can matter enormously, but it is rarely the entire product once you start solving more serious problems. It sits alongside inputs, tools, branching logic, structured outputs, retries, integrations, model selection, and other steps. So instead of maintaining a separate place for prompts, Workflow Studio now has a dedicated prompt editor built directly into it. If you are working on an LLM step, the prompt should live with that step. You should be able to edit it properly, reason about it in context, and continue building without jumping into another product surface. This sounds like a small UX improvement, but it reflects a larger product decision. We are not trying to turn Edgaze into a marketplace of isolated prompts. We are trying to make it easier to build and distribute workflows that produce outcomes. Prompts are an important building block. They are not the destination. ## The canvas needed to scale with the workflow The nodes themselves have also been redesigned. This was less glamorous than adding a new AI feature, but probably more important for anyone spending real time in the builder. The old nodes carried too much visual noise, and as workflows became larger, scanning the graph became harder than it should have been. The new nodes are cleaner and much easier to distinguish at a glance. The goal is not simply to make screenshots prettier. It is to reduce the amount of effort required to understand the graph. Large workflow builders can become visual spaghetti remarkably fast. Once every node is covered in labels, controls, status indicators, metadata, handles, and configuration details, the canvas stops functioning like a map of the system and starts looking like an airport departures board during a thunderstorm. The redesign tries to keep the important information visible while pushing everything else into the places where it is actually needed. The rest of the workspace follows the same principle. The inspector has been redesigned, templates have been overhauled, and the main panels are much more flexible. The block library, Composer, and inspector can be resized and repositioned depending on how you prefer to work. That matters because there is no single correct layout once a builder becomes a serious workspace. Someone editing prompts needs different screen space from someone wiring a large graph. Someone debugging a workflow may want the inspector permanently open. Someone constructing new sections may care more about the block library or Composer. The interface should adapt to the work rather than forcing every task into one fixed arrangement. Performance was also part of the rebuild. A workflow builder can have every feature in the world and still feel terrible if moving around the canvas feels heavy. The larger Studio gets, the more important it becomes that basic interactions remain fast. Nobody should be thinking about renderer performance while trying to figure out why their third branch is returning the wrong data. ## A few new blocks, and one overdue fix The rebuild also adds three nodes: web scraping, workflow forms, and a rebuilt YouTube transcript node. Web scraping gives workflows a direct way to pull information from webpages and use it further down the graph. A public page becomes Markdown, text, structure, and links that later steps can actually work with. ```docsgraph web-scrape ``` Workflow forms make it easier to turn workflows into user-facing experiences where someone can provide structured inputs without having to understand anything about the workflow behind them. One form can collect several answers instead of scattering them across separate input blocks. ```docsgraph workflow-form ``` The YouTube transcript node is slightly less exciting to announce because it is partly an apology. The previous version was unreliable for a stretch. Some users hit failures that should not have happened. It has now been rebuilt and is working properly again. ```docsgraph youtube-transcript ``` That kind of thing is worth saying plainly. New features are nice, but a node that exists and works only some of the time is worse than a node that does not exist at all because people build around it expecting it to behave. So yes, that one needed fixing. ## Building should be cheap while you are still figuring things out There is another kind of friction we wanted to remove from Studio: being charged while experimenting. Workflow development is inherently iterative. You run something, inspect the output, change a prompt, run it again, fix a condition, change a model, run it again, and eventually discover that the actual problem was the thing you changed three versions ago. That is normal. Charging for every one of those experiments creates the wrong incentive. People start avoiding tests precisely when they should be running more of them. Every workflow created in Workflow Studio now gets 10 free test runs while you are building it. Composer also has a generous free tier, with substantially higher usage available through Edgaze Plus. The goal is not to make execution free forever. Real workflow runs consume real infrastructure and model usage. The goal is to separate experimentation from production enough that creators can actually figure out whether something works before worrying about every cent attached to a test. You should be able to break your workflow a few times. In fact, you probably will. Better inside Studio than after somebody pays for it. ## Less interface, more workflow The common thread across all of these changes is context switching. Composer being separate created context switching. Prompt Studio created context switching. Loop configuration forced too much reasoning outside the canvas. Rigid panels made people adapt their workflow to the interface instead of adapting the interface to the work. The rebuild tries to pull those pieces back into one place. A workflow builder will always have complexity because the things being built inside it can be complex. The answer is not to pretend that complexity does not exist. The answer is to make sure the complexity belongs to the workflow itself, not to operating the tool. That is the direction we want Workflow Studio to keep moving in. Less time managing the builder. More time building the thing.