The first mistake I made with coding agents was treating them like smarter chats.
Open the box. Type the request. Wait for code. Correct the code. Repeat.
That works for small things. It is also the reason the workflow starts to feel messy as soon as the work becomes real. One issue becomes one branch. Then another agent opens another worktree. Then a useful idea lives only in a chat thread. Then production has custom domains, Vercel has previews, old Firebase context is still around, Linear has the roadmap, GitHub has the PR, and nobody remembers which version is the one that matters.
At that point the problem is not whether the model is smart enough.
The problem is management.
Part of why this clicked is that I was already tired of how agentic-workflow advice shows up on X. Every week there is another thread about the best harness-engineering repo, another orchestration trick, another prompt stack that promises to make the whole thing obvious. Some of it is useful. A lot of it is noise. When there is that much fluff, it becomes harder to track what actually changes the work.
What I liked about OpenAI's harness engineering article and Symphony is that they gave the workflow a shape: the issue, the worker, the workspace, the checks, the PR, and the human gate.
That is why Symphony clicked for me. I did not understand it first as a product. I understood it as a missing layer.
Linear is the list of work.
Codex is the worker.
Symphony is the manager above them.
It watches the work queue, creates a clean workspace, gives Codex the issue and the rules, lets the agent work, asks for proof, and moves the result toward a PR. The agent does not become magical. It gets an operating system.
The useful detail in OpenAI's write-up is that Symphony changes the center of gravity. The Codex session is not the thing being managed anymore. The ticket is. A Linear issue becomes the durable unit: it gets a workspace, a status, a run loop, and a review path.
Source: OpenAI Symphony article.
That is the part I care about.
The agent needs a workplace
When I use Codex or Claude Code directly, I am still the person doing a lot of invisible orchestration.
I choose the issue. I decide which branch should exist. I remember which worktree is dirty. I paste context from one place into another. I check whether the build passed. I decide whether the change belongs in the current PR or a new one. I update Linear so the work is not trapped in the chat.
Some of that is good. I want to stay close to the work. But some of it is just coordination tax.
The more agents I use, the more obvious this becomes. Writing the code is only part of the job. The harder part is keeping the environment legible enough that the code can be trusted.
That is why I started caring about the small files and records that make agents usable:
- repo instructions for Codex and Claude
- workflow notes
- handoff docs
- worktree ledgers
- pull request templates
- Linear comments
They do not feel exciting. They feel like paperwork.
But they are the workplace.
Without them, every agent starts from vibes. With them, an agent can land in the repo and understand the rules: how to branch, what to verify, what not to deploy, where production lives, what a preview means, and when a human needs to approve the next step.
Chat history is not infrastructure
The biggest trap with agent work is letting the chat pretend to be the source of truth.
It feels natural because the chat is where the work happens. The explanation is there. The mistakes are there. The decision is there. The reason a branch exists is there.
But chat is a terrible long-term memory for engineering.
It is private, fragile, hard to diff, and easy to lose. Another agent cannot reliably start from it. A pull request cannot review it. CI cannot enforce it. Future me will not remember which conversation contained the one important instruction about production deploys.
A repo can remember better.
That is the shift I am trying to make with my site. If something matters, it should move from the conversation into the system:
- Linear for what is being done
- Markdown for what has been decided
- Git branches for isolated changes
- PRs for review
- CI for proof
- Vercel only after approval
Symphony is interesting because it assumes this shape. It does not ask the agent to be a genius in an empty room. It gives the agent a job, a workspace, a loop, and a definition of done.
The workflow is the product
Before looking at Symphony, I thought the next step was mostly better agents.
Now I think the next step is better harnesses.
OpenAI calls this harness engineering, and that phrase helped me put language around what I was already feeling. The agent sits inside a larger system. The harness is everything around it: the repo instructions, the workflow prompt, the tools, the checks, the branch rules, the places where the agent is allowed to act, and the places where it has to stop.
The model matters, but the harness determines whether the model can do useful work without creating chaos. A strong harness answers the practical questions:
- Which issue is this agent solving?
- Which branch owns the diff?
- What files are allowed to change?
- What checks must pass?
- Where does the result get reviewed?
- Who can merge?
- Who can deploy?
Those questions are not secondary. They are the workflow.
For my own site, this became very concrete. I have production and review environments on Vercel. I have oleksandr.lol and oleksandr.md connected through Namecheap and Vercel DNS. I have local Codex worktrees, Claude worktrees, Linear issues, GitHub PRs, Vercel previews, old Firebase context, and a production deploy path that should not happen casually.
That is too much state to hold in my head.
The lesson is that every surface can drift. A local worktree can contain the fix while the PR does not. A preview can look correct while production is still old. A domain can resolve while the www version points somewhere stale. A Linear issue can describe the work while the branch is still messy.
So the harness has to remember the boring truths: main is production, previews are only previews, each real change needs one issue and one branch, DNS has to be checked across all domains, old cloud resources should not keep running quietly, checks must pass, and production needs a human yes.
That is the point of the workflow. Not to make the agent feel more autonomous, but to make the work harder to lose, confuse, or accidentally ship. The workflow has to become visible: not theoretical, but present in files, branches, issues, checks, and the human yes before production.
I still want the human gate
I do not want an agent to silently ship my website.
Especially not a personal site, lol.
The site carries more than code. It carries taste, memory, writing, references, and the public surface of how I think. An agent can help draft, refactor, verify, and prepare the PR. But I still want to review the sentence. I still want to decide whether the design feels right. I still want to approve the production rollout.
That is where orchestration becomes useful. It can automate the boring middle without removing the human gate.
The best version of this workflow looks closer to this:
human decides what matters, agent prepares the work, system proves it, human approves the consequence
That feels like the right division.
What Symphony changed in my thinking
Symphony made the agent workflow feel less like magic and more like engineering management.
That sounds less exciting, but it is much more useful.
I do not need every agent to be autonomous in some vague way. I need the work to be structured enough that autonomy has boundaries. I need the agent to know where it is, what issue it owns, what branch it is touching, how to prove the change, and when to stop.
That is the real unlock for me.
Not a smarter chat.
A managed system for getting work done.
I am not ready to let Symphony run my real repo yet. The safe path is a sandbox first: one Linear project, one harmless issue, one agent, one draft PR, no production deploy. If that works, then maybe it earns more trust.
But the idea already changed how I think about the stack.
Linear holds the work. GitHub holds the code. Markdown holds the decisions. CI holds the proof. Vercel carries the release. Together, they are the rails that make agent work less fragile.
That is the direction I want my workflow to move in.
Not more scattered agents.
Better orchestration.