Slik bygger vi delte arbeidsområder for mennesker og agenter

Vi lanserte nylig prosjekter, en funksjon der mennesker og agenter samarbeider om langvarige oppgaver i Perplexity Computer. Hvert prosjekt ligger på et delt arbeidsområde med et filsystem som samler kontekst på tvers av økter, agenter og brukere. Flerbrukersamarbeid som strekker seg over måneder, krever persistens, samtidighet og sporbarhet:

• Persistens: Arbeidet skal vare lenger enn en enkelt agentøkt eller sandbox, slik at den samme brukeren eller agenten kan fortsette det senere, og alle samarbeidspartnere kan bygge videre på det.
• Samtidighet: Flere brukere i samme prosjekt kan hver ha flere agenter som gjør redigeringer parallelt, og som fører en felles tilstand videre i stedet for å overskrive hverandre.
• Sporbarhet: Både brukere og agenter skal kunne se historikken, slik at de kan sjekke hvem som har endret hva siden forrige økt uten å lese hele prosjektet på nytt, og rulle tilbake redigeringer ved behov.

Disse utfordringene er velkjente for programvareutviklere. Git-forger oppstod for flere tiår siden for å oppfylle nettopp disse kravene: en driftet tjeneste som kombinerer versjonskontroll med samarbeidsfunksjoner, slik at mange bidragsytere kan samles om én felles sannhetskilde. Filsystemet bak prosjekter er en slik Git-forge, bygget for samarbeid mellom mennesker og agenter og mellom agenter.

Forstørr

Arkitektur

Git håndterer allerede persistens, samtidighet og sporbarhet. Git identifiserer hver fil ut fra innholdet, så uendrede filer lagres bare én gang, og lagrede kopier blir aldri utdaterte. Hver commit lagrer alle oppdaterte filer på én gang, så samarbeidspartnere ser aldri en halvferdig tilstand. Når to skrivere kolliderer, kan den som tapte, bruke endringene sine på nytt på den nye versjonen og prøve igjen. Kjeden av commits viser hvem som endret hva, og gjør det enkelt å gjenopprette tidligere versjoner. Det agenter ikke trenger, er resten av en forge bygget for mennesker, som gjennomgangsskjermer, grenadministrasjon og varsler.

Arkitekturen vår kjører hele prosessen i skyen og støtter alle former for kunnskapsarbeid utover koding. Hvert Computer-prosjekt bygger på et Git-repositorium som betjenes av fem komponenter:

• CLI-en vedlikeholder lokale utsjekkinger, synkroniserer oppdateringer og sender inn agentens endringer i hver sandbox.
• Kontrollplanet finner prosjektrepositoriet og utsteder kortvarig legitimasjon for å få tilgang til det.
• Git-tjenesten sender repositoriedata til sandboxer, mottar innsendingene deres og avgjør hvilken innsending som blir den siste godkjente commiten.
• Lagring basert på AWS S3 lagrer repositoriedata varig.
• Nedstrømsbehandling henter ut tekst og annen nyttig informasjon fra lagrede dokumenter og gjør den tilgjengelig når agenter laster inn eller oppdaterer prosjektet.

Hver agent har sin egen isolerte sandbox. Inne i denne sandboxen arbeider den med en lokal kopi av repositoriet, administrert av en liten CLI. CLI-en ber kontrollplanet om å finne repositoriet, og henter og sender deretter inn endringer via Git-tjenesten. En agentproxy kontrollerer tilgangen for forespørsler fra sandboxer før de når Git-tjenesten. Git-tjenesten leser og skriver repositorier på et delt filsystem og avgjør om hver innsending blir den siste godkjente commiten. Dette filsystemet leveres av AWS S3Files, som gjør S3-basert lagring tilgjengelig som vanlige filer og mapper. Lagringen er delt inn i isolerte celler, hver med sitt eget filsystem og egne replikaer av Git-tjenesten. Etter at en commit er godkjent, henter bakgrunnsarbeidere ut tekst og annen nyttig informasjon fra endrede dokumenter, lagrer resultatene atskilt fra repositoriehistorikken og gjør dem tilgjengelige når agenter laster inn eller oppdaterer prosjektet.

Nå går vi gjennom komponentene én etter én.

Forstørr

CLI: arbeid med lokale filer i sandboxer

Agentene kjører i SPACE, vår egenutviklede sandboxplattform. Hver sandbox har en liten CLI som materialiserer repositoriet og holder det synkronisert. For hver meningsfulle arbeidsenhet agenten utfører, sender CLI-en inn endringene som en commit.

Agenter berører vanligvis bare en liten del av prosjektfilene, så det er ikke nødvendig å materialisere hele repositoriet på forhånd. CLI-en materialiserer derfor lat: Store filer og binærfiler som lagres via Git Large File Storage (LFS), kommer som små pekerfiler som lagrer objektets faktiske størrelse, slik at agenten kan bruke navnet og størrelsen til å avgjøre om en nedlasting er verdt det. For dokumenter som PDF-er leser agenten den parsede teksten først og laster bare ned kildefilene når det er nødvendig.

Et annet naturlig alternativ ville vært å bruke et virtuelt filsystem. Vi testet en FUSE-basert implementering, men den var omtrent 400 ganger tregere enn lokale filer på filsystemtunge arbeidsbelastninger, siden hver forespørsel krever en rundtur over nettverket. Den krever dessuten vanligvis privilegerte rettigheter fra verten, så hver agent måtte ha kjørt i en privilegert sandbox.

Forstørr

Kontrollplanet: lokalisering av repositorier og utstedelse av tilgang

Kontrollplanet finner ut hvor hvert repositorium er lagret, og utsteder tilgang til det. Når et repositorium opprettes, tilordner kontrollplanet det til en lagringscelle, en isolert lagringsenhet med egne replikaer av Git-tjenesten. Når en agent begynner å arbeide med et prosjekt, spør CLI-en kontrollplanet hvor repositoriet er lagret. Kontrollplanet returnerer plasseringen og midlertidig legitimasjon for Git-tjenesten. Kontrollplanet leser eller skriver aldri repositoriedata. Det er Git-tjenesten som avgjør hva som kommer inn i et repositorium.

Git-tjenesten: flytting av data og koordinering av oppdateringer

Git-tjenesten utfører Git-operasjoner og overfører repositorieinnhold og versjonshistorikk mellom sandboxer og lagring. Den er en tynn innpakning rundt Gits egne serverkommandoer. Den støtter ref-oppdagelse for å fortelle klienten hvor repositoriets head er, upload-pack for kloning og henting, og receive-pack for å motta nye objekter og en forespørsel om å flytte repositoriets head fremover. Den betjener også Git LFS-API-et: For store filer og binærfiler utsteder den kortvarige lenker, slik at sandboxer kan laste disse filene opp og ned direkte fra S3.

Vi startet med en ferdig forge-server, slik at vi kunne lage prototyper av agent- og brukergrensesnittene parallelt med at vi bygde vår egen lettvektsforge, som bare fokuserer på Git-operasjonene vi trenger.

Tjenesten består av en flåte av replikaer, der hver er en kjørende instans av den samme serveren. En celle samler delt lagring med et sett replikaer og tilhørende støttetjenester. Replikaene i en celle kan dermed få tilgang til det samme delte filsystemet i stedet for å vedlikeholde uavhengige kopier av hvert repositorium.

Denne delte lagringen gjør at replikaene kan forbli tilstandsløse. Enhver replika i cellen kan betjene alle cellens repositorier, så det å erstatte eller legge til replikaer krever ikke at repositoriedata flyttes mellom servere. Forespørsler for et repositorium går normalt til samme replika for å holde hurtigbufferne nyttige, men repositoriet er ikke avhengig av at akkurat den instansen forblir tilgjengelig.

Godkjenningstrinnet kontrollerer repositoriets invarianter for å sikre at en godkjent commit utgjør en gyldig repositorietilstand. Vi definerer en eksplisitt kontrakt for hvert repositorium, slik at mekaniske kontroller kan hindre det i å vokse seg for stort. Store filer og binærfiler, som PDF-er og bilder, lagres via Git LFS i stedet for som rå Git-blobber. Kompaktering holder nyere historikk tilgjengelig og begrenser samtidig størrelsen på repositoriet. Etter en vellykket innsending spør CLI-en Git-tjenesten om repositoriet trenger kompaktering. Hvis antallet bevarte commits overstiger en terskel, beholder Git-tjenesten bare et mindre utvalg av de nyeste commitene. Eldre historikk erstattes med ett enkelt øyeblikksbilde som utgangspunkt, og de nyeste commitene spilles av på nytt for å oppdatere commit-identifikatorene.

Forstørr

Et enkelt synkroniseringstrinn håndterer samtidige skrivere. Det holder styr på den siste godkjente commiten, også kalt head. Når det mottar en innsending, godtar det den bare hvis innsendingen er bygget på denne head-commiten. Hvis ikke, sender det et strukturert svar om utdatert base; taperen må da spille av endringen sin på nytt oppå den nye head-commiten og sende inn på nytt. Denne utformingen sikrer at samtidige agenter ikke i det stille overskriver hverandre, uten å føre til betydelige forsinkelser. I produksjonsarbeidsflytene våre avvises færre enn 2 % av innsendingene som utdaterte. Samlet sett er medianforsinkelsen for innsending under 1,7 sekunder, og p99-forsinkelsen er under 8 sekunder.

Forstørr

Git-tjenesten registrerer også hver godkjente endring. For hver godkjente skriving legger den til en oppføring i en utboks, en logg som viser repositoriet, den nye commiten, brukeren som gjorde endringen, og banene som ble endret. Nedstrømstjenester som parseren leser denne loggen for å finne nytt arbeid.

Sammen utgjør disse delene et lag for repositorieadministrasjon, uten de delene agentene ikke trenger. Pull requests er unødvendige, fordi ingen mennesker gjennomgår hver endring. I stedet kontrollerer Git-tjenesten kontrakten ved innsending, agenten som taper et kappløp, bruker sin egen endring på nytt, og commit-historikken registrerer hvem som endret hva. Deterministiske kontroller holder hvert repositorium innenfor kontrakten, i stedet for at en menneskelig operatør må styre veksten.

Lagring: varig oppbevaring av arbeidet

Lagringslaget lagrer repositoriedata varig, uavhengig av sandboxene og replikaene av Git-tjenesten. Repositoriene ligger på AWS S3Files, som eksponerer S3-basert lagring via et filsystemgrensesnitt som standard Git kan bruke uten endringer. Hvert repositorium er et bart Git-repositorium på det delte filsystemet, som inneholder repositoriets objekter og referanser i stedet for en arbeidskopi.

Ved å skille lagring og databehandling kan sandboxene forbli flyktige. Hver agent får sin egen sandbox, og mange agenter kan arbeide i samme prosjekt uten å dele en maskin. Hvis en sandbox krasjer, er det bare arbeid som ikke er sendt inn, som står i fare.

Vi kunne i stedet gitt hvert prosjekt en langlivet sandbox som alle prosjektets agenter deler, slik at prosjektets filer lå på maskinens disk. Dette ville imidlertid knyttet agentenes databehandling til der maskinen kjører, og krevd at den var dimensjonert for de travleste periodene. Maskinen måtte dessuten fungere stabilt i flere måneder, med sikkerhetskopiering og gjenoppretting håndtert som en del av prosjektets lagringssystem.

Forstørr

Nedstrømsbehandling: slik blir dokumenter lesbare for agenter

Den viktigste nedstrømskomponenten er en parsingspipeline som henter ut tekst og metadata fra nylig tillagte eller oppdaterte dokumenter, slik at prosjektfilene blir lett lesbare for agenter. En parserarbeider henter oppdateringer fra endringsstrømkøen, utleder de endrede filene fra commit-metadataene og henter de rå bytene ved hjelp av innholdshashen. Deretter parser den dokumentet for å produsere den uttrukne teksten og dokumentmetadataene.

Parsede resultater ligger utenfor repositoriet, i et lager med kildedokumentets hash som nøkkel. Disse artefaktene committes aldri tilbake til repositoriet, siden det unødvendig ville forurenset historikken og økt antallet samtidige skrivinger. I stedet når de parsede resultatene en sandbox via utsjekking og synkronisering. Hver utsjekking inneholder en reservert mappe som CLI-en bruker til å materialisere artefakter. Parsingen skjer asynkront, så en parserarbeider i bakgrunnen blokkerer ikke utsjekkinger.

Slik bruker agentene arbeidsområdet

Agentene utforsker repositorieversjonen som er lastet inn i sandboxen, med vanlige filsystemverktøy. I stedet for å følge en fast pipeline med først søk og deretter lesing, lister de opp mapper, søker i filinnhold med grep, leser relevante avsnitt og bruker det de finner, til å bestemme hvor de skal lete videre.

I likhet med Computer bruker Search den samme tilnærmingen via sine vanlige filverktøy. En separat utforskningsagent søker i prosjektet innenfor et mer begrenset budsjett og returnerer relevante filbaner og støttende utdrag. Svarmodellen leser deretter de valgte filene og genererer svaret. Gjenbruk av en eksisterende prosjektsandbox reduserer oppsettstiden: Å koble seg til en varm utsjekking tar omtrent 2,9 sekunder, sammenlignet med omtrent 8 sekunder for en kald oppstart.

Forstørr

Parset tekst gjør større dokumenter, som PDF-er og Office-filer, søkbare med de samme verktøyene. Agenten sjekker først et manifest, en liste som viser hvilke dokumenter som har uttrukket tekst tilgjengelig, og søker deretter i og leser denne teksten som vanlige filer. Den laster bare ned originaldokumentet når teksten ikke er tilstrekkelig, for eksempel for å undersøke figurer, layout eller innebygde data.

Vi sammenlignet denne tilnærmingen med semantisk søk over en indeks på 150 finansspørsmål om enkeltdokumenter i det samme korpuset. Utforskningsagenten fikk 0,867 for å hente riktig dokument og 0,627 for å svare riktig, mot omtrent 0,39 og 0,37 for semantisk søk – omtrent 1,7 ganger bedre på svar og 2 ganger bedre på gjenfinning, med omtrent 25 % lavere forsinkelse. Utforskningsagenten jobber hovedsakelig med uttrukket tekst og laster sjelden ned de originale PDF-ene.

Forstørr

Én felles infrastruktur

Det vedvarende minnet i Computer bruker den samme filsysteminfrastrukturen. Perplexity Brain, kunnskapswikien i Computer, lagrer minne i kunnskapsrepositorier med egen historikk og egne retningslinjer. Når kunnskap holdes atskilt fra prosjektfilene, konkurrerer ikke minneoppdateringer i bakgrunnen med redigeringer av disse filene. En økt som trenger begge, laster inn begge repositoriene.

Bakgrunnsagenter leser eksisterende kunnskap, innarbeider ny informasjon og lagrer oppdaterte sider som commits. Andre agenter leser disse sidene med vanlige filverktøy, og mennesker kan også redigere dem. Skriverne deler arbeidet sitt via repositoriet i stedet for å koordinere direkte med hver leser. Commit-historikken registrerer hvem som endret hva, mens utboksen rapporterer godkjente oppdateringer til nedstrømstjenester. Mennesker og agenter kan bygge videre på hverandres arbeid, med en oversikt over hvordan kunnskapen har utviklet seg.

Konklusjon

Når mennesker og agenter deler et prosjekt, gjør arbeidsområdet mer enn å lagre filer. Det gir et felles sted for å samle bidrag og spore hva som er endret. Git leverer allerede mye av dette grunnlaget. Vi legger til koordinering og automatiserte kontroller, slik at agenter kan sende inn arbeid uten at en person må godkjenne hver oppdatering. Resultatet er en forge strippet ned til det essensielle, fordi samarbeid mellom agenter og programvareutvikling med mange bidragsytere i bunn og grunn er det samme problemet.

Agenter arbeider i uavhengige, midlertidige sandboxer mens de bidrar til varige repositorier. Begrensninger på repositoriene holder veksten håndterbar, eksplisitte nedlastinger lar agentene velge hva de skal hente, og vanlige filer lar dem utforske med kjente verktøy. Bakgrunnsoppdateringer, interaktive redigeringer og planlagte oppgaver kan bygge videre på hverandres arbeid uten å koordinere direkte.

Etter hvert som flere agenter arbeider selvstendig i prosjekter, må det delte arbeidsområdet deres forbli pålitelig og forståelig for mennesker. Målet er enkelt: Hver endring skal vare lenger enn agenten som laget den, bli tilgjengelig for neste samarbeidspartner og etterlate en tydelig oversikt over hva som ble endret.

Sitering

@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}
}