Metimos IA en toda la empresa: lecciones aprendidas

En 1968, un estudio fundacional encontró algo que moldearía Silicon Valley durante décadas: los mejores ingenieros de software eran dramáticamente más productivos que sus pares. Desde entonces, toda empresa de tecnología ha estado cazando a esos individuos raros capaces de generar resultados extraordinarios.

Volviendo de las vacaciones en enero, entusiasmados por los avances de los modelos de frontera, nuestro equipo de ingeniería empezó a correr agentes en paralelo con git worktrees, Claude Code y Codex. En algunas tareas, lograban 5 veces más.

Eso abrió una pregunta más grande: si los agentes podían hacer a los ingenieros tan productivos en un mes, ¿qué haría falta para llevar a todo Sierra hasta ahí? Armamos un equipo de aceleración de IA de seis personas para averiguarlo. Este artículo explica qué construimos, y qué aprendimos en el proceso.

1. Agente, en singular

Empezamos con un grupo de agentes específicos por rol: un agente de soporte (PINE), un analista de datos (Pinewood), un ingeniero (Pinecone), y un agente de ventas (Reggie Jr). Un agente por rol puede parecer intuitivo, pero fracasó en la práctica.

Superficialmente, el problema era la carga sobre los empleados, que tenían que recordar qué agente hacía qué. Nuestro amor por los nombres con temática de pinos no ayudó. Pero el problema más profundo era estructural: el trabajo más importante ocurre entre equipos, no dentro de ellos.

En el fondo, las empresas son una colección de trabajos por hacer. Tomemos el lanzamiento de un producto. Involucra equipos técnicos además de ventas, marketing, legal y operaciones. Los departamentos existen porque un equipo o una persona no puede hacer todas las partes del trabajo. La IA cambia eso, porque cada vez puede completar el trabajo de punta a punta.

Así que colapsamos todos esos agentes específicos por rol en Pinecone: un único agente con un solo handle de Slack, una sola URL, y un hilo ininterrumpido desde la pregunta hasta el resultado terminado. Pinecone decide de qué sistemas traer información y qué hacer con cada pedido, así los empleados no tienen que hacerlo. Eso es técnicamente difícil, pero ese es justamente el punto de la IA: la tecnología absorbe la complejidad, no el empleado.

Es una lección que ya habíamos aprendido con nuestra plataforma. Los agentes construidos sobre Sierra son de servicio completo: un agente puede manejar todo, desde el descubrimiento de producto hasta la configuración de cuenta, resolución de problemas, facturación y más. No es un “presione uno para ventas, presione dos para soporte” como un viejo IVR.

Colapsar todo en un solo agente te acerca mucho más a donde está el valor real en una empresa: los trabajos por hacer. Cada mejora beneficia a todo el negocio, así que todos mejoran, más rápido.

2. Proactivo, no reactivo

La mayoría del trabajo no se completa en una sola sesión. Se despliega a lo largo de días, semanas o incluso meses, mientras los equipos aprenden, las prioridades cambian y surge nueva información. Un agente que aparece cuando se le pide y desaparece cuando termina la sesión sirve hasta cierto punto. Pinecone persiste a través de todo el proceso, llevando el contexto hacia adelante y retomando el hilo, hasta que el trabajo —no solo el pedido individual— está terminado.

La persistencia también hace que Pinecone sea proactivo. En vez de esperar a que se le pida algo, puede actuar cuando el siguiente paso está listo: un webhook se dispara sobre un artefacto, una tarea llega a Linear, entra una revisión. Reúne contexto y hace una primera pasada, trayendo a las personas cuando se necesita su criterio. Las notas de preparación están listas antes de una reunión. Los resúmenes de entrevistas están redactados antes de que te sientes a agregar tus puntuaciones. Las revisiones llegan con resúmenes, riesgos clave y comentarios sugeridos. El objetivo no es más notificaciones. Es que llegue menos trabajo sin terminar.

Todavía no lo tenemos completamente resuelto —la mayoría de las sesiones siguen empezando con un pedido humano— pero invertir esa relación, para que los agentes le pidan cosas a los humanos cuando hace falta, es hacia donde nos lleva la persistencia.

3. El contexto de negocio es el cuello de botella, no la inteligencia

El cuello de botella con la IA solía ser la inteligencia bruta: si un modelo era lo suficientemente inteligente. Hoy, los modelos de frontera son lo suficientemente capaces para la mayoría de las necesidades de negocio. Así que el cuello de botella se movió al contexto: lo específico de tu empresa, tus flujos de trabajo, tu historia, las decisiones de criterio que no aparecen en ningún set de entrenamiento.

En enero, dos personas de nuestro equipo armaron con lo que tenían a mano un agente analista de datos usando Claude Code y Opus 4.6, conectado a nuestros sistemas a través de Model Context Protocol (MCP) y herramientas de línea de comandos. Sin mucha guía adicional, podía investigar un problema de cliente a través de Slack, GitHub, ClickHouse, Salesforce y PagerDuty en minutos. Un trabajo que antes consumía una tarde se convirtió en el primer paso del debugging y la respuesta a incidentes.

El mismo patrón se extiende mucho más allá del debugging. Un agente con contexto completo puede preparar una reunión con un cliente, investigar una cuenta, revisar un contrato o un RFP, rastrear una decisión de producto, y convertir trabajo disperso en un artefacto terminado. Por supuesto, dar a un agente acceso a todo ese contexto introduce un problema nuevo. Un agente sin restricciones es un riesgo enorme de seguridad y privacidad. Nuestro MCP Gateway resuelve esto: Pinecone hereda el acceso de cada empleado, aplica políticas en cada llamada a herramientas, aísla los datos de clientes, y deja un rastro de auditoría.

Pinecone está construido sobre Claude Code y Codex. Sus mejoras frecuentes son un viento a favor, pero el estado del arte cambia constantemente: un modelo puede ser mejor para planificar, otro para programar, otro para redactar. Ser dueños de la capa por encima de los modelos nos permite enrutar cada tarea al modelo correcto, tener respaldo durante caídas, y gestionar el costo, evitando quedar a merced de un solo proveedor. Pero la ventaja duradera no es ser dueño del modelo subyacente. Es ser dueño del contexto, los flujos de trabajo y la capa de enrutamiento que hacen que cada modelo sea más útil.

También estamos experimentando con dejar que Pinecone “sueñe”: reflexionando sobre el trabajo de cada día y proponiendo mejoras a sus propias habilidades. Con el tiempo, esa es la diferencia entre un agente que simplemente trabaja para Sierra y uno que aprende de Sierra.

4. El agente es la interfaz, el sistema de registro es el backend

Cada pieza de trabajo produce algo concreto, un artefacto. Los agentes de código encontraron el suyo primero: el pull request. Cada otro departamento tiene su equivalente propio: una historia de cliente, un contrato, un cuestionario de RFP, una presentación, una evaluación de desempeño.

Los artefactos son tanto la entrada como la salida. Le dan a los agentes el contexto que necesitan para hacer el trabajo, y son donde pertenece el trabajo terminado. Pedile a Pinecone que ajuste una presentación, y la presentación misma vuelve actualizada, no un mensaje de chat contándote qué cambiar.

Descubrimos que lo mejor es trabajar con tus sistemas de registro existentes, no reemplazarlos. GitHub guarda el PR, Salesforce guarda la cuenta, y Linear guarda el issue: el agente es la capa que los atraviesa.

Reemplazar esos sistemas significa recrear décadas de software maduro. Peor aún, divide a la empresa en dos: personas que trabajan a través del agente y personas que trabajan directamente en las herramientas originales, cada una con su propia versión de la verdad. Nuestra apuesta es que esos productos se vuelven cada vez más como backends con el tiempo, con el agente como interfaz principal.

5. Resultados, no solo actividad

Desde el primer commit de Pinecone en marzo, corrió más de 75.000 sesiones para más de 600 personas. Hoy, el 70% de nuestros PRs se abren a través de él, mientras cientos de automatizaciones manejan silenciosamente trabajo que nadie pidió explícitamente.

Números así son tentadores para liderar el relato, y al principio son lo correcto para monitorear: son evidencia de que algo se está usando de verdad, no juntando polvo en una diapositiva de roadmap. Pero las sesiones corridas y las llamadas a herramientas son actividad, no resultado. Un equipo puede inflar artificialmente un gráfico de adopción que se ve impresionante sin que nada río abajo mejore realmente: la misma cantidad de errores, los mismos tiempos de ciclo, solo con más IA involucrada en producirlos.

Así que el uso de tokens es un buen lugar para empezar. Los equipos necesitan formar el hábito de usar la herramienta antes de poder medir si funciona. Pero no es donde está el valor, y no queremos que sea donde termina la historia. La pregunta que estamos tratando de aprender a hacer mejor no es cuánto hizo un agente, sino qué cambió realmente por él: si un trato cerró más rápido, si el problema de un cliente se resolvió al primer intento, si alguien recuperó su noche en vez de terminar una revisión hasta tarde.

Todavía no tenemos una buena forma de medir eso. Las sesiones y las llamadas a herramientas son simplemente más fáciles de contar. Pero esa brecha —entre lo que podemos medir hoy y lo que realmente nos importa— es lo próximo que estamos construyendo.

Aquel estudio de 1968 encontró una brecha de 10 veces entre los mejores y el resto, y durante cincuenta años, la única respuesta fue salir a cazar a esas personas excepcionales. Ahora hay una mejor: darle a todos un agente para que tengan las ventajas de los pocos. El objetivo no es solo hacer más. Es darle a la gente más tiempo para el trabajo que solo las personas pueden hacer: criterio, gusto, creatividad y construir relaciones.

Adaptación del artículo original de Neil Rahilly, “AI-pilling our company: lessons learned”, publicado en el blog de Sierra.