Cómo crear espacios de trabajo compartidos para personas y agentes

Recientemente lanzamos Proyectos, donde las personas y los agentes trabajan juntos en tareas de larga duración en Perplexity Computer. Cada proyecto se basa en un espacio de trabajo compartido con un sistema de archivos que acumula contexto entre sesiones, agentes y usuarios. La colaboración multijugador que se extiende durante meses requiere persistencia, concurrencia y trazabilidad:

• Persistencia: el trabajo debe perdurar más allá de cualquier sesión de agente o entorno aislado individual, para que el mismo usuario o agente pueda continuarlo en el futuro y cualquier colaborador pueda aprovecharlo.
• Concurrencia: varios usuarios del mismo proyecto pueden tener cada uno varios agentes que hacen 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 cambió qué desde su última sesión sin volver a leer todo el proyecto, y revertir ediciones cuando sea necesario.

Estos desafíos les resultan familiares a los ingenieros de software. Las forjas de Git surgieron hace décadas para cumplir estos requisitos: un servicio alojado que complementa el control de versiones con funciones colaborativas para que muchos colaboradores puedan converger en una única fuente de verdad. El sistema de archivos que impulsa Proyectos es una de esas forjas de Git, diseñada 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 desactualizadas. Cada commit guarda todos los archivos actualizados a la vez, así que los colaboradores nunca ven un estado a medio terminar. Cuando dos escritores chocan, el que perdió 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 restaurar versiones anteriores. Lo que los agentes no necesitan es el resto de una forja diseñada para personas, como pantallas de revisión, administración de ramas y notificaciones.

Nuestra arquitectura ejecuta todo el proceso en la nube y admite todas las formas de trabajo del conocimiento más allá de la programación. Cada proyecto de Computer está respaldado por un repositorio de Git atendido 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 ubica el repositorio del proyecto y emite credenciales de corta duración para acceder a él.
• El servicio de Git envía los datos del repositorio a los entornos aislados, recibe sus envíos y decide qué envío se convierte en el commit aceptado más reciente.
• 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 cuando los agentes cargan o actualizan el proyecto.

Cada agente tiene su propio entorno aislado. Dentro de ese entorno, trabaja con una copia local del repositorio, administrada por una pequeña CLI. La CLI le pide al plano de control que ubique el repositorio y luego obtiene y envía cambios a través del servicio de Git. Un proxy del agente verifica el acceso de las solicitudes del entorno aislado antes de que lleguen al servicio de Git. El servicio de Git lee y escribe repositorios en un sistema de archivos compartido y decide si cada envío se convierte en el commit aceptado más reciente. Ese sistema de archivos lo proporciona AWS S3Files, que hace accesible el almacenamiento basado en S3 como archivos y directorios comunes. El almacenamiento se divide en celdas aisladas, cada una con su propio sistema de archivos y sus propias réplicas del servicio de Git. Después de que se acepta un commit, los 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 cuando los agentes cargan o actualizan el proyecto.

A continuación, analizamos 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.

Por lo general, los agentes solo tocan una pequeña fracción de los archivos del proyecto, así que no es necesario materializar todo el repositorio desde el principio. 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 de 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 vale la pena descargarlos. En el caso de documentos como los PDF, el agente lee primero el texto analizado y solo descarga los archivos fuente 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, normalmente requiere capacidades privilegiadas del host, por lo que cada agente tendría que ejecutarse en un entorno aislado con privilegios.

Ampliar

Plano de control: ubicar repositorios y otorgar acceso

El plano de control ubica dónde se almacena cada repositorio y otorga 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 de Git. Cuando un agente comienza a trabajar en un proyecto, la CLI le 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 de Git. El plano de control nunca lee ni escribe datos del repositorio. El servicio de Git decide qué entra en un repositorio.

Servicio de Git: mover datos y coordinar actualizaciones

El servicio de 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 un envoltorio ligero sobre los propios comandos de servicio de Git. Admite el descubrimiento de refs para indicarle al cliente dónde está el head del repositorio, upload-pack para clonar y obtener, y receive-pack para recibir objetos nuevos y una solicitud para 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 listo para usar, para poder crear prototipos de las interfaces del agente y del usuario en paralelo mientras construíamos nuestra propia forja ligera, centrada únicamente en las operaciones de Git que necesitamos.

El servicio consiste en una flota de réplicas, cada una de las cuales es 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 atender cualquiera de sus repositorios, por lo que reemplazar o agregar réplicas no requiere mover datos de repositorios entre servidores. Normalmente, las solicitudes de un repositorio van a la misma réplica para que sus cachés sigan siendo útiles, pero el repositorio no depende de que esa instancia en particular siga disponible.

El paso de aceptación verifica 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 verificaciones mecánicas eviten que crezca demasiado. Los archivos grandes y binarios, como PDF e imágenes, se almacenan mediante Git LFS en lugar de guardarse como blobs de Git sin procesar. La compactación mantiene disponible el historial reciente y, a la vez, limita el tamaño del repositorio. Después de un envío exitoso, la CLI le pregunta al servicio de Git si el repositorio necesita compactación. Si el número de commits conservados supera un umbral, el servicio de Git conserva solo un conjunto más pequeño de los commits más recientes. El historial anterior se reemplaza 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 controla a los escritores concurrentes. Lleva el registro del commit aceptado más reciente, o head. Cuando recibe un envío, lo acepta solo si se construyó sobre ese head. Si no, 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í sin aviso, sin causar ralentizaciones significativas. En nuestros flujos de trabajo de producción, menos del 2% de los envíos se rechazan por 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 de Git también registra cada cambio aceptado. Por cada escritura aceptada, agrega una entrada a una bandeja de salida (outbox), un registro que enumera el repositorio, el nuevo commit, el usuario que hizo el cambio y las rutas que cambiaron. Los servicios posteriores, como el analizador, leen este registro para encontrar trabajo nuevo.

En conjunto, estas piezas forman una capa de administración de repositorios, sin las partes que los agentes no necesitan. Los pull requests son innecesarios, porque ninguna persona revisa cada cambio. En su lugar, el servicio de Git verifica 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 verificaciones deterministas mantienen cada repositorio dentro de su contrato, en lugar de depender de un operador humano para administrar el crecimiento.

Almacenamiento: mantener el trabajo de forma duradera

La capa de almacenamiento guarda de forma duradera los datos de los repositorios, independientemente de los entornos aislados y de las réplicas del servicio de 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 bare de Git en el sistema de archivos compartido, que contiene los objetos y las referencias del repositorio en lugar de una copia 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 está en riesgo el trabajo que no se ha enviado.

En cambio, podríamos darle 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 ataría el cómputo de los agentes al lugar donde se ejecuta la máquina y requerirí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 administradas 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 agregados 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, deriva los archivos modificados a partir de los metadatos del commit y obtiene los bytes sin procesar mediante el hash del contenido. Luego analiza el documento para producir 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 fuente. Estos artefactos nunca se agregan como commits al repositorio, ya que eso contaminaría innecesariamente el historial y aumentaría el número de escrituras concurrentes. En cambio, los resultados del análisis llegan a un entorno aislado mediante el checkout y la sincronización. Cada checkout incluye un directorio reservado que la CLI usa para materializar los artefactos. El análisis ocurre de forma asíncrona, por lo que un 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 un flujo fijo de buscar y luego leer, listan carpetas, buscan en el contenido de los archivos con grep, leen los pasajes relevantes y usan lo que encuentran para decidir dónde buscar a continuación.

Al igual que Computer, Search usa 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 los archivos relevantes y fragmentos de apoyo. Luego, el modelo que responde lee los archivos seleccionados y genera la respuesta. Reutilizar un entorno aislado de proyecto existente reduce el tiempo de configuración: conectarse a un checkout en caliente tarda unos 2.9 segundos, en comparación con aproximadamente 8 segundos en un arranque en frío.

Ampliar

El texto analizado permite buscar en documentos más grandes, como PDF y archivos de Office, con las mismas herramientas. Primero, el agente consulta un manifiesto, una lista que muestra qué documentos tienen texto extraído disponible, y luego busca y lee ese texto como archivos comunes. Descarga el documento original solo cuando el texto no es suficiente, por ejemplo, para examinar figuras, el diseño o datos incrustados.

Comparamos este enfoque con la búsqueda semántica sobre un índice, usando 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: cerca de 1.7 veces mejor en las respuestas y 2 veces mejor en la recuperación, con una latencia aproximadamente 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 comunes, 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 informa las actualizaciones aceptadas a los servicios posteriores. Las personas y los agentes pueden aprovechar el trabajo de los demás, con un registro de cómo evolucionó el conocimiento.

Conclusión

Cuando las personas y los agentes comparten un proyecto, el espacio de trabajo hace más que almacenar archivos. Ofrece un lugar común para combinar contribuciones y llevar un registro de lo que cambió. Git ya proporciona gran parte de esa base. Nosotros agregamos coordinación y verificaciones 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 la colaboración entre agentes y el desarrollo de software con múltiples colaboradores son, en el fondo, 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 que los agentes elijan qué obtener y los archivos comunes 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 confiable y comprensible para las personas. El objetivo es sencillo: cada cambio debe durar más 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}
}