Orchestras, Not Factories: Five Principles Top AI Developers Use to Manage Agents

At a wedding in New York, a Conductor co-founder mentioned they were preparing a talk on AI engineering — and watched the stranger's eyes immediately glaze over as they scanned the room for someone else to talk to. That same topic, invisible to most people, drew a room full of eager developers at the AI Engineer conference.

Conductor is a desktop app for managing teams of coding agents. Instead of juggling a pile of terminal windows to manage Claude Code, Codex, and other coding agents, you get a single unified interface to coordinate all of them. Building this product gave the team a front-row seat to how top developers actually work — and from that, they distilled a set of principles to help you become the fastest builder in your organization.

Principle 1: Stay Near the Frontier — But Not At It

"Staying near the frontier" means trying new tools almost the day they ship. When Ultra Code drops, you try it. When a new feature goes live, you jump in immediately. For founders, being close to the frontier constantly sparks new product ideas — that's exactly how Conductor came to exist.

The team was originally building a completely different app called Chorus, but as heavy Claude Code users, they started building workflows around it: first cloning a repo five times, then discovering work trees, and gradually an internal tool called Conductor took shape. Without staying close to the frontier, they never would have found that path.

The key word is "near," not "at." There's a real danger in being right at the frontier — what the speaker calls "midwit memeing" — spending all your time polishing workflows instead of doing actual work. To guard against this, the team arrived at a useful heuristic: Don't beat the market.

The way to check whether you've gone too deep is to ask: why hasn't this workflow already become the default? When something like Ralph Loops blows up, if it works for everyone, Anthropic or OpenAI will eventually bake it into the default toolchain — you can just wait. This is similar to the efficient market hypothesis: unless you have genuine alpha, you shouldn't be over-optimizing your workflow. Alpha here means information about your users or your codebase that the model is unlikely to know.

The efficient market hypothesis comes from finance: market prices already reflect all public information, so ordinary investors can't consistently beat average market returns. The speaker applies this logic to AI tool optimization — if a workflow trick is universally effective, mainstream tools will quickly absorb it as a default, and the marginal return on spending lots of time mastering it alone approaches zero. The only things worth deep optimization are scenarios that depend on information only you have — like deep knowledge of your codebase architecture, or insight into your specific user base's behavior. These are things models and general-purpose tools can't replace you on. That's what "genuine alpha" means. Git work trees are an advanced Git feature that lets you check out multiple branches from the same repo into different directories simultaneously, so developers can work on multiple tasks in parallel without constantly switching branches — one of the underlying mechanisms Conductor uses to manage multiple concurrent coding agents.

Principle 2: Create Slot-Free Zones — Strictly Human-Reviewed Areas

Many people assume the Conductor team are pure token maximizers, churning out 30,000-line PRs. The reality is the opposite. They're extremely cautious about certain parts of the codebase and much more relaxed about others.

A "slot-free zone" refers to parts of the codebase that require strict human review. Without defining these zones, the codebase gets into seriously messy territory — the team had to rewrite their entire application a few times because of this. In practice, this means: any change to a migrations file must pass through a human review gate in CI.

Also treated as slot-free: all Slack content, documentation, CLAUDE.md, and skills files — all written by humans with significant care. The speaker used an analogy: if you had a new intern you could whisper to every morning before they sat down to work, you'd choose your words carefully. CLAUDE.md is exactly that — it's the information loaded into context every time an agent starts up, and it's worth refining obsessively.

Database migration files record every change script ever made to a database's structure. Execute them incorrectly or introduce inconsistencies, and at best you lose data — at worst, the entire application won't start and rollback becomes a nightmare. The special risk with these files is that AI-generated code can look logically sound while creating subtle conflicts with the existing data state — conflicts that often only surface in production. Marking them as "slot-free zones" and using CI to force human review is essentially inserting an extra human judgment checkpoint for "high-risk, low-tolerance" changes, preventing AI's confident output from bypassing the caution these changes deserve. CLAUDE.md is the agent context configuration file format introduced by Anthropic, where developers describe project context, coding conventions, prohibited actions, and other instructions that are automatically loaded each time an agent starts — effectively a permanent work brief for your AI assistant.

Principle 3: Feed the Beast — Centralize All Context

Conductor has an internal tool called CIA (Conductor Internal Agent) — a central database of everything happening across the entire organization. Whenever there's a new Slack message, a user reports a bug on Discord, or a team meeting gets recorded, CIA captures it and stores it in a Postgres database.

The "Feed the Beast" name comes from a simple insight: to make agents work efficiently inside a company, you need to give them as much context as possible about how your specific team operates. And the best way to do that is to create a centralized place where all information flows together. The speaker quoted a tweet that put it well: dump everything into a database, give the agent a SQL tool, and let it handle the rest — and it works surprisingly well.

Principle 4: Free-Range Agents — Give Them Room to Run

Give agents a sandbox that won't get shut down — a place where they can explore the codebase and tackle hard tasks, knowing they won't be killed when you close your laptop. As models get stronger, run longer, and multiply in number, keeping them trapped on your laptop is far less efficient than letting them roam freely.

The new version of Conductor shipping this week is built around cloud collaboration. Each workspace has a cloud icon at the top — click it and you can see information about the sandbox the agent is running in. Where tasks used to be built on top of Git work trees, they now run in cloud sandboxes, making them truly free-range agents.

The collaboration capabilities are even cooler. The speaker showed how, in the interface, he can see what team members like Caden, Lewis, Tywin, and Jackson are each working on, and click in to watch in real time. He jumped into Caden's workspace to review changes and left a comment — "Can you use tabs instead of spaces?" — which Caden could see and respond to in real time. The speaker argued that real-time collaboration is one of the most important interface shifts happening this year — one almost nobody is talking about. Great things have always been built by teams, not individuals. And the stronger the models get, the more ambitious the things you can build — which means you need more people and agents working together.

Cloud sandboxes also unlock an interesting capability: giving agents an API to spawn more agents. The speaker demonstrated an open claw called Lord Crandon, connected to the Conductor API. He sent a message from Telegram — "Create a new workspace for me and make all the buttons blue" — and Lord Crandon automatically created the workspace and got to work. Even when he's out and about, agents are doing the work for him.

Cloud sandboxes are a technical approach to running code and agents in isolated remote environments. Compared to local execution, the key advantages are: first, their lifecycle is independent of the user's device — closing your laptop or losing connectivity doesn't interrupt agent tasks; second, multiple team members can access the same sandbox environment simultaneously for genuine collaborative visibility; third, sandbox environments can be precisely snapshotted and reproduced, making agent behavior easier to debug. The "API to generate itself" the speaker mentions refers to letting an agent dynamically create new workspaces or spin up other agents by calling platform APIs — a form of meta-orchestration. Agents don't just execute tasks; they can expand their own execution resources on demand. This is an early manifestation of multi-agent systems evolving toward autonomous scheduling.

Principle 5: Orchestras, Not Factories

The theme of the broader conference was "software factories" — and the speaker admitted he hates that phrase, believing it's the wrong mental model for understanding these new tools. The word "factory" evokes automation. Automation has real benefits — it makes life more efficient, it makes everything produce more — but he doesn't want the future to be built on factories.

The future he wants is one that "feels human": standing in front of an orchestra, raising the baton — one sweep and a team of agents gets to work; another sweep and humans and agents weave together in collaboration; you can zoom in on the details when needed, but most of the time you can zoom out and survey the whole. He doesn't want a future of "managing agent swarms and pressing buttons like an assembly line foreman, squeezing agents for the next feature." The industry used the term "feature factories" a decade ago, and it turned out to be a dead end.

"I want my software to feel human, to feel crafted. I want to feel like I'm at the center of all of it." The speaker emphasized that because developers are literally building these tools with their own hands, they have a responsibility to make them human-friendly — to use words that excite people, that make them feel capable, in flow, having fun. He wants to feel like Steve Jobs designing the Mac with a team of brilliant humans and AI agents. Like standing in front of an orchestra.

Quick Reference: Five Principles

These five principles can be remembered with the acronym STCFO:

• Stay near the frontier — stay close to the cutting edge, but don't try to beat the market
• Try not to beat the market — don't over-optimize workflows without genuine alpha
• Create slot-free zones — establish strict human review areas for critical code
• Feed the beast — centralize all context to keep agents well-informed
• Orchestras, not factories — think of yourself as a conductor, not an assembly line supervisor

As agent capabilities evolve at breakneck speed, what determines how fast you build is no longer just the strength of any single tool — it's how well you orchestrate the collaboration between humans and agents. From centralizing context and deploying free-range cloud agents to enabling real-time team collaboration, this framework points toward a way of building that is both more human and more productive.