La semana pasada enviamos No más de meses de sprints de ingeniería – en una semana, con 10 sesiones de Agente de membrana que se ejecutan en paralelo. 1,000 API integrations El universo membranoso Membrane Universe es nuestra biblioteca de conocimientos de integración preestablecidos, todo lo que un agente o desarrollador necesita para conectarse a APIs externos. Hay muchos tipos de elementos en él, pero para este proyecto nos enfocamos en dos: Conectores, que definen cómo conectarse a una API externa (autenticación a través de OAuth2, claves de API, etc., más recopilaciones de datos y eventos) Paquetes de acción, que son colecciones de acciones de API listas para usar (por ejemplo, "Crear un mensaje Slack", "Lista repos GitHub") que agentes y flujos de trabajo pueden llamar. Para los paquetes de acción, no intentamos ser exhaustivos - generamos las acciones más comunes que cubren ~80% del uso típico. Construir cada integración manualmente requiere de un desarrollador - Investigar los documentos, averiguar auth, implementar el cliente, escribir pruebas. A esa tasa, 1.000 integraciones llevarían a una persona aproximadamente un año de trabajo a tiempo completo.Hemos utilizado LLMs para acelerar esto desde los primeros días de gpt-3.5, pero siempre fue ad-hoc. 30–60 minutes Membrane Agent ya sabe cómo trabajar con nuestra plataforma. Hemos construido una tubería de lotes para procesar miles de aplicaciones automáticamente. We saw the opportunity to industrialize it La construcción del gasoducto El gasoducto tiene dos fases, cada una impulsada por su propio script de lotes. Fase 1 trata de la autenticación, la parte más difícil de cualquier integración. Fase 2 capas sobre las acciones que hacen que cada integración sea útil. Ambos siguen el mismo patrón: recoger aplicaciones elegibles, crear agentes de IA simultáneos, validar los resultados, publicar lo que pasa, marcar lo que no. Fase 1 - Autenticación (construcción de conectores) Este script trata el primer paso: implementar auth para cada aplicación. How it works: Recibe todas las aplicaciones de nuestra API, filtra a las que aún no tienen un conector Para cada aplicación (executando hasta 10 simultáneamente), es: Crea un registro de conector en Membrane Crea una sesión de agente en nuestro motor Spawns un agente local de membrana alimentado por Claude Dice al agente qué conector implementar - el agente sabe cómo interactuar con Membrane desde su prompt del sistema y cómo construir conectores a través de habilidades precargadas, por lo que el mensaje del usuario es sólo el nombre de la aplicación y la URL Espera que el agente termine (~ 2,5 minutos en promedio) Valida el resultado frente a nuestros esquemas: este ciclo de retroalimentación es importante para los agentes, ya que pueden corregirse cuando la validación falla Si es válido: publica el conector y lo hace público Si es válido: marca la aplicación para una revisión manual What Membrane Agent actually does inside each session: En primer lugar, el usuario utiliza y Para encontrar la documentación de la API de la aplicación. lee a través de los documentos, descubre si la API utiliza OAuth2, API keys, Basic auth, u otra cosa, y configura todos los parámetros relevantes de auth - ID del cliente / campos secretos, ámbitos, URLs de token, las obras. web search web fetch Luego implementa un cliente de API que adjunta correctamente credenciales a las solicitudes, escribe una función de prueba para verificar la conexión, y realmente hace solicitudes HTTP a la API para confirmar que es accesible y responde correctamente. Finalmente, utiliza las herramientas de Membrane para escribir toda la configuración de vuelta a la plataforma. El agente lo hace de forma totalmente autónoma. 2.5 minutes per app Haz la matemática: Eso es aproximadamente 10 conectores construidos y validados cada un par de minutos - sin un solo toque de teclado humano. y 10 es sólo lo que nos hemos fijado para ahora - la concurrencia es configurable y podría ir más alto. 10 agents, ~2.5 minutes each, running in parallel Cada agente maneja un conector (o un paquete de acción) por sesión. deliberadamente lo mantenemos en un elemento por sesión para evitar hinchar la ventana de contexto - una nueva sesión para cada aplicación significa que el agente permanece enfocado. Fase 2 - Acciones (construcción de paquetes) Una vez que una aplicación ha configurado auth, está lista para la segunda fase: generar las acciones que hacen que la integración sea realmente útil. El patrón refleja la Fase 1. El script filtra a las aplicaciones que tienen un conector con auth pero sin paquete todavía, luego engendra un agente para cada uno. Cada agente conoce su ID de conector y se le dice que implemente el paquete. Investiga la API de la aplicación, identifica los endpoints más populares y útiles, y crea definiciones de acción —completa con esquemas de entrada, configuración de solicitud de API, esquemas de salida y directrices opcionales para el comportamiento no obvio. Después de la validación (verificar el paquete realmente tiene acciones), se publica y se hace público. La arquitectura Aquí está como se ve el sistema completo cuando se zooma: Detalles técnicos clave En la competición 5-10, procesamos Aquí está lo que hace que funcione de manera fiable: ~100 apps per batch run Sesión de seguimiento Cada sesión de agente se rastrea en nuestra nube, aunque los agentes se ejecuten localmente durante las ediciones de batch. El script crea sesiones en nuestra plataforma y después de que cada agente termine, y sincroniza todos los mensajes de conversación de vuelta. Esto significa que podemos revisar cada decisión de IA a través de nuestra interfaz de usuario de la consola, exactamente como si fuera una sesión alojada en la nube. Validación y manejo de errores No todas las aplicaciones pueden ser automatizadas. El script maneja el fracaso graciosamente: Validación del esquema: Después de que el agente termine, validamos el resultado contra nuestros esquemas SDK. Si no pasa (falta de campos requeridos, estructura incorrecta), la aplicación se marca. APIs muertas: El agente es instruido a dejar auth vacío y explicar por qué si la API no está disponible. Timeouts: Si Claude se queda atrapado en una API particularmente complicada (aunque no sucede a menudo), la sesión se marca como fallida y se puede retrasar. Cuando un agente falla en una aplicación, revisamos la sesión para entender por qué — ¿era una brecha en las habilidades del agente? ¿Un extraño patrón de API? ¿Una mala documentación? — Corregimos el problema subyacente, re-executamos, y cada lote es mejor que el último. Conocimientos del agente Esta es la clave: el agente no comienza de cero para cada API. Su prompt de sistema se monta a partir de múltiples fuentes de conocimiento: Vista general de la plataforma de membrana (qué es Membrane, cómo funciona el marco) Habilidades de construcción de conectores (un flujo de trabajo paso a paso para implementar auth, determinar el tipo de auth, leer los documentos específicos de auth, configurar los parámetros, implementar el cliente de API, implementar la prueba) Habilidad de OpenAPI (cómo encontrar y interrogar incrementalmente las especificaciones de OpenAPI sin cargar esquemas enteros en el contexto), Guías de implementación detalladas para las funciones del conector principal. Nuestro marco de agentes soporta la carga de habilidades en demanda durante una sesión, pero para el procesamiento de lotes encontramos que la pre-carga de habilidades clave directamente en la solicitud del sistema funciona mejor. LLMs todavía no tienen habilidades de autocarga fiables en el 100% de los casos, y en esta escala desea consistencia sobre flexibilidad. Esto significa que el agente tiene un profundo conocimiento de los patrones de nuestra plataforma antes de que incluso vea la API de destino. El Manual Layer No todo es totalmente automatizado —y eso es por diseño.Algunas cosas todavía necesitan un humano: Casos de Edge: Algunas APIs son indocumentadas pero funcionales. los descubrimos durante la revisión y las tratamos manualmente. Revisión de calidad: Revisamos las sesiones de agentes a través de nuestra consola, especialmente para las aplicaciones donde la validación falló. No hay credenciales reales: Actualmente, el agente no autentica con claves de API reales. Verifica que las API son accesibles y que el auth está configurado correctamente, pero no completa los flujos de OAuth reales. Estamos construyendo activamente la automatización del navegador para la generación automática de cuentas de prueba para cerrar esta brecha. ¿Qué es lo siguiente Estamos lanzando públicamente Membrane Universe en las próximas semanas, comenzando con nichos y aplicaciones obscuras - APIs de vieja escuela, sistemas mal documentados. La mayor brecha en este momento es la prueba de credenciales reales.Estamos construyendo la automatización del navegador para el registro automático y los flujos de OAuth para que los agentes puedan verificar las integraciones de fin a fin. A largo plazo: mantenimiento continuo. las API cambian, los puntos finales se deprecian. Los mismos agentes que construyeron estas integraciones las mantendrán actualizadas. El cuadro más grande es este: los agentes de IA no son solo asistentes de codificación que te ayudan a escribir funciones más rápidamente. Ponerlos en un problema bien definido, darles las herramientas y conocimientos adecuados, y pueden construir cosas a una escala que simplemente no era posible antes. infrastructure builders
