Meta has bought Conductor, the startup whose app lets developers run several coding agents in parallel (InfoWorld has the details). Congratulations to the team, genuinely: building something good enough for Meta to want it is no small feat. But if you’re one of Conductor’s users, the small print is less cheerful. New registrations and downloads have stopped, the cloud service shuts down on 20 November, after which customer cloud data starts being deleted, and the desktop app gets model updates and critical fixes until early 2027 before it winds down too.

That’s about two weeks’ notice for the cloud bit. Two weeks! I’ve had longer notice periods from a gym membership 🙂

Your Agent Tooling Is Now a Dependency

Here’s the thing: a year or so ago, the AI tools on a developer’s laptop were personal preferences. Some people liked one editor plugin, others liked another, and if a tool disappeared you shrugged and installed the next one. That’s no longer the case. Tools like Conductor sit right in the middle of how work gets done: they hold the task history, the agent configurations, the prompts that took weeks to tune, sometimes the context about why a change was made. When a tool like that vanishes, it takes a chunk of your engineering process with it.

And the AI tooling market right now is a buyers’ market for the giants. Small, clever teams build the interesting tools, and big companies with deep pockets buy them for the people and the ideas, not for the existing customer base. I’d venture to say we’ll see a lot more of these “great news for us, a migration project for you” announcements over the next year, and quite likely in tools your team relies on.

What I’d Do as a CTO This Week

I wrote recently about being able to switch AI model providers quickly; this is the same problem one layer up, in the tooling around the models. Point being, the same discipline applies:

• Know what you’re using. Ask your engineers which agent tools they actually rely on day to day. You might be surprised; I usually am when I ask the companies I advise.
• Keep the valuable bits in your own repo. Prompts, agent instructions, skills, task specs: they belong in version control, next to the code, in plain text. If they only live inside a vendor’s cloud, you don’t own them, you rent them.
• Prefer tools that work on open formats and open protocols. MCP servers, Markdown instructions and standard git workflows survive an acquisition. Proprietary workspaces don’t.
• Have an exit plan before you need it. For every tool that holds your team’s process, write down (in a paragraph, no need for a 30-page document) what you’d move to and how long it would take.

The Bigger Picture

The thing that made Conductor interesting in the first place is worth noting too: running several agents in parallel, with a human orchestrating them, is becoming normal. I believe the future of software engineering is a “lights out” setup, where people write specs and agents write, test and ship the code. If that’s where we’re heading (and I’m convinced it is), then the orchestration layer is the factory floor, and you really don’t want your factory floor to be something that can be switched off with two weeks’ notice.

Don’t get me wrong, I’m not saying “build everything yourself”. Use the good tools, by all means, they’re what make small teams so fast nowadays. Just make sure the knowledge they hold stays yours, so that when the acquisition email lands (and it will), it’s an afternoon’s work to move on rather than a quarter’s.

Moral of the story: the agents are replaceable, the tools are replaceable, but your specs and your process aren’t. Keep those where nobody can buy them out from under you.