Not yet a "success story" but a work in progress: my interest in agent harness orchestration has culminated in an article (that I'm pitching at the moment), and a 😆 And of course, my own orchestration system I'm working on. I'm loving the new OpenAI Symphony system (driven from Linear issues and GitHub PRs), and I'm using it to create OpenSymphony with several improvements. It will include a Rust TUI orchestrator dispatching work to OpenHands via

agent-server

. I'm using the reference OpenAI Symphony implementation (which uses codex app-server) to do the new implementation. I just started that build today. We'll see where it's as after a few hundred million more tokens! I already had

chatgpt-codex-connector

wired up to do automated code reviews, and it's so fun to see the system automatically responding to them and addressing them. In future iterations I can explore integrating it with emerging OpenHands work on verification stack and PR reviews.

Wow, this is ambitious. Any other projects similar to yours that you draw inspiration from?

https://github.com/Dicklesworthstone#the-agentic-coding-flywheel It's something I've been tracking but not yet using. But inspired me in the sense of seeing the amount and quality of his output with issue-based development. I think it's a very promising approach and beads are a compelling concept. However, I personally want to start with the Linear-based UX of having the human in the loop with a web-based or app-based issue tracker I can interact with even on my phone at a restaurant - like I did the other day 😄

Jesus, seeing stuff like this makes me realize just how puny my brain is. It's so humbling

It's pretty awesome, frankly. Two of the sub-projects that flywheel uses are AgentMail MCP and Beads, which I use

One 🤯 kind of thing from the flywheel is Cross Agent Session Resumer, which I've used to resume one agent harness' session in a different one. I may use it in OpenSymphony to resume OpenHands agent-server sessions in the harness of the user's choice at some point 😄

Thinking aloud, I do wonder if the all or nothing approach is the way to go. ie: resuming the entire session in a different model, instead of having the session itself broken down into 5-6 individual areas of responsibility, run by agents using models that have been eval'd to determine they are the best for that job given a number of relevant variables(ie: time, money, req' quality)

I've just finished my first end-to-end project implemented with OpenSymphony: a LiteLLM-based performance benchmarking suite to monitor and measure performance across LLM providers, models, agent harnesses, and configurations: https://github.com/trilogy-group/StackPerf I'm traveling today but will be editing some videos, doing some write-ups and doing the official OpenSymphony announcement this evening 😅 It will be a good plug for OpenHands 🙌🏼

@echoing-garage-24541 - Did you evaluate Flywheel and decide against forking it?

In my experience, Agent Mail and Beads are crazy useful; personally though, I use simpler versions of them (older versions were the necessary stuff, I don't update them to the newest bells and whistles) and haven't got as far as Jeffrey's flywheel

Is that an intentional choice to use simpler versions?

Yes. A bit vibe-choice, but it's a choice. They fit my purposes, they enabled an amazing 60k event sessions with 4 main agents and a bunch of additional reviewers; and I heard some concerns about Beads becoming too deeply entrenched in the system and/or buggy, idk

Entrenched in what system?

I think maybe OpenHands could do something like that, we could take inspiration from the Things That Work (tm)

@worried-salesclerk-85726 I simply wanted to adopt the Symphony design because I love the idea of Human In The Loop at the work issue & GitHub PR level. Having Linear as the primary UX is lovely, and seeing/participating in the PR review conversations helps build codebase understanding. I much prefer using openhands agent-server as the harness because by virtue of being an independent harness it's inherently more flexible and stable across providers and models. Also, it gave me the excuse to finally roll up my sleeves and dive into the OpenHands internals 😅 The other main improvement over the reference Symphony implementation (aside from a much better TUI, which I'm building with flywheel's FrankenTUI) is the ability to "debug" any issue's agent session interactively with the/a harness if ever needed.

This is rad!

Hoping to trade some ideas soon about "hosted mode" options from RemoteAPIWorkspace to APIRemoteWorkspace.. I'd like to offer a self-hosted team version as well as one using OpenHands Cloud.

Loving this @broad-flag-16604, so you're connecting specifically to the OH SDK or do you also tie into the CLI as well? Would developers want to bring their own skills and other harness components into OS or would OS leverage the skills, agents and refs from the inference layer of say OH?

Hi @worried-salesclerk-85726 the OpenSymphony orchestrator manages & connects to OpenHands via

agent-server

via HTTP and websocket. Each issue gets its own workspace and OH conversation session, which can be inspected/debugged interactively if desired. There are included skills with OpenSymphony that get scaffolded in, for interacting with Linear, for structuring the implementation plan and converting to issues, etc. Any additional skills could easily be added by the user at the repo level or globally. The three main orchestration challenges I noted in the course videos at the top of the thread are scope, context, and execution. One of the strengths of OpenSymphony is the execution. With this in mind, it's not a "one-shot attempt" because retries, hand-offs, and iterations are naturally part of the execution workflow. Automated code review or human interaction at the issue or PR level will trigger iterative refinement in a persistent workspace for the issue. Regarding the "protocols and pipelines" there is a repo-wide workflow (also scaffolded in via

opensymphony init

) that contains all the business logic for polling, updates, implementing the scope, presenting evidence, creating, linking, and interacting with PRs, etc. Each issue would leverage this and also manage its own acceptance criteria, test plan, audit trail, etc. While Vibe Kanban is somewhat related since it is a visual agent-management board for supervising and reviewing coding agents, OpenSymphony is a more full-featured workflow orchestration system for turning issues into structured, managed agent execution.

Ah, it was the structuring of the implementation plan I was curious about. I didn't the skills I would expect for the planning and execution so I wasn't sure where that happened and how it was executed. How did you decide what to keep in your inference harness vs what to push out to your programmatic layer?

In the event that we failed to complete a milestone because our turn budget was exhausted, it would trigger a full eval of the audit logs and propose architectural changes in the programmatic and inference pipelines to prevent the same failure next time.

Love this! How has it been working so far?

@calm-artist-7206 - Well the early deployment was really rough, it's combination of complexity and need for consistency taught us how important it is to move as much of our orchestration layer out of inference. Was a nightmare to produce reliable results and then even worse to get agents to reliably fix issues once diagnosed.

@worried-salesclerk-85726 I haven't had to deal with any "infinite loops"... it always either succeeds (most of the time), or is blocked and flags it appropriately, or in some edge cases it fails for some reason. For that, I have a

doctor

command and a

rehydrate

functionality and summarizes the conversation and recreates the session & workspace anew in case there is a non-recoverable error.

@broad-flag-16604 - how goes it?

Did you mean to tag me? 😅 I've been quite on OpenSymphony for a couple of weeks, but looking forward to picking it back up. Some items on the near-term roadmap: • Adding support for ChatGPT/Codex OAuth, maybe support for codex harness as an alternative • Making use of the newly-documented OpenHands hooks • Incorporating ideas / workflows from GSD-2 for user interviews, analysis, planning, and task creation. This will create a more end-to-end workflow • Examining opportunities for token efficiency. I was burning near 1B tokens a day. Almost all of it was cached input, which is much cheaper, but it still adds up.

yep, was curious as to the progress, exciting news thanks for sharing

New progress is underway. Release 1.6.0 is available with an auto-evolving memory and documentation system. 44 stories are in place for the hosted mode and rich desktop/web UX, and I'm now churning through them with a dedicated GPU deployment 😄 Excited to dogfood using OpenSymphony to build out OpenSymphony

@echoing-garage-24541 - Wow! This is huge, I love your tui layout.. And yes, dogfooding is the only way.. Our own tech development probably 10x'd once it got to the point where we could(and forced ourselves to ) use it to develop it.