--- schema: "swft.publication/v1" id: "company-openai-codex-symphony" title: "OpenAI's Codex factory: harness engineering and Symphony orchestration" description: "How OpenAI combines agent-legible repositories, executable feedback, architectural checks, agent review, and Symphony issue orchestration." summary: "One OpenAI team built an internal product by changing the repository and feedback systems around Codex, then created Symphony to assign project-board issues to isolated agent sessions. The public spec and operating account are unusually concrete, while the speed, scale, and adoption figures remain first-party evidence from bounded settings." canonical: "https://swft.io/companies/openai-codex-symphony" author: "SWFT Editorial" author_type: "Organization" published: "2026-09-01" modified: "2026-09-02" kind: "case-study" section: "Companies" tags: ["OpenAI Codex", "Symphony", "harness engineering", "agent orchestration", "agent-legible repository", "AI software factory"] evidence_labels: ["OBS", "SELF-REPORT"] source_ids: ["openai-agents-work", "openai-harness-engineering", "openai-symphony", "openai-symphony-blog"] authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections." --- # OpenAI's Codex factory: harness engineering and Symphony orchestration OpenAI made one repository legible and testable by Codex, then used Symphony to turn project issues into isolated, continuously managed agent work. > **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections. ## Quick answer One OpenAI team built an internal product by changing the repository and feedback systems around Codex, then created Symphony to assign project-board issues to isolated agent sessions. The public spec and operating account are unusually concrete, while the speed, scale, and adoption figures remain first-party evidence from bounded settings. OpenAI's public material describes two connected systems. One team redesigned a repository so Codex could build, test, review, and maintain a working product. It then created Symphony to assign issue-tracker work to isolated Codex sessions and keep those sessions running until people could review the result. ## Harness engineering changes the repository around the agent OpenAI's [harness-engineering account](https://openai.com/index/harness-engineering/) follows an internal product built under a strict experiment: no manually written code. Over five months, a small team used Codex to generate application code, tests, CI configuration, documentation, observability, and internal tools. OpenAI reports roughly one million lines of code and about 1,500 merged pull requests, with three engineers initially directing the work and seven later. The team estimates that it built the product in one tenth of the time manual coding would have required. The product had internal daily users and external alpha testers. **Harness engineering** means improving the environment around an agent so it can do reliable work. In this experiment, people specified intent, designed the system, improved the tools, and encoded feedback. Codex performed the repository changes. The time estimate is a team judgment about a counterfactual project that did not happen. Lines of code and pull-request count measure production volume, not usefulness or maintainability. The experiment also started with an empty repository, which makes it different from changing a mature product with years of hidden assumptions. ## The repository becomes the shared memory The team kept a short AGENTS.md as a map, then stored architecture, product specifications, execution plans, reliability guidance, and design decisions in a structured docs directory. Mechanical checks verified that the knowledge remained linked and current. A recurring documentation agent looked for stale material and proposed repairs. This approach is called **progressive disclosure**. The agent receives a small map first and loads deeper context only when the task needs it. It protects the context window from a large instruction file while keeping important decisions close to the code they govern. The application could start once per Git worktree, giving each change an isolated instance. Codex could inspect the browser through Chrome DevTools and query task-local logs, metrics, and traces. Architectural dependency rules, data-boundary checks, file-size limits, and other invariants were enforced by linters and structural tests. These feedback loops made product behavior legible to the agent. A request such as keeping startup below a time limit can only be delegated when the agent can run the system, measure the result, and tell whether its change helped. ## Symphony turns the issue tracker into a control plane The team later published [Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/), an open-source specification for coordinating coding agents. Symphony watches a project board such as Linear. Each active issue receives an isolated workspace and an agent session. The agent can use repository tools, create several pull requests, read review feedback, and continue until the issue reaches a terminal state or needs human input. The issue tracker acts as a **control plane**: it records the work, status, ownership, and human decisions while execution happens elsewhere. Instead of supervising terminal tabs, a person reviews the deliverable and its evidence in the ordinary product workflow. The public [Symphony repository](https://github.com/openai/symphony) is an engineering preview centered on a language-independent specification. It is inspectable starting material, not a hosted production service or proof that a particular implementation is safe for every repository. ## Agent-to-agent review protects human attention For a pull request, Codex reviews its own changes, requests focused reviews from other agents, responds to agent and human comments, and iterates until the required reviewers are satisfied. People may review changes, but the experiment moved much of the routine review burden to agent-to-agent loops. This changes where people spend time. Engineers inspect goals, architecture, product behavior, exceptions, and the quality of the controls. It also creates a new risk: several agents can repeat the same blind spot. Deterministic checks and independent human judgment remain important where the consequence is high or the success condition cannot be expressed completely. ## Company-wide adoption adds scale, not outcome proof OpenAI's [June 2026 work study](https://openai.com/index/how-agents-are-transforming-work/) says the average OpenAI engineer generated 99 percent of their output tokens through Codex rather than ChatGPT. Among daily active internal users, people at the 99th percentile generated more than 60 hours of Codex agent turns per day across parallel agents. Tokens and agent hours show how the tool is used. They do not measure accepted code, customer benefit, cost effectiveness, or quality. The paper estimates human task duration with a model judge and says those horizon estimates should be treated as directional. ## The evidence comes from a bounded experiment OpenAI authored all three operating accounts. The harness article describes one new product and says the team still does not know how coherence will evolve over years. Public material does not provide raw review data, defect trends, full operating cost, abandoned runs, or a controlled comparison. Symphony is public, while the internal product, repositories, prompts, tools, and usage data remain private. ## What a product team can copy Make the repository the current source of product and engineering knowledge. Give agents isolated, runnable applications plus direct access to tests, logs, metrics, and interface evidence. Enforce architecture with exact checks. Use the issue tracker to hold durable state while agents work elsewhere. Start with a bounded product line, and measure accepted outcomes, rework, defects, cost, and human attention alongside generation volume. ## How we know - **First-party report (SELF-REPORT)** OpenAI describes a five-month internal product experiment with no manually written repository code, agent-legible documentation, isolated app instances, observability, structural checks, and agent review loops. Sources: [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/). - **First-party report (SELF-REPORT)** OpenAI describes using Symphony to map issue-tracker work to isolated agent workspaces and continuous sessions with human review of results. Sources: [An open-source spec for Codex orchestration: Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/). - **Observed artifact (OBS)** OpenAI publishes Symphony's language-independent specification and reference implementation for inspection and adaptation. Sources: [Symphony](https://github.com/openai/symphony). - **First-party report (SELF-REPORT)** OpenAI reports high internal Codex token share and many hours of parallel agent activity while identifying model-based and directional limits on task-duration estimates. Sources: [How agents are transforming work](https://openai.com/index/how-agents-are-transforming-work/). ## Sources - **First-party report (SELF-REPORT)** [How agents are transforming work](https://openai.com/index/how-agents-are-transforming-work/) — OpenAI; published 2026-06-25; accessed 2026-09-01. OpenAI's first-party internal usage study across engineering and non-technical departments; runtime and output-token figures are adoption signals, not direct quality measures. - **First-party report (SELF-REPORT)** [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/) — OpenAI; published 2026-02-11; accessed 2026-09-01. OpenAI's bounded internal experiment with an agent-written repository, enforceable architecture, repository-legible context, proof loops, observability, and recurring cleanup. - **Observed artifact (OBS)** [Symphony](https://github.com/openai/symphony) — OpenAI; accessed 2026-08-31. Open-source engineering preview for turning project work into isolated agent implementation runs with proof of work and protected landing. - **First-party report (SELF-REPORT)** [An open-source spec for Codex orchestration: Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) — OpenAI; published 2026-04-27; accessed 2026-09-01. OpenAI's account of turning a Linear board into a state machine and control plane for continuous isolated agent work, task dependencies, retries, and human review. ## Read next - [Vercel eve: the shared infrastructure behind more than 100 production agents](/companies/vercel-eve) - [Stripe Minions: how developer infrastructure became an AI software factory](/companies/stripe-minions) - [How an AI software factory works](/software-factory-architecture)