OpenAI recently launched Symphony, which is a small orchestrator that uses linear edit score. And they chose a very interesting way to distribute this orchestrator and that 's with a single spec file you can see here on screen. To get the orchestrator up and running, you just point your agent to this spec file and have it implemented, which to me is a very bold statement from OpenAI. The way Symphony works is that you describe your workflow in a workflow.md file

have it implemented, which to me is a very bold statement from OpenAI. The way Symphony works is that you describe your workflow in a workflow.md file . For example, you can say, if the issue has the label "Agent Ralph", you need to work on the child issues and only when everything is complete, you can mark the parent issue as complete. The CLI is polling linear at the fixed cadence and when an issue appears, the orchestrator

The CLI is polling linear at the fixed cadence and when an issue appears, the orchestrator spawns an agent and it gets to work. And this works, but in my opinion it has two big limitations. Number one, you can only have a single workflow.md file and you need to describe literally everything in there. And number two, since this is built by OpenAI, there is no support for Claude. So me and Claude got to work and I created my own orchestrator based on the core ideas

So me and Claude got to work and I created my own orchestrator based on the core ideas found in Symphony. And by lack of a better name, I called it "Better Symphony". The difference with Symphony is that this has support for Claude and it has support for multiple workflow files because it has a small routing layer built in. Let me show you. Right here I have two workflow files, I have Ralph.md and I have PRD.md. In my implementation of Symphony, Ralph is a first class citizen as well as Y

Right here I have two workflow files, I have Ralph.md and I have PRD.md. In my implementation of Symphony, Ralph is a first class citizen as well as Y oloBox. So right here we can say Agent, Mode, Ralph Loop and this will take all the principles we talked about in this course and apply it here. So to clarify, Ralph Mode is not running the loop inside the context window, the loop is handled by the orchestrator itself. We have a bunch of hooks we can use, for example we have an after-create hook

handled by the orchestrator itself. We have a bunch of hooks we can use, for example we have an after-create hook and then we will clone this repository and before running we will set up our workspace. Then in here we have our routing layer, we can say the issue is active when it 's in to-do or in progress, it's turnal when it's done or cancelled and the required label is Agent Ralph. This means that this workflow will only be applied when the label Agent Ralph

Agent Ralph. This means that this workflow will only be applied when the label Agent Ralph is present. Cooling down we can see the actual workflow file using liquid.js, these variables will be replaced with their actual value at runtime. So we can say, Ralph Loop the sub-task is one out of ten for example, we are currently working on ABC and this is the title, the parent issue is this one and this is the title.

working on ABC and this is the title, the parent issue is this one and this is the title. Here we'll build our progress and we do that by looping over the children and saying whether or not the child is completed. Finally, we arrive at the instructions where we say things like move the sub- task to in progress or swap the labels etc etc. And for the PRD workflow we require the label Agent PRD. We allow up to three concurrent agents to generate PRDs and in here we will

And for the PRD workflow we require the label Agent PRD. We allow up to three concurrent agents to generate PRDs and in here we will basically find our PRD skill from before. Let's open up the terminal and say bunnics, better, symphony and let's say dash dash web so we get a nice web interface and right here we can see two workflow files have been loaded and we have four slots, that's because we have three slots for the PRD and one for

loaded and we have four slots, that's because we have three slots for the PRD and one for Ralph. If you go to linear I created a small issue here, we want to add a larval backend to our example app instead of the static menu.js file. We apply the label Agent PRD and we set it to to do and if you go to the web interface we can see the issue got picked up and Claude started working on it. If you go back to linear you'll see it move to in progress and the label Agent

we can see the issue got picked up and Claude started working on it. If you go back to linear you'll see it move to in progress and the label Agent PRD progress got applied and the beauty of it is you can literally just create a workflow file that suits you because it's just a markdown file. Now instead of waiting on the PRD to generate let me show you a few things I've been doing in my actual project. This is an actual PRD I worked on a few days ago and multi-safe pay is a

in my actual project. This is an actual PRD I worked on a few days ago and multi-safe pay is a payment provider and for some reason the transaction timeout was set to 30 days instead of 60 minutes which would have been a more sensible default but hey, so this was my original request. I applied the label Agent PRD on it and it generated this entire PRD for me. If you scroll down we can see the activity log the PRD got created and we have three

If you scroll down we can see the activity log the PRD got created and we have three sub-tasks then I added the label Agent Ralph and put it back to to do and scrolling down the Ralph loop started working and worked on these three sub-issues. So going back up the workflow is actually very powerful my original request was basically this sentence and a reference to the documentation then the PRD got created and worked out all the details and I let Ralph loose on the implementation and about 20 minutes

worked out all the details and I let Ralph loose on the implementation and about 20 minutes later it was completed. This is a different issue I worked on I also have a workflow to spot books for example we had a customer that claimed that the VAT ticket did not print. And I had a rough idea where the issue might have been like in the sinking logic for example and the triage agent got to work but in the initial analysis it didn't really find the

and the triage agent got to work but in the initial analysis it didn't really find the issue of the customer but then the customer called. I added this comment wait the customer called and clarified the order was never registered and it was showing as open and after I re-dispatched the issue the triage agent revised the entire issue and found the actual book which was at table orders never actually registered if this flag was disabled.

registered if this flag was disabled. This workflow hunted down the book in a matter of minutes and it will have taken me literal hours to figure it out. Jumping back to our issue we can see that the PRD agent is complete and it created these sub-issues for us. We can scaffold the larval project we can create a migrations for menu items, customizations

We can scaffold the larval project we can create a migrations for menu items, customizations and coupons, the eloquent models we'll create the controllers, the cedars and finally we will update the view up to fetch from the API instead of static imports. If you want to implement this now we can just swap the label to Agent Ralph, put it to to do and if you open better symphony I will force a poll. We'll see that the ticket now gets picked up by Ralph and it gets to work. And this is actually something I've been running over the past few weeks and it

We'll see that the ticket now gets picked up by Ralph and it gets to work. And this is actually something I've been running over the past few weeks and it saved me so much time. Thank you very much for sticking with me through this course. Let's briefly reflect on what we achieved. In the first lesson our Ralph loop was invisible because it ran in print mode without streaming. We then improved this and added streaming support so we can actually see what the model

We then improved this and added streaming support so we can actually see what the model is doing. We then talked about the PRD and how important this concept is for running Ralph successfully. We learned about Tmux and how to use it to run loops in the background and we learned about sandboxing, permissions, hooks, auto mode and finally we bypassed the permission system entirely using YoloBox.

permission system entirely using YoloBox. We then upgraded our small Ralph script to an entire CLI which we used throughout the lessons. We added word tree support but also learned about the downsides of word trees and how I actually like to use a copy on right clone instead. We then moved the PRDs to linear, added ourselves back into the loop to prevent things from

We then moved the PRDs to linear, added ourselves back into the loop to prevent things from going sideways and we then talked about running loops on a remote machine. Finally I showed you the experiment I ran with the perpetual loop and we doubled a bit in a genetic orchestration to conclude this video series. Now this is not an ending. This is just the beginning because the speed of change in the AI landscape is quite literally insane.

quite literally insane. I highly encourage you to experiment with these tools because it's never been more exciting to be a developer than today. Don't be afraid to get your hands dirty. I included the source code of a Ralph CLI so you can modify it to your exact needs. Thank you so much for sticking with me and I'll see you in the next one.

Thank you so much for sticking with me and I'll see you in the next one.