OpenAI julkaisi Symphony-nimisen avoimen lähdekoodin spesifikaation, jolla Codex-koodausagenteille voidaan rakentaa oma orkestraattori. Sovellus lukee tehtävät Linear-projektihallinnasta ja käynnistää erillisen agenttisession jokaiselle tiketille omassa työtilassaan.
Yhtiön mukaan kyse ei ole uudesta tuotteesta vaan tavasta osoittaa, miten Codex App Server taipuu jatkuvasti pyörivien agenttitiimien rungoksi. Lähdekoodi ja spesifikaatio ovat saatavilla GitHubissa Apache 2.0 -lisenssillä, ja referenssitoteutus on kirjoitettu Elixirilla.
Tikettijonosta agenttien työohjeet
Symphony pollaa Linearin projektitaulun säännöllisin väliajoin ja poimii aktiivisessa tilassa olevat tiketit työjonoon. Jokaista uutta tikettiä varten luodaan oma työhakemisto, johon Codex käynnistetään App Server -tilassa. Agentti pysyy työpaikallaan, kunnes tehtävä on suoritettu tai tiketin tila vaihtuu sopimattomaan.
Käytännössä yksi insinööri voi seurata kymmenen samanaikaisen agentin etenemistä yhden hallintapaneelin kautta. OpenAI ilmoitti käyttäneensä järjestelmää sisäisessä kehitystyössään ja toteaa Symphonyn toimivan parhaiten koodikannoissa, joissa harness engineering -käytännöt — automatisoidut testit, agenttiystävällinen rakenne ja suojaverkot — ovat jo olemassa.
Tikettiin sidottu pull request, CI-status ja katselmointipalaute palautetaan automaattisesti orkestraattorille. Tulosten hyväksyntä tapahtuu silti aina ihmisen toimesta.
Workflow-tiedosto pitää säännöt versionhallinnassa
Symphonyn keskiössä on WORKFLOW.md, repon sisällä elävä tiedosto. Sen YAML-otsake määrittää tikettilähteen, työtilojen sijainnin ja agenttien rinnakkaisuuden. Tiedoston Markdown-runko toimii Codex-istunnon kehotteen pohjana — koko agentin käytöstä ohjaa repoon committoitu säännöstö.
Tämä yksityiskohta erottaa Symphonyn monista markkinoiden orkestrointityökaluista. Agentin kehotteet eivät elä erillisessä SaaS-paneelissa, vaan ne kulkevat sovelluskoodin mukana. Pull request -prosessi koskee yhtä lailla agenttien sääntökoodia kuin tuotantokoodia.
Liquid-templatointi mahdollistaa dynaamisen sisällöntäytön, kuten tiketin otsikon ja kuvauksen lisäämisen agentin lähtökontekstiin. Yksinkertaiselle tiimille riittää tyypillisesti muutaman kymmenen rivin Workflow-tiedosto.
Eristetyt työtilat ja sandbox-asetukset
Symphony käyttää oletuksena tiukkoja rajauksia. Codex käynnistyy workspace-write-sandboxissa, joka rajaa tiedostokirjoitukset kunkin tiketin omaan kansioon. Hyväksyntäkäytäntö on oletuksena reject-tilassa, eli agentti ei saa vahvistuksia ilman ylläpitäjän väliintuloa.
Asetukset ovat ylikirjoitettavissa, mutta dokumentaatio kehottaa siirtymään löysempiin sandbox-tiloihin vain harkiten. Kullakin tiketillä on oma git-työtila, johon Workspace Manager pitää huolen elinkaarihookien ajamisesta sekä siivouksesta tiketin sulkeuduttua.
agent.max_turns-asetuksella rajataan, kuinka monta peräkkäistä Codex-vuoroa Symphony saa ajaa yhdessä agenttikutsussa. Oletusarvo on 20. Yhdistettynä eksponentiaaliseen retry-logiikkaan järjestelmä toipuu väliaikaisista API-katkoksista ilman tilakannan tarvetta.
Ei tuote vaan referenssitoteutus
OpenAI tekee selväksi, ettei se aio ylläpitää Symphonyä standalone-tuotteena. Repo on tarkoitettu opettavaksi esimerkiksi siitä, miltä Codex-orkestraattori voi näyttää, kun se rakennetaan App Serverin päälle. Yhtiö ehdottaa, että tiimit pyytävät omaa koodausagenttiaan generoimaan kullekin tarpeeseen räätälöidyn version.
InfoWorldin haastatteleman Forresterin Biswajeet Mahapatran mukaan Symphony siirtää tekoälyä yksittäisen kehittäjän tuottavuustyökalusta jaetuksi kehitysinfrastruktuuriksi. Greyhound Researchin Sanchit Vir Gogia kutsuu sitä "kevyeksi käyttöjärjestelmäksi ohjelmistotoimitukselle".
Help Net Securityn raportin mukaan Symphony toimii lähinnä koodikannoissa, joissa CI-putki, automaattiset testit ja roolipohjaiset suojaverkot ovat valmiina. Ilman näitä pohjia agentit eivät vapaudu valvontaa vaativista työnkuluista.
Yhteenveto
Symphony ei ole valmiiksi tehty SaaS-palvelu vaan referenssimalli siitä, miten Codex-agentit voi siirtää manuaalisesta käytöstä jatkuvasti pyörivään orkestrointiin. Käytännössä se sopii tiimeille, jotka ovat jo investoineet harness engineering -käytäntöihin ja haluavat ottaa seuraavan askeleen.
Suurin yksittäinen muutos koskee insinöörien ajankäyttöä. Sen sijaan että jokaista agenttia ohjataan yksittäisestä terminaalista, tiimi hallinnoi tikettijonoa ja katselmoi tuloksia. Linear-integraation valinta antaa Symphonylle nopean alkupisteen, mutta spesifikaatio on kirjoitettu siten, että muutkin tikettilähteet voidaan kytkeä omassa toteutuksessa.