Meta se queda con el director de orquesta de los agentes de código
Meta ha comprado Conductor, una startup que se había ganado un lugar en el escritorio de miles de desarrolladores con una propuesta tan sencilla de enunciar como difícil de ejecutar: permitir que una sola persona ponga a trabajar varios agentes de programación al mismo tiempo, cada uno en su propia copia aislada del proyecto, y después revisar y fusionar lo que cada uno produce. La operación se conoció el 4 de noviembre de 2026. Los términos económicos no se hicieron públicos, pero el destino del equipo sí: sus integrantes, encabezados por el director ejecutivo Charlie Holtz y el director de tecnología Jackson de Campos, se incorporan a Meta Superintelligence Labs, la división con la que la compañía de Mark Zuckerberg concentra su apuesta más ambiciosa en inteligencia artificial.
La noticia llega en un momento en que la conversación sobre la programación asistida por IA ha cambiado de eje. Durante los dos últimos años, la pregunta dominante fue qué modelo escribía mejor código. Ahora la pregunta empieza a ser otra: cómo gestiona un desarrollador a varios agentes que trabajan en paralelo sin que el resultado se convierta en un caos de cambios contradictorios. Meta, con esta compra, deja claro que quiere tener una respuesta propia a esa pregunta.
Para los usuarios de Conductor, la noticia tiene una contracara inmediata. De acuerdo con la compañía, sus productos se irán cerrando de forma gradual en las próximas semanas y meses. Quienes habían construido su flujo de trabajo diario sobre la aplicación tendrán que buscar alternativas, una situación que vuelve a poner sobre la mesa un dilema conocido en la industria: el atractivo de las herramientas innovadoras de startups frente al riesgo de que desaparezcan de un día para otro.
Qué era Conductor y qué problema venía a resolver
Para entender por qué Conductor despertó el interés de uno de los gigantes tecnológicos más grandes del mundo, conviene recordar cómo ha evolucionado el trabajo con asistentes de código. La primera generación de herramientas se limitaba a sugerir líneas o funciones dentro del editor. La segunda generación, la de los agentes, dio un salto cualitativo: estos sistemas son capaces de leer un repositorio completo, planificar cambios, editar varios archivos, ejecutar pruebas y corregir sus propios errores con un grado considerable de autonomía.
Ese salto trajo consigo un problema nuevo. Un agente puede tardar minutos, a veces mucho más, en completar una tarea compleja. Mientras tanto, el desarrollador espera. La reacción natural de muchos profesionales fue abrir varias sesiones a la vez y repartir tareas: un agente arregla un error, otro escribe pruebas, un tercero explora una refactorización. El inconveniente es evidente para cualquiera que haya trabajado con control de versiones: si todos los agentes modifican la misma carpeta de trabajo, se pisan entre sí, sobrescriben archivos y generan conflictos difíciles de desenredar.
Conductor nació para resolver exactamente esa fricción. Su aplicación permitía lanzar varios agentes de programación de manera simultánea, asignando a cada uno un espacio de trabajo independiente basado en worktrees de Git. Cuando un agente terminaba, el desarrollador podía revisar sus cambios, compararlos con los de los demás y decidir qué fusionar en la rama principal. En la práctica, la herramienta convertía al programador en algo parecido a un jefe de proyecto que supervisa a un pequeño equipo de colaboradores automáticos.
Una de las claves de su adopción fue que no obligaba a elegir un proveedor. La aplicación era compatible con varios de los agentes más usados del mercado, entre ellos Claude Code, de Anthropic; Codex, de OpenAI; Cursor y OpenCode, además de otros. Esa neutralidad la convertía en una capa de coordinación por encima de los modelos, un punto estratégico en un mercado donde los desarrolladores cambian de herramienta con frecuencia según el tipo de tarea o la calidad de cada nueva versión.
Los worktrees de Git, una vieja función con un papel nuevo
El corazón técnico de Conductor no era una invención reciente. Los worktrees forman parte de Git desde hace años y permiten tener varios directorios de trabajo vinculados a un mismo repositorio, cada uno apuntando a una rama distinta. En lugar de clonar el proyecto varias veces, con el consiguiente gasto de espacio y la complejidad de mantener sincronizadas las copias, un worktree comparte el historial del repositorio y solo separa los archivos de trabajo.
Durante mucho tiempo, esta función fue una herramienta de nicho que usaban sobre todo desarrolladores avanzados para, por ejemplo, revisar una rama de corrección urgente sin interrumpir el trabajo en curso en otra. La llegada de los agentes le dio una relevancia inesperada. Si cada agente necesita un espacio donde editar archivos con libertad sin interferir con los demás, los worktrees ofrecen exactamente eso: copias aisladas del código que comparten un mismo origen y que pueden integrarse después mediante los mecanismos habituales de fusión.
Lo que aportaba Conductor era la capa de experiencia de usuario. Crear, nombrar, limpiar y supervisar worktrees a mano exige disciplina y conocimientos que no todos los desarrolladores tienen interiorizados. Multiplicar ese trabajo por cuatro, seis o diez agentes lo vuelve tedioso. La aplicación automatizaba el ciclo completo y ofrecía una vista centralizada del estado de cada agente, de modo que el desarrollador podía concentrarse en lo que realmente importa: decidir qué cambios merecen llegar al código principal.
Este detalle explica parte del atractivo del producto. No se trataba de un modelo de lenguaje nuevo ni de un agente más inteligente, sino de una pieza de infraestructura de flujo de trabajo. En un mercado saturado de anuncios sobre modelos cada vez más capaces, Conductor se posicionó en un lugar menos vistoso pero cada vez más necesario: la gestión del trabajo que esos modelos generan.
Del asistente único al ejército de agentes
La compra se entiende mejor a la luz de una tesis que gana adeptos en la industria. Según esa lectura, el futuro de la programación con inteligencia artificial no dependerá únicamente de que los agentes sean más listos, sino de que los desarrolladores puedan dirigir con comodidad a muchos de ellos al mismo tiempo. La metáfora que circula en el sector es la de los “ejércitos” de agentes: grupos de sistemas autónomos que se reparten tareas, trabajan en paralelo y entregan resultados que una persona revisa y combina. Quien quiera profundizar en los patrones de coordinación puede revisar nuestra guía de sistemas multiagente con LangGraph, MCP y A2A.
Esta visión cambia el perfil del trabajo del programador. Si hasta hace poco su labor principal era escribir código, en este escenario su valor se desplaza hacia la definición de tareas, la supervisión, la revisión y la integración. La orquestación de agentes de programación se convierte así en una habilidad profesional en sí misma, comparable a la que tiene un líder técnico que coordina a un equipo humano.
Charlie Holtz resumió la ambición del equipo al anunciar su incorporación a Meta. El director ejecutivo de Conductor explicó que trabajarán junto a Nat Friedman y Alexandr Wang en lo que describió como “la próxima interfaz”. La expresión es reveladora. No habla de un editor de código mejorado ni de un agente más potente, sino de una forma nueva de relacionarse con el software y con la propia inteligencia artificial, en la que la persona deja de teclear instrucciones una a una para pasar a dirigir procesos.
Los nombres mencionados por Holtz tampoco son casuales. Nat Friedman, exdirector ejecutivo de GitHub, conoce de primera mano el ecosistema de herramientas para desarrolladores y fue testigo del nacimiento de los asistentes de código a gran escala. Alexandr Wang, fundador de Scale AI, es una de las figuras centrales de la estrategia de inteligencia artificial de la compañía. Que el equipo de una startup relativamente joven vaya a trabajar directamente con ellos indica la importancia que Meta concede a esta línea de trabajo.
Una startup joven con tracción notable
Conductor no era un proyecto marginal. La compañía afirma en su sitio web que más de 100.000 personas utilizan su aplicación, una cifra relevante para una herramienta dirigida a un público técnico y especializado. Ese nivel de adopción sugiere que el problema que resolvía no era hipotético: muchos desarrolladores ya estaban trabajando con varios agentes y necesitaban una forma ordenada de hacerlo.
En marzo de 2026, la startup cerró una ronda de financiación Serie A de 22 millones de dólares, con la participación de las firmas de capital riesgo Spark Capital y Matrix. La operación se produjo apenas unos meses antes de la adquisición, lo que ilustra la velocidad a la que se mueve el mercado de herramientas para agentes. En otro contexto, una empresa recién capitalizada habría dedicado los años siguientes a crecer de forma independiente, ampliar su equipo y buscar un modelo de ingresos sostenible. En el actual, la presión competitiva entre los grandes laboratorios de inteligencia artificial acelera los plazos y convierte a las startups prometedoras en objetivos de compra tempranos.
Este patrón no es nuevo en la industria tecnológica, pero se ha intensificado con la carrera por la inteligencia artificial. Las grandes compañías disponen de recursos casi ilimitados para entrenar modelos, pero no siempre tienen la agilidad para detectar y construir los productos que los desarrolladores adoptan de forma orgánica. Comprar equipos que ya han demostrado esa capacidad resulta, en muchos casos, más rápido que replicar su trabajo desde cero.
Hay además un componente de talento difícil de cuantificar. Los equipos que han construido herramientas populares entre desarrolladores acumulan un conocimiento muy específico sobre cómo trabajan realmente los programadores, qué les frustra y qué están dispuestos a adoptar. Ese conocimiento, más que el código de la aplicación en sí, suele ser el activo que justifica este tipo de operaciones.
Por qué Meta quiere a Conductor
La estrategia de inteligencia artificial de Meta ha atravesado una transformación profunda en los últimos tiempos. La compañía, que durante años construyó su reputación en este campo con la familia de modelos abiertos Llama, reorganizó sus esfuerzos bajo el paraguas de Meta Superintelligence Labs, una división creada para competir de tú a tú con los laboratorios más avanzados del sector. La incorporación de figuras como Alexandr Wang y Nat Friedman formó parte de ese giro. La compra encaja con el ritmo de inversión que la compañía ya mostró al impulsar Muse y elevar su gasto previsto en IA.
En ese contexto, la compra de Conductor encaja en una necesidad concreta. Meta compite con OpenAI, Anthropic y Google en el desarrollo de modelos de frontera, pero en el terreno de las herramientas para programadores llega con desventaja frente a rivales que ya tienen productos consolidados. OpenAI tiene Codex; Anthropic, Claude Code; y otras compañías disponen de entornos de desarrollo con agentes integrados. Meta no contaba con un producto equivalente con tracción entre desarrolladores profesionales.
Adquirir Conductor no le da a Meta un agente propio, pero sí algo que puede resultar igual de valioso: un equipo con experiencia demostrada en diseñar la capa de coordinación que se sitúa por encima de los agentes. Si la tesis de los ejércitos de agentes se confirma, quien controle esa capa tendrá una posición privilegiada para decidir qué modelos se usan, cómo se combinan y qué experiencia vive el desarrollador.
También existe una lectura más amplia. La “próxima interfaz” a la que aludió Holtz no tiene por qué limitarse a la programación. La idea de que una persona dirija a varios agentes autónomos que trabajan en paralelo es aplicable a muchas otras tareas del conocimiento: análisis de datos, redacción, investigación o gestión de procesos. La programación es, en buena medida, el terreno de pruebas donde estas interfaces maduran primero, porque el código ofrece mecanismos claros para verificar resultados, como pruebas automáticas y revisiones de cambios. Lo aprendido allí puede trasladarse después a otros ámbitos.
Una semana de movimientos en la carrera por los agentes
La compra de Conductor no fue un hecho aislado. Durante la misma semana, OpenAI anunció la adquisición de Pierre Computer, una startup que trabajaba en infraestructura de control de versiones al estilo de Git pensada para Codex. Al mismo tiempo, Amazon Web Services lanzó Kiro bots, una nueva propuesta dentro de su oferta de herramientas basadas en agentes. La coincidencia en el calendario refleja la intensidad de la competencia en este segmento.
El movimiento de OpenAI resulta especialmente significativo cuando se compara con el de Meta. Ambas compañías parecen haber llegado a una conclusión similar: el control de versiones, la gestión de ramas y la integración de cambios son piezas críticas cuando el código lo producen agentes en paralelo. Git fue diseñado para coordinar el trabajo de muchas personas sobre un mismo proyecto; ahora debe adaptarse a un escenario en el que buena parte de esos colaboradores son sistemas automáticos que trabajan a una velocidad muy superior.
Ese desplazamiento tiene implicaciones prácticas. Los agentes pueden generar muchas ramas y cambios en poco tiempo, y los flujos tradicionales de revisión, pensados para el ritmo humano, se vuelven un cuello de botella. Las empresas que logren resolver esa fricción, ya sea con interfaces mejores para revisar cambios o con infraestructura de versiones adaptada a los agentes, tendrán una ventaja competitiva clara.
El precedente de Ona y la batalla por el entorno de ejecución
Unos meses antes, en junio, OpenAI ya había anunciado la compra de Ona, una compañía especializada en ejecutar agentes dentro de entornos aislados en la nube, conocidos como sandboxes. La lógica de aquella operación complementa la de Conductor desde otro ángulo. Si Conductor aislaba a los agentes en la máquina del desarrollador mediante worktrees, Ona proponía hacerlo en servidores remotos, donde cada agente dispone de un entorno propio, controlado y desechable.
Las dos aproximaciones responden a la misma necesidad de fondo: los agentes necesitan espacio para trabajar sin interferir entre sí ni con el sistema del usuario. El aislamiento local tiene ventajas de inmediatez y control, porque el desarrollador ve los cambios en su propio equipo y puede intervenir en cualquier momento. El aislamiento en la nube, en cambio, permite escalar a muchos más agentes de los que soportaría un portátil, reduce riesgos de seguridad al separar la ejecución del entorno personal y facilita tareas de larga duración que siguen funcionando aunque el usuario cierre su equipo.
No es descabellado pensar que el futuro combine ambos modelos. Un desarrollador podría lanzar algunos agentes en local para tareas rápidas e interactivas y delegar otros a la nube para trabajos más largos, revisando después todo desde una misma interfaz. La sucesión de compras de los últimos meses sugiere que los grandes laboratorios están reuniendo las piezas necesarias para ofrecer ese tipo de experiencia integrada.
Qué pasa con los usuarios ahora que el producto se cierra
Para las más de 100.000 personas que, según la compañía, utilizan Conductor, la parte práctica de la noticia es menos estimulante que la estratégica. Los productos se irán apagando de forma progresiva en las próximas semanas y meses, sin que se haya comunicado una fecha exacta para el cierre definitivo. Este tipo de transición es habitual en las adquisiciones centradas en el equipo, en las que el comprador está más interesado en las personas y su conocimiento que en mantener vivo el producto original.
La primera recomendación para los usuarios es sencilla pero importante: no esperar al último momento. Conviene revisar qué worktrees y ramas siguen activos, fusionar o archivar el trabajo pendiente y asegurarse de que ningún cambio importante quede atrapado en un espacio gestionado por la aplicación. Dado que la herramienta se apoyaba en mecanismos estándar de Git, el trabajo realizado vive en el propio repositorio, lo que reduce el riesgo de pérdida de información. Aun así, es prudente comprobar el estado de cada rama antes de que la aplicación deje de funcionar.
La segunda recomendación es documentar el flujo de trabajo actual. Muchos equipos adoptan herramientas como Conductor de forma orgánica, sin dejar por escrito cómo las usan. Describir qué tipo de tareas se asignaban a cada agente, cómo se revisaban los cambios y qué criterios se aplicaban para fusionarlos facilita la migración a otra solución y evita que el conocimiento se pierda con la herramienta.
Alternativas para seguir trabajando con varios agentes
La buena noticia para los usuarios es que la técnica en la que se basaba Conductor no desaparece con el producto. Los worktrees siguen siendo una función nativa de Git, disponible para cualquiera que quiera gestionarlos manualmente. Un desarrollador con cierta soltura en la terminal puede crear un worktree por tarea, lanzar en cada uno el agente de su preferencia y revisar después los cambios con las herramientas habituales de comparación y fusión. El proceso es más laborioso, pero perfectamente viable. Un ejemplo práctico de este enfoque se explica en cómo construir una fábrica de software con Claude Code y subagentes.
Para quienes prefieran una experiencia más cómoda, existen varias rutas genéricas. La primera es combinar los propios agentes de línea de comandos con multiplexores de terminal, que permiten mantener varias sesiones abiertas y visibles a la vez. La segunda es recurrir a las funciones de trabajo en paralelo que algunos agentes y entornos de desarrollo han empezado a incorporar de forma nativa, una tendencia que probablemente se acelere tras esta compra. La tercera es explorar las opciones basadas en la nube, en las que los agentes se ejecutan en entornos remotos y el desarrollador revisa los resultados desde una interfaz web o mediante solicitudes de cambios.
También es razonable esperar que surjan nuevas herramientas independientes para ocupar el hueco que deja Conductor. Cuando un producto con una base de usuarios considerable desaparece, el mercado suele reaccionar con rapidez, y la demanda ya está demostrada. Al evaluar cualquier alternativa, conviene fijarse en tres aspectos: que respete los flujos estándar de Git, que sea compatible con varios agentes en lugar de atar al usuario a uno solo y que permita exportar o recuperar el trabajo con facilidad si algún día también deja de existir.
Por último, los equipos pueden aprovechar la transición para preguntarse si necesitan realmente una herramienta dedicada o si les basta con unas convenciones claras. En equipos pequeños, una guía interna sobre cómo nombrar ramas, cuántos agentes ejecutar a la vez y cómo revisar sus cambios puede ofrecer buena parte del valor con menos dependencias externas.
El riesgo de depender de una startup en la cadena de herramientas
El cierre de Conductor ilustra un fenómeno que los equipos de ingeniería conocen bien. Las startups suelen ser las primeras en detectar necesidades nuevas y en ofrecer soluciones elegantes, pero su futuro es incierto. Pueden quedarse sin financiación, cambiar de rumbo o, como en este caso, ser adquiridas por una compañía que decide integrar al equipo y cerrar el producto. La dependencia de herramientas de startups es, por tanto, una decisión que conviene tomar con los ojos abiertos.
Eso no significa que haya que evitarlas. Buena parte de la innovación en herramientas para desarrolladores procede precisamente de empresas pequeñas, y renunciar a ellas supondría perder ventajas competitivas reales. La clave está en gestionar el riesgo. Las herramientas que se apoyan en estándares abiertos, como era el caso de Conductor con los worktrees de Git, son menos peligrosas que aquellas que guardan el trabajo en formatos propietarios o en servicios de los que no se puede extraer la información.
Una práctica recomendable es mantener siempre un plan de salida. Antes de adoptar una herramienta en un flujo crítico, los equipos pueden preguntarse qué harían si mañana dejara de funcionar, cuánto tardarían en sustituirla y qué conocimiento o datos perderían. Si la respuesta es tranquilizadora, la dependencia es asumible. Si no lo es, conviene construir alguna capa de protección, como copias periódicas, documentación del proceso o una alternativa probada en reserva.
El caso también invita a reflexionar sobre la concentración del mercado. Cada vez que una gran compañía absorbe una herramienta independiente y compatible con varios proveedores, el ecosistema pierde una opción neutral. Si la tendencia continúa, los desarrolladores podrían encontrarse con un panorama en el que cada laboratorio ofrece su propia capa de orquestación, optimizada para sus propios modelos. La neutralidad que valoraban los usuarios de Conductor podría volverse más difícil de encontrar.
Los retos técnicos de la orquestación multiagente
Más allá de la operación empresarial, la compra pone el foco en un campo técnico que todavía está lejos de estar resuelto. Ejecutar varios agentes a la vez parece sencillo sobre el papel, pero en la práctica plantea desafíos considerables que cualquier herramienta, sea de Meta o de otro actor, tendrá que afrontar.
El primero es el de los conflictos. Aunque cada agente trabaje en su propio worktree, sus cambios acabarán confluyendo en la misma base de código. Si dos agentes modifican la misma función con enfoques distintos, alguien tendrá que decidir cuál prevalece o cómo combinarlos. Cuantos más agentes trabajen en paralelo, mayor es la probabilidad de que esto ocurra y más tiempo dedica el desarrollador a resolver choques en lugar de avanzar.
El segundo reto es la carga de revisión. Un agente puede producir en minutos una cantidad de cambios que a una persona le llevaría horas escribir, pero revisarlos sigue requiriendo atención humana. La revisión humana del código generado se convierte en el verdadero límite de productividad. Si un desarrollador lanza diez agentes pero solo puede revisar con rigor el trabajo de tres, el resto se acumula o, peor aún, se fusiona sin el escrutinio necesario.
El tercer desafío es el contexto. Cada agente trabaja con una visión parcial del proyecto y de lo que están haciendo los demás. Sin mecanismos de coordinación, pueden duplicar esfuerzos o tomar decisiones de diseño incompatibles. Las herramientas de orquestación más avanzadas tendrán que ofrecer formas de compartir contexto entre agentes, asignar tareas con límites claros y detectar solapamientos antes de que se conviertan en problemas.
Por último, están los costes y la seguridad. Ejecutar muchos agentes en paralelo multiplica el consumo de recursos de cómputo y, en el caso de servicios de pago por uso, la factura. Además, cada agente con capacidad para ejecutar comandos y modificar archivos es una superficie potencial de riesgo. El aislamiento mediante worktrees protege frente a interferencias entre agentes, pero no sustituye a las medidas de seguridad sobre qué puede hacer cada uno en el sistema.
Situación actual de la operación
A fecha de esta publicación, la adquisición de Conductor por parte de Meta está confirmada, aunque las condiciones económicas permanecen sin revelar. El equipo de la startup, con Charlie Holtz y Jackson de Campos a la cabeza, se integra en Meta Superintelligence Labs, donde trabajará con Nat Friedman y Alexandr Wang en el desarrollo de lo que Holtz denominó “la próxima interfaz”. Meta no ha detallado públicamente qué productos concretos saldrán de esta colaboración ni en qué plazo.
En paralelo, la aplicación de Conductor sigue disponible para sus usuarios mientras se completa el cierre progresivo anunciado, que se extenderá a lo largo de las próximas semanas y meses. No se ha comunicado una fecha precisa para el apagado definitivo, por lo que los usuarios deberían planificar su migración con antelación.
El contexto competitivo sigue en ebullición. OpenAI acumula en pocos meses las compras de Ona y Pierre Computer, mientras AWS amplía su catálogo con Kiro bots. Todo apunta a que la gestión de múltiples agentes, el control de versiones adaptado a la IA y los entornos de ejecución aislados serán algunos de los frentes más disputados de la industria en los próximos meses.
Lecciones para desarrolladores y equipos técnicos
La primera lección es que las habilidades del programador están cambiando. Saber escribir código sigue siendo fundamental, pero cada vez pesa más la capacidad de dividir un problema en tareas bien delimitadas, describirlas con precisión para que un agente las ejecute y evaluar con criterio los resultados. Quienes desarrollen esas competencias estarán mejor preparados para un entorno en el que trabajar con varios agentes sea la norma. Para quienes quieran entender cómo se construyen aplicaciones sólidas sobre modelos fundacionales, el libro AI Engineering, de Chip Huyen ofrece un marco completo y muy práctico.
La segunda lección es técnica: dominar Git a fondo vuelve a ser un diferenciador. Funciones como los worktrees, el rebase o la resolución de conflictos, que muchos desarrolladores usaban de forma superficial, adquieren un papel central cuando el volumen de cambios se multiplica. Las herramientas de orquestación pueden ocultar parte de esa complejidad, pero entender lo que ocurre por debajo permite trabajar con más seguridad y recuperarse cuando algo falla.
La tercera lección tiene que ver con la elección de herramientas. La desaparición de Conductor recuerda que conviene preferir soluciones basadas en estándares abiertos, compatibles con varios proveedores y de las que resulte sencillo salir. La comodidad de una aplicación pulida no debería ocultar la pregunta sobre qué ocurre si deja de existir.
La cuarta lección es organizativa. Los equipos que adopten flujos multiagente necesitan acordar reglas claras: cuántos agentes pueden ejecutarse en paralelo sobre un mismo proyecto, quién revisa sus cambios, qué pruebas deben superar antes de fusionarse y cómo se documentan las decisiones. Sin esas reglas, la promesa de productividad puede convertirse en una acumulación de cambios difíciles de mantener.
La quinta y última lección es estratégica. La compra de Conductor confirma que los grandes laboratorios ven en la experiencia del desarrollador un campo de batalla tan importante como la calidad de los modelos. Para los profesionales, esto significa que las herramientas evolucionarán con rapidez y que conviene mantener una actitud de experimentación constante, probando nuevas formas de trabajo sin atarse en exceso a ninguna.
Conclusiones
La adquisición de Conductor por parte de Meta es mucho más que la compra de una startup prometedora. Representa una apuesta explícita por una idea que gana terreno en la industria: el próximo salto en la programación asistida por inteligencia artificial no vendrá solo de agentes más capaces, sino de interfaces que permitan a una persona dirigir a muchos de ellos a la vez de manera ordenada y segura.
Conductor demostró, con más de 100.000 usuarios según la propia compañía y una Serie A de 22 millones de dólares en marzo de 2026, que existe una demanda real para esa capa de coordinación. Su apuesta por los worktrees de Git y por la compatibilidad con agentes como Claude Code, Codex, Cursor y OpenCode la convirtió en una pieza neutral dentro de un ecosistema fragmentado. Esa neutralidad es precisamente lo que se pierde con su cierre progresivo.
Para Meta, la operación aporta un equipo con experiencia en un terreno donde llegaba con desventaja frente a OpenAI y Anthropic, y refuerza la ambición de Meta Superintelligence Labs de construir “la próxima interfaz”. Para el sector, la coincidencia con las compras de Ona y Pierre Computer por parte de OpenAI y con el lanzamiento de Kiro bots por AWS confirma que la orquestación multiagente se ha convertido en un frente competitivo de primer orden.
Para los desarrolladores, el mensaje es doble. Por un lado, conviene prepararse para un modelo de trabajo en el que supervisar, revisar e integrar el trabajo de varios agentes será tan importante como escribir código. Por otro, el cierre de Conductor recuerda la importancia de elegir herramientas sobre estándares abiertos, mantener planes de salida y no depender en exceso de un único proveedor. La técnica sobrevive al producto; la lección, también.