OpenAI acaba de meter un directorio de plugins en Codex: Slack, Notion, Figma, Gmail, Google Drive, MCP… La versión 0.117.0 lo vende como un “workflow de primera clase”, no como un truco más del autocompletado. Yo lo leo distinto: admiten en voz alta que el código ya no es el cuello de botella; el cuello de botella es que el agente vive aislado del resto del trabajo.
Si llevas un tiempo probando agentes, seguro que te suena el patrón. Abres el IDE, lanzas una tarea, copias el diff, lo pegas en Linear, vuelves al chat, adjuntas un PNG de Figma que alguien te pasó por Slack, y a mitad de camino pierdes el hilo. Codex con plugins intenta cerrar ese circuito sin que tú seas el pegamento humano. Unite.AI recoge que la integración funciona en la app de escritorio, la CLI y las extensiones de IDE, con marketplaces locales por repo y por usuario vía marketplace.json. Suena bien. Demasiado bien si miras lo que pasa en el resto del ecosistema.
Más conectores, mismo problema de fondo
El mercado no va hacia “un agente que lo hace todo”, va hacia “cinco agentes que no se hablan”. JetBrains lo dice sin rodeos al lanzar Air en preview público: cada agente en una herramienta distinta, contexto distinto, cero entendimiento estructural del código. Air no compite con Codex en generar funciones; compite en orquestar Codex, Claude Agent, Gemini CLI y Junie en un mismo entorno, con Agent Client Protocol y ejecución en sandbox en camino.
Ahí está la grieta que el marketplace de OpenAI no tapa. Puedes instalar el plugin de Slack en Codex y pedirle que lea un hilo, pero si mañana tu jefe te obliga a usar Gemini CLI en un proyecto legacy y Claude en otro, vuelves a ser tú quien mantiene la coherencia. Los plugins arreglan el last mile hacia apps de productividad; no arreglan la torre de Babel de modelos, precios y políticas de datos que ya tienes en la empresa.
Y mientras tanto Google empuja otra narrativa: “vibe coding” en AI Studio, Antigravity, Firebase detrás, Next.js en el menú, secretos guardados, despliegue a Antigravity con un clic. Es el camino opuesto al plugin suelto: un jardín amurallado donde el agente entiende el proyecto entero porque Google controla el stack. Business Insider cuenta que por dentro usan “Agent Smith”, un agente asíncrono tan demandado que tuvieron que restringir el acceso. Traducción: cuando el agente deja de ser un juguete del desarrollador y pasa a ser infraestructura, el cuello de botella pasa a ser capacidad y gobernanza, no falta de integración con Gmail.
Lo que sí está madurando: agentes internos, no marketplaces
Fuera del ruido comercial, las organizaciones grandes están convergiendo en otro patrón. LangChain publicó Open SWE justo con esa tesis: Stripe (Minions), Ramp (Inspect), Coinbase (Cloudbot) construyeron agentes internos que viven en Slack, Linear y GitHub, con sandboxes aisladas y subagentes, no en un marketplace de terceros. No es casualidad. Un plugin curado en el directorio de Codex te da velocidad el primer día; un framework interno te da auditoría, límites de permisos y la posibilidad de decir “este agente no toca producción”.
OpenAI presume cifras —1,6 millones de usuarios activos semanales en Codex, uso de tokens multiplicado— y clientes enterprise en la foto. Yo no discuto la tracción; discuto la historia que venden al mismo tiempo. Si el valor está en conectar con Notion y Figma, estás compitiendo con el flujo de trabajo del conocimiento worker. Si el valor está en generar código de calidad en tu repo, los plugins son un analgésico. Las empresas que ya han quemado dinero en pilotos saben cuál de los dos dolores les despierta a las tres de la mañana.
Qué miraría yo antes de instalar nada
Primero, quién guarda el contexto cuando el agente lee Slack y tu repositorio. ¿Queda en el historial del chat de Codex? ¿En el workspace de OpenAI? ¿Puedes borrarlo por proyecto?
Segundo, qué pasa cuando el plugin falla. Un conector a Drive que devuelve un extracto incompleto puede generar un parche que compila y rompe negocio. Sin trazabilidad del dato de entrada, el diff es teatro.
Tercero, lock-in entre agentes. Air te dice que cambiar de Codex a Gemini CLI debería ser natural; la realidad en muchas pymes es una suscripción por seat aquí, otra allí, y nadie con tiempo de unificar prompts. Los plugins de Codex profundizan en el ecosistema OpenAI justo cuando JetBrains apuesta a ser agnóstico.
Cuarto, async vs pair programming. Agent Smith y los agentes internos van a tareas en background; Codex en IDE sigue siendo mayoritariamente síncrono. Mezclar ambos modelos en un mismo equipo sin reglas claras es cómo acabas con tres PRs abiertos que nadie revisa porque “el agente aún está pensando”.
En mi experiencia, el equipo que gana no es el que tiene más plugins instalados, sino el que define dónde termina la responsabilidad humana. Un marketplace bonito no sustituye eso; lo hace más fácil de posponer.
OpenAI publicará “muy pronto” el self-serve en el directorio oficial. Cuando eso pase, vendrá la ola de plugins cutres, MCP opacos y conectores que piden permisos absurdos. Igual que pasó con las extensiones de Chrome. Si tu agencia o tu departamento web no tiene una lista blanca de integraciones antes de septiembre, llegarás tarde otra vez —perdón, otra vez—.
¿Instalaría yo el plugin de Slack en Codex? Depende. Si tu flujo real ya vive en Slack y revisáis diffs allí, tiene sentido probarlo. Si lo que te falla es que cada desarrollador usa un agente distinto y nadie comparte contexto de arquitectura, el marketplace es un parche de marketing sobre un problema organizativo. Las piezas que más me interesan ahora mismo son Air por agnosticismo, Open SWE por patrones internos replicables, y la pregunta incómoda de Google: ¿quieres que tu “vibe coding” termine en su nube o en la tuya?
Si mañana tu proveedor de agentes te ofreciera conectar Slack, Jira y Figma gratis pero solo pudieras usar su modelo —sin exportar historial de decisiones técnicas—, ¿seguirías llamándolo productividad o lo llamarías dependencia?