El 13 de octubre, DXC Technology confirmó algo que llevaba meses viendo venir en cualquier conversación sobre agentes de IA en empresas grandes: su plataforma de agentes para operaciones de TI, construida sobre LangChain y LangGraph, ya está en producción y escalando a 125 entornos de clientes en industrias reguladas (banca, seguros, telecomunicaciones). Los números que publicaron son de los que te hacen releer el comunicado dos veces.
Qué anunciaron exactamente
La plataforma se llama OASIS. DXC es una de las consultoras de TI más grandes del mundo (factura más de 12 mil millones de dólares al año), así que cuando dice que algo ya corre en producción en 125 clientes, no habla de un piloto de laboratorio. Según el comunicado, los incidentes de sistema de archivos que antes tomaban entre 53 y 90 minutos en resolverse ahora se resuelven en 3 a 6 minutos. Los problemas de rendimiento de base de datos bajaron de 2-3 horas a 5-12 minutos. Y la gestión de problemas complejos, la que normalmente se arrastra 2 a 6 días pasando por un comité de cambios, ahora toma entre 8 y 10 minutos. DXC también confirmó que está licenciando LangSmith, la plataforma de observabilidad de LangChain, para evaluar y monitorear cada agente que corre en producción.
Por qué la arquitectura importa más que el modelo
Lo interesante acá no es qué modelo de lenguaje usan por debajo. Es cómo organizaron el sistema. LangGraph les da control de flujo: pueden decidir con precisión en qué paso un agente actúa solo y en cuál se detiene a esperar la aprobación de una persona. Eso es justo lo que separa un prototipo que impresiona en una demo de un sistema que corre de verdad en un banco sin que nadie pierda el sueño por las noches.
- ▸Agentes especializados por dominio (base de datos, redes, aplicaciones) que investigan en paralelo, no uno solo que intenta saberlo todo.
- ▸Trazabilidad de cada paso del razonamiento, no solo del resultado final, para poder auditar y depurar cuando algo sale mal.
- ▸Un punto de parada explícito donde el agente cede el control a una persona cuando la decisión tiene riesgo o costo alto.
- ▸Memoria compartida entre agentes dentro de un mismo incidente, para que no repitan el mismo diagnóstico tres veces.
Lo que el comunicado no dice: diseñar esos puntos de parada toma más tiempo que escribir los prompts. La mayoría de equipos que conozco subestima esa parte y termina con un agente que o pide permiso para todo, o no pide permiso para nada.
Esos números importan porque en operaciones de TI se miden con una métrica muy concreta: el MTTR, el tiempo medio de resolución. Es lo que define si cumples el SLA que firmaste con tu cliente interno o externo, y en industrias reguladas, un incumplimiento no es solo una queja, puede ser una multa. Bajar el MTTR de horas a minutos no es una mejora cosmética, cambia directamente cuántas personas necesitas en guardia nocturna y cuánto tiempo de inactividad le cuesta al negocio cada incidente.
Lo que el anuncio no resuelve solo
Nada de esto funciona si el agente alucina un diagnóstico y nadie lo revisa. DXC no está reemplazando al ingeniero de guardia, lo está moviendo de 'investigar manualmente durante 80 minutos' a 'revisar y aprobar una propuesta en 5'. Esa diferencia solo se sostiene si el sistema de aprobación es bueno de verdad, con evidencia clara de por qué el agente propone lo que propone. Si el agente solo dice 'reinicia el servicio X' sin mostrar los logs que lo llevaron a esa conclusión, nadie en su sano juicio va a aprobar eso a las 3 de la mañana. Por eso LangSmith (la capa de observabilidad) termina siendo tan importante como LangGraph (la capa de orquestación): sin poder ver el razonamiento paso a paso, la aprobación humana se vuelve un trámite sin sentido, un botón que la gente aprieta sin leer.
¿Esto es solo para consultoras del tamaño de DXC?
No. Las piezas que usa DXC (LangGraph para orquestar, LangSmith para observar, el patrón de aprobación humana en el medio) son las mismas que puede armar un equipo de 5 personas. La diferencia entre DXC y una pyme no es el framework, es el volumen de incidentes y los años de pulir el flujo de aprobación. Si tu empresa ya tiene un proceso con el patrón 'varios pasos, varias personas, mucho tiempo muerto entre pasos', ahí hay terreno para un agente bien diseñado. Y con 'bien diseñado' haciendo todo el trabajo en esa frase: lo mismo sirve para conciliar pagos en finanzas, revisar contratos simples en legal, o escalar reclamos en atención al cliente.
Hay otro detalle que me parece subestimado en todo esto: DXC eligió un framework de código abierto (LangGraph) en vez de construir su propio motor de orquestación desde cero, algo que una empresa de ese tamaño podría pagar sin problema. La razón probable es simple: el ecosistema alrededor de LangChain (documentación, integraciones con herramientas, una comunidad que encuentra y reporta bugs todos los días) avanza más rápido que cualquier equipo interno trabajando solo. Es la misma lógica por la que cada vez más empresas en LATAM prefieren formar a su gente en frameworks abiertos en vez de apostar todo a una solución cerrada de un solo proveedor.
Cómo aprender a construir algo así
Si quieres entender LangGraph a fondo, el framework que DXC usó para orquestar OASIS, el punto de partida es el curso de Creación de Agentes con LangChain, donde armas agentes desde cero con herramientas, memoria y los mismos patrones de control de flujo que mencioné arriba. Y si tu meta es el perfil completo, el que diseña arquitecturas de agentes para producción y no solo scripts sueltos, ese es el rol de AI Agentic Engineer, la ruta que cubre RAG, memoria, harness engineering y despliegue de principio a fin.
Si quieres practicar esto con gente que está resolviendo los mismos problemas, cada semana hacemos un taller en vivo en la Comunidad AI Builders: es el paso intermedio entre leer sobre agentes y construir uno de verdad, acompañado.
Qué pasa si tu empresa no es una consultora de TI
He visto este mismo patrón repetirse en contextos que no tienen nada que ver con servidores. Un equipo de cobranzas que arma un agente para priorizar qué cuentas llamar primero según el historial de pago, con un paso de revisión antes de cualquier acción sobre un cliente VIP. Un equipo de compliance que usa un agente para marcar contratos con cláusulas fuera de política, pero deja la decisión final de rechazar o renegociar a una persona. En los tres casos (TI, cobranzas, compliance) el patrón se repite: el agente hace el trabajo pesado de investigar y proponer, la persona hace el trabajo de juzgar. Esa división es la que hace que un proyecto de agentes pase de ser un experimento bonito a una herramienta que el negocio usa todos los días sin miedo.
Para seguir
Si este anuncio te dejó con ganas de meterle mano a un agente real, arranca por el curso de LangChain o directo por la ruta de AI Agentic Engineer. También puedes revisar el resto de cursos de IA y datos para armar tu propio plan.
