Creación de espacios de trabajo compartidos para personas y agentes

Hace poco lanzamos Proyectos, donde personas y agentes colaboran en tareas de larga duración en Perplexity Computer. Cada proyecto se apoya en un espacio de trabajo compartido con un sistema de archivos que acumula contexto entre sesiones, agentes y usuarios. Una colaboración multijugador que se prolonga durante meses requiere persistencia, concurrencia y trazabilidad:

• Persistencia: el trabajo debe perdurar más allá de cualquier sesión o entorno aislado de un agente concreto, para que el mismo usuario o agente pueda continuarlo en el futuro y cualquier colaborador pueda aprovecharlo.
• Concurrencia: varios usuarios de un mismo proyecto pueden tener cada uno varios agentes que realizan ediciones en paralelo y que hacen avanzar un estado compartido en lugar de sobrescribirse entre sí.
• Trazabilidad: tanto los usuarios como los agentes deben poder ver el historial para comprobar quién ha cambiado qué desde su última sesión sin tener que volver a leer todo el proyecto, y revertir ediciones cuando sea necesario.

Estos retos resultan familiares para los ingenieros de software. Las forjas de Git surgieron hace décadas para satisfacer estos requisitos: un servicio alojado que envuelve el control de versiones con funciones colaborativas para que muchos colaboradores puedan converger en una única fuente de verdad. El sistema de archivos en el que se basa Proyectos es una de esas forjas de Git, creada para la colaboración entre personas y agentes, y entre agentes.

Ampliar

Arquitectura

Git ya se encarga de la persistencia, la concurrencia y la trazabilidad. Identifica cada archivo por su contenido, por lo que los archivos sin cambios se almacenan una sola vez y las copias guardadas nunca quedan obsoletas. Cada commit guarda todos los archivos actualizados a la vez, así que los colaboradores nunca ven un estado a medio terminar. Cuando dos escritores entran en conflicto, el que ha perdido puede volver a aplicar sus cambios sobre la nueva versión e intentarlo de nuevo. La cadena de commits muestra quién cambió qué y facilita la restauración de versiones anteriores. Lo que los agentes no necesitan es el resto de una forja pensada para personas, como las pantallas de revisión, la gestión de ramas y las notificaciones.

Nuestra arquitectura ejecuta todo el proceso en la nube y admite todo tipo de trabajo intelectual más allá de la programación. Cada proyecto de Computer está respaldado por un repositorio Git servido por 5 componentes:

• La CLI mantiene los checkouts locales, sincroniza las actualizaciones y envía los cambios del agente en cada entorno aislado.
• El plano de control localiza el repositorio del proyecto y emite credenciales de corta duración para acceder a él.
• El servicio Git envía los datos del repositorio a los entornos aislados, recibe sus envíos y decide qué envío se convierte en el último commit aceptado.
• El almacenamiento basado en AWS S3 guarda de forma duradera los datos de los repositorios.
• El procesamiento posterior extrae texto y otra información útil de los documentos guardados y la pone a disposición de los agentes cuando cargan o actualizan el proyecto.

Cada agente tiene su propio entorno aislado. Dentro de él, trabaja con una copia local del repositorio, gestionada por una pequeña CLI. La CLI pide al plano de control que localice el repositorio y, después, obtiene y envía cambios a través del servicio Git. Un proxy de agentes comprueba el acceso de las solicitudes de los entornos aislados antes de que lleguen al servicio Git. El servicio Git lee y escribe repositorios en un sistema de archivos compartido y decide si cada envío se convierte en el último commit aceptado. Ese sistema de archivos lo proporciona AWS S3Files, que hace que el almacenamiento basado en S3 sea accesible como archivos y directorios normales. El almacenamiento se divide en celdas aisladas, cada una con su propio sistema de archivos y sus propias réplicas del servicio Git. Una vez aceptado un commit, procesos en segundo plano extraen texto y otra información útil de los documentos modificados, almacenan los resultados por separado del historial del repositorio y los ponen a disposición de los agentes cuando cargan o actualizan el proyecto.

A continuación, repasamos los componentes uno por uno.

Ampliar

CLI: trabajar con archivos locales en entornos aislados

Los agentes se ejecutan en SPACE, nuestra plataforma interna de entornos aislados. Cada entorno aislado tiene una pequeña CLI que materializa el repositorio y lo mantiene sincronizado. Por cada unidad de trabajo significativo que realiza el agente, la CLI envía los cambios como un commit.

Los agentes normalmente solo usan una pequeña parte de los archivos del proyecto, así que no es necesario materializar todo el repositorio de antemano. Por eso, la CLI materializa de forma diferida: los archivos grandes y binarios almacenados mediante Git Large File Storage (LFS) llegan como pequeños archivos puntero que guardan el tamaño real del objeto, de modo que el agente puede usar el nombre y el tamaño para decidir si merece la pena descargarlos. En documentos como los PDF, el agente lee primero el texto analizado y solo descarga los archivos originales cuando es necesario.

Otra opción natural sería usar un sistema de archivos virtual. Probamos una implementación basada en FUSE, pero era aproximadamente 400 veces más lenta que los archivos locales en cargas de trabajo con uso intensivo del sistema de archivos, ya que cada solicitud requiere un viaje de ida y vuelta por la red. Además, suele requerir capacidades privilegiadas del host, por lo que todos los agentes tendrían que ejecutarse en un entorno aislado privilegiado.

Ampliar

Plano de control: localización de repositorios y concesión de acceso

El plano de control localiza dónde se almacena cada repositorio y concede acceso a él. Cuando se crea un repositorio, el plano de control lo asigna a una celda de almacenamiento, una unidad de almacenamiento aislada con sus propias réplicas del servicio Git. Cuando un agente empieza a trabajar en un proyecto, la CLI pregunta al plano de control dónde está almacenado el repositorio. El plano de control devuelve la ubicación y credenciales temporales para el servicio Git. El plano de control nunca lee ni escribe datos del repositorio. Es el servicio Git el que decide qué entra en un repositorio.

Servicio Git: transferencia de datos y coordinación de actualizaciones

El servicio Git ejecuta operaciones de Git y transfiere el contenido y el historial de versiones de los repositorios entre los entornos aislados y el almacenamiento. Es una capa fina sobre los propios comandos de servicio de Git. Admite el descubrimiento de refs, para indicar al cliente dónde está el head del repositorio; upload-pack, para clonar y obtener cambios, y receive-pack, para recibir nuevos objetos y una solicitud para hacer avanzar el head del repositorio. También sirve la API de Git LFS: para los archivos grandes y binarios, emite enlaces de corta duración para que los entornos aislados puedan subir y descargar esos archivos directamente desde S3.

Empezamos con un servidor de forja estándar para poder crear prototipos de las interfaces de agente y de usuario mientras desarrollábamos nuestra propia forja ligera, centrada únicamente en las operaciones de Git que necesitamos.

El servicio consta de un conjunto de réplicas, cada una de ellas una instancia en ejecución del mismo servidor. Una celda agrupa el almacenamiento compartido con un conjunto de réplicas y sus servicios de soporte. Así, las réplicas de una celda pueden acceder al mismo sistema de archivos compartido, en lugar de mantener copias independientes de cada repositorio.

Este almacenamiento compartido permite que las réplicas no tengan estado. Cualquier réplica de la celda puede servir cualquiera de sus repositorios, por lo que sustituir o añadir réplicas no requiere mover datos de repositorios entre servidores. Las solicitudes para un repositorio suelen dirigirse a la misma réplica para que sus cachés sigan siendo útiles, pero el repositorio no depende de que esa instancia concreta siga disponible.

El paso de aceptación comprueba las invariantes del repositorio para garantizar que un commit aceptado sea un estado válido del repositorio. Definimos un contrato explícito para cada repositorio, de modo que las comprobaciones mecánicas puedan evitar que crezca demasiado. Los archivos grandes y binarios, como los PDF y las imágenes, se almacenan mediante Git LFS en lugar de como blobs de Git sin procesar. La compactación mantiene disponible el historial reciente y limita el tamaño del repositorio. Tras un envío correcto, la CLI pregunta al servicio Git si el repositorio necesita compactarse. Si el número de commits conservados supera un umbral, el servicio Git conserva solo un conjunto más reducido de los commits más recientes. El historial más antiguo se sustituye por una única instantánea inicial, y los commits recientes se vuelven a aplicar para actualizar los identificadores de commit.

Ampliar

Un sencillo paso de sincronización gestiona los escritores concurrentes. Registra el último commit aceptado, o head. Cuando recibe un envío, solo lo acepta si se ha creado sobre ese head. Si no es así, envía una respuesta estructurada de base obsoleta; el perdedor debe entonces volver a aplicar su cambio sobre el nuevo head y reenviarlo. Este diseño garantiza que los agentes concurrentes no se sobrescriban entre sí de forma silenciosa, sin provocar ralentizaciones significativas. En nuestros flujos de trabajo de producción, menos del 2 % de los envíos se rechazan por estar obsoletos. En general, la latencia mediana de envío es inferior a 1,7 segundos, y la latencia p99 es inferior a 8 segundos.

Ampliar

El servicio Git también registra cada cambio aceptado. Por cada escritura aceptada, añade una entrada a una bandeja de salida (outbox), un registro que indica el repositorio, el nuevo commit, el usuario que realizó el cambio y las rutas modificadas. Los servicios posteriores, como el analizador, leen este registro para encontrar trabajo nuevo.

En conjunto, estas piezas forman una capa de gestión de repositorios sin las partes que los agentes no necesitan. Las pull requests son innecesarias, porque ninguna persona revisa cada cambio. En su lugar, el servicio Git comprueba el contrato en el momento del envío, el agente que pierde una carrera vuelve a aplicar su propio cambio y el historial de commits registra quién cambió qué. Las comprobaciones deterministas mantienen cada repositorio dentro de su contrato, en lugar de depender de un operador humano para gestionar su crecimiento.

Almacenamiento: conservar el trabajo de forma duradera

La capa de almacenamiento guarda de forma duradera los datos de los repositorios, con independencia de los entornos aislados y de las réplicas del servicio Git. Los repositorios residen en AWS S3Files, que expone almacenamiento basado en S3 mediante una interfaz de sistema de archivos que Git estándar puede usar sin modificaciones. Cada uno es un repositorio Git bare en el sistema de archivos compartido, que contiene los objetos y las referencias del repositorio en lugar de un checkout de trabajo.

Desacoplar el almacenamiento y el cómputo permite que los entornos aislados sigan siendo efímeros. Cada agente obtiene su propio entorno aislado, y muchos agentes pueden trabajar en el mismo proyecto sin compartir una máquina. Si un entorno aislado falla, solo corre peligro el trabajo que no se ha enviado.

En su lugar, podríamos asignar a cada proyecto un entorno aislado de larga duración compartido por todos sus agentes, de modo que los archivos del proyecto residieran en el disco de esa máquina. Sin embargo, esto vincularía la capacidad de cómputo de los agentes al lugar donde se ejecute la máquina y obligaría a dimensionarla para sus periodos de mayor actividad. Además, tendría que mantenerse en buen estado durante meses, con copias de seguridad y recuperación gestionadas como parte del sistema de almacenamiento del proyecto.

Ampliar

Procesamiento posterior: hacer que los documentos sean legibles para los agentes

El principal componente posterior es una canalización de análisis que extrae texto y metadatos de los documentos recién añadidos o actualizados para que los agentes puedan leer fácilmente los archivos del proyecto. Un proceso de análisis consume las actualizaciones de la cola del flujo de cambios, obtiene los archivos modificados a partir de los metadatos del commit y recupera los bytes sin procesar mediante el hash del contenido. Después, analiza el documento para generar el texto extraído y los metadatos del documento.

Los resultados del análisis residen fuera del repositorio, en un almacén indexado por el hash del documento original. Estos artefactos nunca se confirman en el repositorio, ya que eso contaminaría innecesariamente el historial y aumentaría el número de escrituras concurrentes. En su lugar, los resultados del análisis llegan al entorno aislado a través del checkout y la sincronización. Cada checkout incluye un directorio reservado que la CLI usa para materializar los artefactos. El análisis se realiza de forma asíncrona, por lo que el proceso de análisis en segundo plano no bloquea los checkouts.

Cómo usan los agentes el espacio de trabajo

Los agentes exploran la versión del repositorio cargada en el entorno aislado con herramientas estándar del sistema de archivos. En lugar de seguir una secuencia fija de buscar y luego leer, listan carpetas, buscan en el contenido de los archivos con grep, leen los fragmentos relevantes y usan lo que encuentran para decidir dónde buscar a continuación.

Al igual que Computer, Search aplica el mismo enfoque mediante sus herramientas de archivos estándar. Un agente de exploración independiente busca en el proyecto con un presupuesto más limitado y devuelve las rutas de archivo relevantes y los fragmentos que las respaldan. A continuación, el modelo que responde lee los archivos seleccionados y genera la respuesta. Reutilizar un entorno aislado existente del proyecto reduce el tiempo de preparación: conectarse a un checkout en caliente tarda unos 2,9 segundos, frente a aproximadamente 8 segundos en un arranque en frío.

Ampliar

El texto analizado permite buscar en documentos más grandes, como los PDF y los archivos de Office, con las mismas herramientas. El agente consulta primero un manifiesto, una lista que indica qué documentos tienen texto extraído disponible, y después busca y lee ese texto como si fueran archivos normales. Solo descarga el documento original cuando el texto no basta, por ejemplo, para examinar figuras, la maquetación o datos incrustados.

Comparamos este enfoque con la búsqueda semántica en un índice mediante 150 preguntas financieras de un solo documento sobre el mismo corpus. El agente de exploración obtuvo 0,867 en la recuperación del documento correcto y 0,627 en responder correctamente, frente a aproximadamente 0,39 y 0,37 de la búsqueda semántica: alrededor de 1,7 veces mejor en las respuestas y 2 veces mejor en la recuperación, con una latencia aproximadamente un 25 % menor. El agente de exploración trabaja principalmente con texto extraído y rara vez descarga los PDF originales.

Ampliar

Una infraestructura compartida

La memoria persistente de Computer usa la misma infraestructura de sistema de archivos. Perplexity Brain, la wiki de conocimiento de Computer, almacena la memoria en repositorios de conocimiento con su propio historial y sus propias políticas. Mantener el conocimiento separado de los archivos del proyecto significa que las actualizaciones de memoria en segundo plano no compiten con las ediciones de esos archivos. Una sesión que necesita ambos carga los dos repositorios.

Los agentes en segundo plano leen el conocimiento existente, incorporan información nueva y guardan las páginas actualizadas como commits. Otros agentes leen esas páginas con herramientas de archivos normales, y las personas también pueden editarlas. Los escritores comparten su trabajo a través del repositorio en lugar de coordinarse directamente con cada lector. El historial de commits registra quién cambió qué, mientras que la bandeja de salida comunica las actualizaciones aceptadas a los servicios posteriores. Personas y agentes pueden aprovechar el trabajo de los demás, con un registro de cómo ha evolucionado el conocimiento.

Conclusión

Cuando personas y agentes comparten un proyecto, el espacio de trabajo hace algo más que almacenar archivos. Proporciona un lugar común donde combinar las contribuciones y seguir lo que ha cambiado. Git ya aporta gran parte de esa base. Nosotros añadimos coordinación y comprobaciones automatizadas para que los agentes puedan enviar trabajo sin que una persona apruebe cada actualización. El resultado es una forja reducida a lo esencial, ya que, en el fondo, la colaboración entre agentes y el desarrollo de software con múltiples colaboradores son el mismo problema.

Los agentes trabajan en entornos aislados independientes y temporales mientras contribuyen a repositorios duraderos. Los límites de los repositorios mantienen el crecimiento bajo control, las descargas explícitas permiten a los agentes elegir qué obtener y los archivos normales les permiten explorar con herramientas conocidas. Las actualizaciones en segundo plano, las ediciones interactivas y las tareas programadas pueden aprovechar el trabajo de las demás sin coordinarse directamente.

A medida que más agentes trabajan de forma autónoma dentro de Proyectos, su espacio de trabajo compartido debe seguir siendo fiable y comprensible para las personas. El objetivo es sencillo: cada cambio debe ser más duradero que el agente que lo produjo, quedar disponible para el siguiente colaborador y dejar un registro claro de lo que cambió.

Cita

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}