De la programación a los agentes de trabajo de conocimiento — Karan Vaidya, Composio

AAI Engineer
Computing/SoftwareInternet Technology

Transcript

00:00:00Hola a todos, soy Karan Vedya, cofundador y CTO de Composio.
00:00:19La mayoría de las llamadas a herramientas de agentes
00:00:21siguen ocurriendo en un solo campo.
00:00:23Sin sorpresas: es la ingeniería de software.
00:00:26Cualquier otro tipo de trabajo se queda muy atrás.
00:00:29Si los modelos siguen mejorando, entonces
00:00:32¿por qué seguimos limitados solo a la programación con agentes?
00:00:35Esa es la pregunta del millón que vengo a responder.
00:00:43Hace tres años, los agentes de código eran solo autocompletado.
00:00:47Hoy en día, la ingeniería de software es completamente autónoma.
00:00:50Pasamos de presionar tab, tab, tab a dejar que Claude se encargue de todo.
00:00:56Es simplemente mágico.
00:00:59¿Y por qué ocurrió tan rápido en la programación?
00:01:04La mayoría pensaría que son los modelos.
00:01:06Sí, los modelos mejoraron mucho con el tiempo, en los últimos dos o tres años, y también lo hicieron
00:01:13los entornos de ejecución, como Claude Code, Codex y Cursor.
00:01:17Pero por sí solos, no habría sido suficiente.
00:01:20Solo funcionó porque toda la infraestructura y los sistemas alrededor del código estaban literalmente diseñados
00:01:26para los agentes.
00:01:27El código venía con el soporte que los agentes necesitaban.
00:01:31Tienes el repositorio, el historial de confirmaciones, las pruebas, CI/CD, revisiones, linters, y la opción de revertir si algo
00:01:39sale mal.
00:01:39Ese tipo de cosas que te hacen confiar en los agentes y en los sistemas que rodean al código.
00:01:45Ahora, estamos dirigiendo estos mismos agentes increíbles hacia cualquier otra área: soporte, finanzas, ventas.
00:01:54Pero los agentes que funcionaban de maravilla en la programación están trabajando a ciegas porque la
00:02:00infraestructura en torno al código ni siquiera existe en otros campos.
00:02:04Entonces, ¿cómo cerramos la brecha entre los agentes de programación y los agentes de trabajo de conocimiento?
00:02:11Creemos que se trata de seis primitivas fundamentales, y la programación tenía las seis, mientras que el trabajo de conocimiento no tiene
00:02:19ninguna.
00:02:20Y eso es lo que necesitamos construir.
00:02:24La primera es la centralización.
00:02:26Los agentes de código funcionaban muy bien, en parte porque estaban muy cerca de la fuente de la verdad.
00:02:34Conocían el qué, el porqué y el cómo.
00:02:37Les das el repositorio, la infraestructura como código, cierras el ciclo y dejas que el modelo trabaje.
00:02:43se luzca.
00:02:44El agente empieza con todo lo que necesita en un solo lugar, que es la base de código.
00:02:51Esto es exactamente lo que le falta al trabajo de conocimiento hoy en día.
00:02:55Por ejemplo, un solo acuerdo comercial está disperso en cinco plataformas diferentes.
00:03:00Los registros están en Salesforce, los documentos en Notion, los correos en Gmail, las conversaciones en
00:03:05Slack y el historial de soporte en Zendesk.
00:03:09No hay una única fuente de verdad, ni un solo lugar para obtener toda la información.
00:03:14El código está separado y cada aplicación tiene su propio inicio de sesión.
00:03:18Antes de que un agente de trabajo de conocimiento pueda siquiera empezar a hacer cosas, tiene que ir a recopilar todos los
00:03:23hilos y atarlos un poco por sí mismo.
00:03:27Y ese es apenas el punto de partida en el que empezaba un agente de código.
00:03:30Él ya lo tenía todo.
00:03:32¿Cómo puedes esperar entonces que un agente de trabajo de conocimiento haga el mismo nivel de trabajo que uno de programación?
00:03:39Así que lo primero que construimos es el centro que falta.
00:03:42Un solo lugar donde existan todas tus aplicaciones, todas tus conexiones y todos tus inicios de sesión.
00:03:46Para que el agente no tenga que hacer el arduo trabajo de unirlas todas por sí mismo.
00:03:51Lo encuentra todo en un solo lugar.
00:03:55Y obtiene la base con la que empezó el agente de código: el repositorio y la información
00:03:59de todas las pilas tecnológicas en un solo sitio.
00:04:02Esa es la base con la que arrancas, y puedes otorgar accesos de escritura a tu agente.
00:04:09Lo siguiente que necesita el agente es sentido de la historia, la capacidad de mirar hacia el pasado.
00:04:16En el código, lo obtienes gratis.
00:04:18Git mantiene un registro de cada cosa que entró y de cada cambio que se realizó.
00:04:23De este modo, el agente siempre puede mirar atrás y ver cómo se hizo un cambio determinado.
00:04:27Por qué algo funcionó y por qué algo no funcionó.
00:04:31Piensa en el tipo de cosas que realmente le pides a tu agente que haga.
00:04:34Tuvimos que revertir un cambio en el pasado debido a algún fallo, pero fue bastante difícil de lograr.
00:04:40¿Puedes revisarlo y recuperarlo de nuevo?
00:04:43Simplemente lee el historial, lo recupera y se pone a trabajar.
00:04:46El historial no es solo para el agente.
00:04:49También es para que tú lleves un registro de lo que está haciendo el agente.
00:04:53Puedes ver qué hace, dónde se está equivocando y dónde está teniendo éxito.
00:04:58Y en lugar de confiar en lo que te dice el agente, puedes ir directamente a esas aplicaciones
00:05:04y comprobar lo que ha hecho.
00:05:09Ahora, hazte esas mismas preguntas sobre el trabajo de conocimiento.
00:05:12¿Qué llevó al CRM al estado en el que se encuentra hoy?
00:05:16¿Cómo redactó mi colega ese correo increíble que condujo al cierre del acuerdo?
00:05:22¿Cuál es el proceso real para escalar un problema de soporte o incluso para resolverlo?
00:05:27Las respuestas están esparcidas por cientos de aplicaciones y ninguna conserva el historial.
00:05:31Así que el agente no tiene memoria.
00:05:33Empieza desde un estado en blanco casi siempre.
00:05:36No tiene idea de qué se intentó antes, qué funcionó y qué no.
00:05:40Y tú tampoco tienes nada que consultar.
00:05:44Una vez que el agente se ejecuta, te dice que lo ha hecho con éxito.
00:05:47Pero no sabes si realmente lo ha hecho bien.
00:05:49No hay forma de saber si está en lo cierto o no.
00:05:52Y eso es lo que falta: un registro del trabajo.
00:05:56Ahora, dado que todo finalmente pasa por un solo lugar, esa centralización,
00:06:02podemos construir una capa encima, el registro.
00:06:06Cada acción que toma el agente puede registrarse en todas las demás aplicaciones.
00:06:12Lo que sea que tocó, lo que omitió, qué funcionó y qué no.
00:06:17A través de esto, en primer lugar, el agente adquiere memoria.
00:06:20Puede mirar hacia atrás para ver cómo se hicieron tareas similares antes, qué tuvo éxito y replicarlo.
00:06:28No empieza desde cero todo el tiempo.
00:06:31Segundo, obtienes confianza.
00:06:33Por fin puedes ver exactamente lo que está haciendo el agente.
00:06:36Así que, en lugar de esperar que haga lo correcto, puedes regresar, verificar y detenerlo si hace algo mal.
00:06:44Y a medida que lo veas hacer lo correcto una y otra vez, desarrollarás confianza y le delegarás más tareas.
00:06:50Lo siguiente que necesita un agente es contexto.
00:06:53Y si lo piensas, en realidad hay dos tipos de contexto.
00:06:57El primero es la forma de la plataforma, la arquitectura.
00:07:01Cómo se relacionan las cosas entre sí, cómo están conectadas, los flujos de datos.
00:07:05Algo así como un mapa que un ingeniero sénior lleva en la cabeza y que a un ingeniero júnior le toma probablemente tres meses desarrollar.
00:07:12El segundo es el estilo.
00:07:13Esto no es lo que es objetivamente correcto, sino más bien cómo se ve un buen trabajo en tu empresa.
00:07:19Cómo haces las cosas, detalles como linters, comprobaciones de tipos, etcétera.
00:07:24Y tal vez uses un decorador de TypeScript que nadie más usaría.
00:07:29Esto no está escrito exactamente en un manual.
00:07:32Está más bien en tu base de código.
00:07:34Está todo disponible en tu base de código.
00:07:35Así que el agente puede ir a revisar y averiguar las especificaciones, lo que te gusta, los linters, los formateadores, etcétera.
00:07:45Ahora, pasando al trabajo de conocimiento, ocurre lo mismo.
00:07:48Digamos que estás escribiendo un documento para un cliente.
00:07:50Para tan solo empezar, tendría que abrir la base de datos para extraer su uso, comprobar retrospectivamente cómo han estado utilizando las cosas realmente,
00:07:58y mirar Salesforce para ver los detalles de su acuerdo.
00:08:01Solo entonces puedo empezar a escribir la primera línea del documento.
00:08:05La respuesta no estaba aislada en ninguna de esas herramientas por separado.
00:08:09Puedo escribir este documento porque estoy uniendo los hilos de todas estas herramientas en un solo contexto en mi cabeza.
00:08:15Así que, juntando el historial y el contexto, es como mapeas el funcionamiento de la organización.
00:08:21Y esa parte no está disponible fácilmente para el agente.
00:08:26Así que, al hacer la centralización y el registro —el historial que acabamos de crear, el que le da memoria al agente y te permite verificar lo que hizo—,
00:08:36también ocurre otra cosa interesante.
00:08:38Si registras lo suficiente de lo que hace cada agente, empiezas a ver patrones.
00:08:42Empiezas a ver cómo funciona la organización y a desarrollar habilidades, que son una especie de destilación de cómo ha estado operando.
00:08:51Qué enfoques funcionan y cuáles no, qué condujo a fallos en el pasado, etcétera.
00:08:57El registro ya no es solo el historial de lo que pasó.
00:09:01Es un retrato de cómo opera tu empresa.
00:09:03Y en realidad funciona a tres niveles diferentes.
00:09:06Cómo funciona una herramienta en general, lo cual es aplicable a cualquier persona.
00:09:09Cómo hace las cosas la empresa y cómo prefieres hacerlas tú.
00:09:13Cómo se ve un buen trabajo para ti.
00:09:15Y ese es el contexto que le faltaba a un agente de trabajo de conocimiento.
00:09:19Cómo se realiza el trabajo en la práctica.
00:09:21El manual de jugadas real, por así decirlo.
00:09:23Y las preferencias de una empresa y de un usuario individual.
00:09:27Ahora el agente puede consultarlo y dejar de adivinar cómo opera la compañía.
00:09:34La otra razón por la que los agentes de programación funcionan tan bien.
00:09:37Se prueban a sí mismos.
00:09:38El trabajo se comprueba solo.
00:09:40Verificación.
00:09:41En el momento en que el agente escribe código, le sigue una serie de comprobaciones.
00:09:44Las pruebas unitarias pueden detectar pequeños errores.
00:09:47Las pruebas de integración detectan los que solo afectan a componentes situados a tres bloques de distancia.
00:09:52El sistema de tipos ni siquiera funcionaría ni se ejecutaría si algo fuera mal.
00:09:57El compilador ni siquiera se compilaría.
00:10:00Por encima de todo eso se encuentran las comprobaciones de software.
00:10:02Linters, formateadores, bugbot.md, habilidades de revisión, etcétera.
00:10:06Y estos garantizan que el código coincida con la forma en que a tu equipo le gusta seguir sus estándares.
00:10:12Ninguno te llega.
00:10:14El agente completa el ciclo por sí solo y se asegura de seguir el estándar y de poder hacer que el código se ejecute.
00:10:21Ahora piensen en, bueno, hace un tiempo, dirigí mi open claw hacia una campaña de contratación.
00:10:28Correos masivos a candidatos.
00:10:30Funcionó.
00:10:31Envió toneladas de correos electrónicos.
00:10:34Es posible que algunos de ustedes también lo hayan recibido de mi open claw.
00:10:37Hizo exactamente lo que le pedí que hiciera.
00:10:40También fue un desastre.
00:10:42De esos que terminan en Twitter con mi nombre encabezándolo.
00:10:46Sí, creo que pueden ver un lío considerable por ahí.
00:10:51No estaba precisamente muy feliz cuando sucedió.
00:10:54Y he aquí el detalle.
00:10:55Todas las comprobaciones de la diapositiva anterior habrían pasado.
00:10:58Los correos eran válidos.
00:11:00Las direcciones eran reales.
00:11:00De hecho, llegaron a personas reales que publicaron.
00:11:04No había ninguna prueba en el mundo para cuestionar realmente lo que de verdad importaba.
00:11:10¿Debía haberse enviado esto siquiera?
00:11:13Esa es la brecha.
00:11:14En el código, estas pruebas te dicen qué está mal y qué está bien.
00:11:17Aquí, internet me dijo que yo estaba equivocado.
00:11:21Así que construimos las comprobaciones que faltan.
00:11:24El problema en el hilo anterior no fue que la campaña fuera errónea.
00:11:28Fue que se envió incluso antes de que yo me enterara.
00:11:31Así que la solución es sencilla.
00:11:33Atraparlo antes de que sea real.
00:11:35Por lo tanto, tenemos dos formas de hacerlo.
00:11:37Una, antes de que el agente envíe nada, comprueba los borradores de correo que he enviado antes, si coincide con mi estilo, si coincide con la calidad que me gusta.
00:11:47La segunda, antes de hacer cualquier cosa destructiva en el escenario del mundo real, proporcionamos a los agentes bandejas de salida que simulan las herramientas reales, y pueden enviar y realizar acciones sobre estas bandejas de salida.
00:11:59De modo que, en lugar de que el radio de impacto golpee al mundo real, golpeará un entorno aislado, y luego podré revisarlo antes de que el agente haga lo real.
00:12:07Junta ambas cosas y obtendrás algo que el trabajo de conocimiento nunca tuvo.
00:12:11Una forma para que el agente compruebe su propio trabajo antes de que sea real.
00:12:16Por fin puede cerrar su propio ciclo en lugar de detenerse a esperarte, y con todo eso, puedes confiar en la acción que está tomando sin que te bombardeen con los tuits que publico.
00:12:29Lo siguiente que necesita el agente es gobernanza.
00:12:32Construir confianza es controlar lo que el agente puede hacer, levantando los muros adecuados a su alrededor.
00:12:39En el código, esto está prácticamente resuelto y tiene múltiples capas.
00:12:44El agente puede hacer lo que quiera en su propia rama, pero no puede fusionarla con la principal.
00:12:49Un revisor humano se interpone antes de que se fusione con la principal.
00:12:52Los archivos críticos tienen propietarios de código, por lo que cada vez que toca uno de ellos, las personas adecuadas se ven involucradas.
00:12:58Usamos agentes para enviar a implementaciones de vista previa, nunca permitimos que toquen las de producción, así que lo controlamos ahí.
00:13:04La gobernanza no es una sola puerta, sino varias, y cada una varía de tamaño dependiendo del radio de impacto al que expone.
00:13:12Nada de esto ralentiza al agente en las partes seguras, solo evita que arruine la producción.
00:13:19Y cuanto más estrictas sean esas líneas, más podrás confiar en el agente y dejarlo actuar sin frenos.
00:13:25Probablemente viste este caso.
00:13:27La directora de alineación en Meta Super Intelligence Lab conectó un agente a su correo electrónico, y este empezó a destruir su bandeja de entrada, borrando muchos de ellos.
00:13:36Ella le dijo que se detuviera y siguió adelante; al final tuvo que correr hacia una máquina física para pararlo, pero para entonces ya habían desaparecido 200 correos.
00:13:45Le había indicado de antemano en el mensaje que confirmara antes de actuar en tales casos, pero eso era solo una instrucción en texto, que probablemente se compactó y desapareció.
00:13:53Y si alguien cuyo único trabajo es la alineación de la IA no puede indicarle correctamente al agente, entonces probablemente ninguno de nosotros pueda.
00:14:03Y esa es la verdadera razón por la cual es tan difícil confiar en estos agentes, no porque sean peores que los de programación, sino porque no hay ningún muro a su alrededor.
00:14:12En el código, el muro ya estaba integrado en el sistema mientras desarrollábamos antes.
00:14:17El trabajo de conocimiento también tiene algunos fragmentos aquí y allá.
00:14:20Por ejemplo, Gmail tiene ámbitos.
00:14:21Salesforce tiene niveles de permisos.
00:14:23Pero está tan disperso por todas partes que resulta muy difícil tener un control real, y la gente suele terminar haciéndolo mediante instrucciones de texto.
00:14:32Y las instrucciones son frágiles.
00:14:34El agente encontrará esas lagunas.
00:14:36Las cosas se compactarán y desaparecerán.
00:14:38Y a gran escala, una de estas barreras se romperá y también estarás en la misma situación en la que 200 de tus correos importantes desaparecen.
00:14:47Así que lo que realmente lo detendría no es una mejor instrucción, sino un muro que el agente no pueda cruzar, incluso si olvidara que ese muro existía.
00:15:00Así que construimos estos muros en dos capas.
00:15:03La primera capa es un control determinista sobre lo que el agente puede alcanzar y a qué tiene acceso.
00:15:09Un agente de contratación probablemente solo pueda leer los correos.
00:15:13Un agente de soporte puede crear un borrador de correo, pero no enviarlo realmente.
00:15:17El límite vive fuera de estos agentes.
00:15:19El agente no puede discutir con él, ni olvidarlo, ni compactarlo.
00:15:24Las instrucciones de uso fallaban porque vivían en la memoria del agente dentro del texto.
00:15:28Esto no.
00:15:30Pero el acceso por sí solo no la habría salvado, porque ella en realidad estaba construyendo un agente de correo electrónico.
00:15:36Así que definitivamente necesitaba acceso a ese correo.
00:15:39Lo otro que hacemos es proporcionar políticas, lo que significa que puedes definir directrices en lenguaje natural sobre lo que el agente puede hacer, incluso con dichos accesos.
00:15:49Así que cosas como no borrar nunca más de 10 correos sin mi permiso.
00:15:53Nunca enviar correos fuera de un dominio en particular.
00:15:56Reglas que, incluso con esos accesos, controlan el comportamiento.
00:16:00Así que entre esas dos cosas, una capa controla lo que el agente puede alcanzar, y la otra capa puede controlar el comportamiento con lo que puede hacer con ese alcance.
00:16:09Juntas, es una gobernanza real para el agente.
00:16:11No pedirle al agente que se comporte, sino hacer cumplir lo que puede hacer.
00:16:17El último pilar, la reversibilidad.
00:16:20Y aquí es a donde llegamos cuando las cosas salen mal.
00:16:25¿Puedo deshacerlo?
00:16:27En el código, casi siempre se puede.
00:16:30Cada cambio queda registrado.
00:16:32Se puede dar marcha atrás a las cosas.
00:16:33Puedes revertir el último commit o usar git bisect para encontrar el commit que rompió tu producción y revertirlo.
00:16:41O sea, no digo que sea bueno.
00:16:44No voy a fingir tal cosa.
00:16:45Si las cosas llegan a producción y se rompen, siempre es malo.
00:16:48Pero aún así no es permanente.
00:16:50Aún puedes dar marcha atrás.
00:16:51Y eso es lo que te da la confianza para dejar que tus agentes actúen por su cuenta y hagan algo de magia.
00:16:57Porque incluso si rompen las cosas, tienes una vía de retorno.
00:17:03Para el trabajo de conocimiento, no hay botón de deshacer.
00:17:05Cosas como pensar en la bandeja de entrada.
00:17:07Esos 200 correos se han ido.
00:17:09Se han desvanecido.
00:17:10Ese es el caso normal, por cierto.
00:17:12El caso desastroso es un correo enviado, el cual no puedes revertir.
00:17:15Una transferencia ya realizada, por lo que no puedes recuperar ese dinero.
00:17:18Un registro eliminado, perdido para siempre.
00:17:20La mayoría de las acciones en el trabajo de conocimiento no tienen un botón de deshacer.
00:17:24Y eso cambia toda la ecuación.
00:17:27Eso cambia el radio de impacto.
00:17:29Con el código, puedes confiar en el agente a posteriori.
00:17:31Déjalo correr.
00:17:32Revisa el resultado.
00:17:33Deshaz si está mal.
00:17:34Aquí fuera, no hay vuelta atrás.
00:17:36El único recurso que te queda es confiar antes de que el agente actúe.
00:17:40Eso es lo que hace que estos agentes se sientan peligrosos de una manera que los de programación nunca lo hicieron.
00:17:44No es que fallen a menudo.
00:17:46Es que ahí fuera el fallo es para siempre.
00:17:49Así que o confías por completo de antemano o nunca dejas que actúe.
00:17:55Déjenme ser honesto.
00:17:56La reversibilidad es lo más difícil de replicar en el trabajo de conocimiento.
00:17:59Un “undo” real, tal como existe para el código, probablemente no exista en todos los escenarios del trabajo de conocimiento.
00:18:04Pero tenemos algunos escenarios donde el “undo” existe, y los controlamos.
00:18:09Digamos que añades una etiqueta.
00:18:11Puedes quitar la etiqueta después.
00:18:14Pero para las acciones que no puedes deshacer en absoluto, como eliminaciones permanentes que hacen desaparecer los correos de tu bandeja de entrada,
00:18:21ofrecemos de nuevo un entorno aislado donde el agente puede hacer la tarea primero ahí,
00:18:25puedes revisarla y luego pasa realmente al entorno de producción.
00:18:30Nada de eso toca el mundo real.
00:18:31Ese es todo el cambio.
00:18:32En el código, puedes deshacer el error después de que ocurra.
00:18:35Aquí, lo atrapas antes de que lo haga.
00:18:37Diferente timing, mismo resultado.
00:18:39Un error que no perdurará.
00:18:41Piensen en ella otra vez.
00:18:42Las acciones que podíamos revertir, les daríamos un botón de reversión.
00:18:45Aquellas que no podíamos, el agente pasaría primero por el entorno aislado,
00:18:48y se le notificaría: tus 1.200 correos están a punto de ser borrados.
00:18:52¿Los quieres fuera?
00:18:54Todavía no está hecho.
00:18:57Pero a través de miles de millones de acciones que estamos procesando,
00:19:00vamos aprendiendo sobre la marcha cuáles se pueden revertir y cuáles no,
00:19:04y preparando el entorno aislado en consecuencia.
00:19:09Si se llevan una sola cosa hoy, que sea esta.
00:19:11Durante dos años, el modelo fue el cuello de botella.
00:19:14Así que todo el mundo competía por conseguir modelos cada vez mejores.
00:19:17Ahora los modelos se han vuelto lo suficientemente buenos como para que la ingeniería de software sea 100% autónoma.
00:19:23Pero ahora todo lo demás es el cuello de botella.
00:19:26El mismo modelo que escribe tu código también puede encargarse de tus contrataciones, ventas y otras tareas de conocimiento.
00:19:36Pero ahora mismo está trabajando a ciegas.
00:19:39Sin historial, sin contexto, sin formas de verificar, sin barandillas de seguridad, sin opción de deshacer.
00:19:44Así que el cuello de botella se ha movido.
00:19:48Ahora es la infraestructura que nadie ha construido todavía, y eso es lo que estamos construyendo en Composio.
00:19:54Sí, estamos impulsando mil millones de llamadas a herramientas en total, con 300 millones de llamadas ocurriendo cada mes.
00:20:02Y si estás construyendo un agente, solo dirígelo a Composio y observa cómo ocurre la magia en el trabajo de conocimiento.
00:20:08Y si quieres construir el futuro de la infraestructura de los agentes de IA, por favor acércate a mí.
00:20:13Definitivamente estamos contratando, y queda muchísimo por hacer.
00:20:17Los modelos seguirán mejorando.
00:20:19El cuello de botella no serán los modelos.
00:20:21Serán las cosas que los rodean.
00:20:22Gracias.

Key Takeaway

El cuello de botella de los agentes de IA ya no son los modelos, sino la falta de infraestructura de soporte, historial, contexto, pruebas, gobernanza y reversibilidad en el trabajo de conocimiento.

Highlights

  • Composio procesa 300 millones de llamadas a herramientas al mes y un total de mil millones de llamadas.

  • La ingeniería de software funciona con agentes autónomos debido a que toda la infraestructura previa ya estaba diseñada para ellos.

  • El trabajo de conocimiento carece de las seis primitivas fundamentales que la programación posee de manera nativa.

  • Un agente de correo electrónico autónomo borró 200 correos de una investigadora en Meta tras no contar con barreras de gobernanza deterministas.

  • La infraestructura de agentes de conocimiento requiere entornos aislados y políticas en lenguaje natural para prevenir acciones destructivas en producción.

Timeline

La brecha entre la programación y el trabajo de conocimiento

  • La ejecución de agentes de herramientas se concentra abrumadoramente en la ingeniería de software.
  • Los agentes de código operan con éxito porque la infraestructura de los repositorios incluye historiales, pruebas y sistemas de control.
  • El trabajo de conocimiento dispersa la información en múltiples plataformas como Salesforce, Notion, Gmail y Slack sin una fuente única de verdad.

La evolución de la asistencia de código pasó del autocompletado básico a la autonomía total de modelos como Claude Code y Cursor. Este éxito no se debe únicamente a la mejora de los modelos, sino a que el entorno de desarrollo posee una arquitectura preparada para agentes. En contraste, las tareas de oficina carecen de esta base unificada, lo que obliga al agente a recopilar datos fragmentados antes de iniciar cualquier labor.

Historial, registro y contexto en los flujos de trabajo

  • Git provee un registro histórico que permite a los agentes de código auditar y revertir modificaciones anteriores.
  • La ausencia de un registro centralizado en el trabajo de conocimiento deja a los agentes sin memoria operativa de lo que funcionó previamente.
  • El contexto empresarial combina la arquitectura de las plataformas con el estilo y las preferencias específicas de la compañía.

El historial funciona como la memoria del agente y la herramienta de supervisión del usuario. Sin un registro de las acciones previas en las aplicaciones empresariales, el trabajo de conocimiento carece de trazabilidad. Al centralizar los eventos, el sistema destila patrones operativos y preferencias corporativas que permiten al agente replicar comportamientos exitosos sin adivinar los procesos.

Verificación y gobernanza para prevenir fallos masivos

  • Las pruebas unitarias, de integración y los sistemas de tipos validan automáticamente el código antes de la ejecución.
  • Las instrucciones en texto libre fallan bajo presión y no logran detener acciones destructivas a gran escala en aplicaciones de correo.
  • La gobernanza efectiva requiere controles deterministas de acceso y políticas de comportamiento que el agente no pueda eludir.

Las campañas automatizadas sin pruebas de impacto real generan desastres públicos y pérdida de datos, como ocurrió en incidentes reales con bandejas de entrada corporativas. Para evitarlo, los sistemas actuales implementan bandejas de salida aisladas y restricciones de alcance estrictas que operan fuera de la memoria textual del modelo.

Reversibilidad y el futuro de la infraestructura de agentes

  • Git permite revertir commits y recuperar estados anteriores en la ingeniería de software a pesar de los errores en producción.
  • La mayoría de las acciones en el trabajo de conocimiento no cuentan con un botón nativo de deshacer.
  • Composio construye la infraestructura de centralización, gobernanza y entornos aislados para habilitar agentes autónomos en el trabajo de conocimiento.

La irreversibilidad de las acciones en el ámbito administrativo transforma el riesgo de los fallos, ya que las eliminaciones de registros o transferencias de dinero son permanentes. Mediante entornos aislados que simulan la producción y análisis previos de reversibilidad, es posible alcanzar el mismo nivel de confianza que existe en el desarrollo de software.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video