Orchestras, Not Factories: How the Fastest Builders Work — Charlie Holtz, Conductor

At a wedding in New York, Charlie Holtz mentioned that he was preparing a presentation about AI engineering. His conversational partner’s eyes glazed over. An audience that actually wanted to hear about coding agents was a welcome change. Holtz, Conductor’s co-founder and CEO, used that opening to introduce a practical question: what do the fastest builders do with these tools?

Conductor is a desktop app for managing multiple coding agents at once. Instead of distributing their sessions across terminal windows, it brings them into one interface. Building that interface gave Holtz a close view of other engineers’ workflows: where they invested effort, what they delegated and what they avoided. The principles that follow are his synthesis of those observations and Conductor’s own experience.

“Stay near the frontier” starts with trying new tools and workflows when they arrive. For a startup, that exposure can change what seems worth building. Conductor itself began this way. The team was working on a different app, Chorus, when heavy use of a coding agent started reshaping its development process.

The first response was to clone the repository five times. Then the team discovered Git worktrees, and the workflow gradually became an internal tool: Conductor. The product idea emerged from using the new capability enough to encounter a concrete coordination problem. Multiple agents were useful; managing their work needed a better interface.

Inside an established company, the same habit can make someone the person who knows which workflows are newly possible. Holtz warns that waiting for useful practices to trickle through a social network can leave a builder three to six months behind; that is his assessment of the pace, rather than a measured adoption delay. But the word near matters. Experimentation stops paying when improving the workflow consumes all the time that was supposed to go into the work.

Conductor’s heuristic for deciding how far to customize is “don’t try and beat the market.” Ask why a promising workflow is not already the default. If it works broadly, Holtz expects providers such as Anthropic or OpenAI to incorporate it into their agent harnesses—the tools that run and coordinate the model’s work. Under that expectation, extensively rebuilding a generally useful workflow yourself may buy only a temporary advantage.

The exception is “real alpha”: information about your users or codebase that a general model may not know. Conductor needs to render very long chats quickly. That product requirement justifies spending time optimizing its React queries, even when doing so requires sacrifices elsewhere in the codebase. The useful customization comes from knowing which behavior matters most for this app.

This puts a stopping rule around experimentation: invest when specific knowledge changes how the work should be done. Otherwise, keep the setup from becoming its own project. Holtz’s warning is familiar to anyone who has spent too long configuring an editor: an amazing Emacs setup does not ensure that anything gets finished.

A “slop-free zone” is an area that requires strict human review. Conductor applies that care selectively: some parts of the codebase get close scrutiny, while others allow much looser development. Holtz connects this practice to costly experience—the team had to rewrite its app a couple of times after failing to protect important areas.

• Migrations: CI requires a human review whenever the migrations file changes. This makes scrutiny a required step for that file, rather than a general aspiration.
• Team communication: Conductor treats Slack messages as human-written material. That is a team convention about who authors the communication.
• Documentation and agent instructions: Docs and skill files receive substantial attention. They shape what agents know and how they begin their work.

The instruction-file analogy is an intern joining the company. Imagine being able to whisper advice into that intern’s ear every time they sit down to work. You would choose those words carefully because they keep influencing subsequent decisions. Agent instruction files play that recurring role: their contents enter the agent’s context when it starts working. Time spent improving them can affect many tasks, which explains why the builders Holtz admires put unusual effort into these files.

Careful instructions provide standing guidance. “Feed the beast” adds information about what is happening now. Conductor’s internal tool, the Conductor Internal Agent—CIA—collects organizational activity in a central database. A new Slack message is picked up and saved to a Postgres table. Discord bug reports enter the same collection process, and recorded meetings go into the CIA as well.

How does information scattered across conversations become available to an agent? The diagram follows the collection and access paths. Centralizing the material gives agents one place to look for company-specific context; a SQL tool lets them query the database. Holtz’s prescription is deliberately simple: put the information in a database and give the agent a way to ask questions of it. The mechanism supplies access to context, without establishing that every query will find or interpret the right information.

“Free-range agents” need somewhere to work that survives the user closing a laptop. Holtz proposes persistent sandboxes where agents can explore the codebase, tackle difficult tasks, create more agents and collaborate with people. His reasoning is that longer-running, more capable models need an execution environment that does not inherit the interruptions of a personal computer.

The demonstration introduces a Conductor version centered on cloud collaboration. Each workspace has a cloud icon that exposes information about the sandbox running its agent. Holtz describes a change from tasks built around local Git worktrees to tasks running in cloud sandboxes, so work can continue after the laptop closes. He announces a rollout for the week of the presentation; that announcement does not establish subsequent availability.

Cloud execution also gives the interface a shared place for collaboration. The organization view lists work across teammates, and Holtz opens a colleague’s workspace to review its changes. He sends a request to use tabs instead of spaces. The colleague can see the message and chat in the same workspace; a typing indicator appears during the demonstration. The sequence establishes shared review and live conversation, though no corresponding code edit is shown.

The collaboration case follows from ambition. As models improve, teams can attempt larger projects, and larger projects call for more people and agents working together. A shared workspace gives those participants a place to inspect work and discuss its direction while it is underway. Holtz expects collaboration to become an important interface change because the unit of work increasingly includes a team.

The next example turns cloud execution into remotely initiated work. A personal agent has access to the Conductor API. Holtz describes reaching it from a phone, Telegram or Slack and asking it to create a workspace. His concrete task is simple: make all the buttons blue.

The request passes to the personal agent, which can call Conductor’s API to start the work. Holtz then reports that the workspace has been created and the coding agent is on the task. Opening Conductor shows that workspace setup is still underway. The observable change is therefore a new workspace beginning its task; the demonstration does not establish that the buttons were changed.

What separates sending a request from executing it? The diagram shows the handoff from a messaging interface through an API to a cloud workspace. The phone supplies the request, while the sandbox supplies the execution environment. That separation lets a person initiate a task while away and return to its workspace later, without requiring the laptop to remain the host.

The final principle gives the talk its title. Holtz dislikes the term “software factory,” even while recognizing that automation improves efficiency and makes it possible to produce more. His objection concerns the working experience and the goal that the metaphor encourages: a person managing an assembly line of agents that continually pumps out features.

An orchestra offers a different role for the person directing the work. A gesture starts one group of agents; another brings people and agents together. The conductor can zoom in on details when needed and spend much of the time looking across the whole effort. This is a design aspiration for the interface: make it possible to move between directing a team and examining its work, while retaining a sense of craft.

The shared-workspace demonstration makes part of that aspiration concrete: teammates can see ongoing work, review changes and discuss a decision in the place where the task is happening. The selective review policy supplies another part: a human deliberately gets close to migrations and recurring agent instructions. Cloud agents provide room to keep work moving between those interventions. Together, these choices let direction, review and execution happen at different levels of attention.

For tool builders, the ending is a responsibility as much as a metaphor. Holtz wants software to feel human and crafted, and wants the people making it to feel capable, absorbed and excited. His image is designing the Mac with a team of people and AI agents in the same place. The closing recap returns to all six principles, but the orchestra explains what their speed is meant to preserve: the pleasure and judgment of making something together.