Gedeelde werkruimten bouwen voor mensen en agents

We hebben onlangs Projecten gelanceerd, waar mensen en agents samenwerken aan langlopende taken in Perplexity Computer. Elk project draait op een gedeelde werkruimte met een bestandssysteem dat context verzamelt over sessies, agents en gebruikers heen. Samenwerking met meerdere deelnemers die maanden beslaat, vereist persistentie, gelijktijdigheid en traceerbaarheid:

• Persistentie: werk moet duurzaam blijven, los van een individuele agentsessie of sandbox, zodat dezelfde gebruiker of agent het later kan voortzetten en andere bijdragers erop kunnen voortbouwen.
• Gelijktijdigheid: meerdere gebruikers in hetzelfde project kunnen elk meerdere agents parallel bewerkingen laten uitvoeren die een gedeelde toestand vooruithelpen in plaats van elkaar te overschrijven.
• Traceerbaarheid: zowel gebruikers als agents moeten de geschiedenis kunnen inzien, zodat ze kunnen nagaan wie wat heeft gewijzigd sinds hun laatste sessie zonder het hele project opnieuw te lezen, en bewerkingen kunnen terugdraaien wanneer dat nodig is.

Deze uitdagingen komen softwareontwikkelaars bekend voor. Git-forges zijn decennia geleden ontstaan om aan deze eisen te voldoen: een gehoste service die versiebeheer combineert met samenwerkingsfuncties, zodat veel bijdragers kunnen samenkomen rond één gezaghebbende bron. Het bestandssysteem achter Projecten is zo'n Git-forge, gebouwd voor samenwerking tussen mensen en agents en tussen agents onderling.

Vergroten

Architectuur

Git regelt persistentie, gelijktijdigheid en traceerbaarheid al. Het identificeert elk bestand aan de hand van de inhoud, zodat ongewijzigde bestanden maar één keer worden bewaard en opgeslagen kopieën nooit verouderen. Elke commit slaat alle bijgewerkte bestanden in één keer op, zodat bijdragers nooit een half afgemaakte toestand zien. Wanneer twee schrijvers botsen, kan degene die verloor zijn wijzigingen opnieuw toepassen op de nieuwe versie en het nogmaals proberen. De keten van commits laat zien wie wat heeft gewijzigd en maakt het eenvoudig om eerdere versies te herstellen. Wat agents niet nodig hebben, is de rest van een forge die voor mensen is gebouwd, zoals reviewschermen, branchbeheer en meldingen.

Onze architectuur voert het hele proces uit in de cloud en ondersteunt alle vormen van kenniswerk, ook buiten programmeren. Achter elk Computer-project staat een Git-repository die wordt aangeboden door 5 componenten:

• CLI beheert in elke sandbox lokale checkouts, synchroniseert updates en dient de wijzigingen van de agent in.
• Control plane lokaliseert de projectrepository en geeft kortlevende inloggegevens uit om deze te bereiken.
• Git-service stuurt repositorygegevens naar sandboxes, ontvangt hun indieningen en bepaalt welke indiening de laatst geaccepteerde commit wordt.
• Opslag op basis van AWS S3 bewaart repositorygegevens duurzaam.
• Downstreamverwerking haalt tekst en andere nuttige informatie uit opgeslagen documenten en maakt die beschikbaar wanneer agents het project laden of vernieuwen.

Elke agent heeft een eigen geïsoleerde sandbox. Binnen die sandbox werkt de agent met een lokale kopie van de repository, beheerd door een kleine CLI. De CLI vraagt het control plane om de repository te lokaliseren en haalt vervolgens wijzigingen op en dient ze in via de Git-service. Een agentproxy controleert de toegang van sandboxverzoeken voordat ze de Git-service bereiken. De Git-service leest en schrijft repository's op een gedeeld bestandssysteem en bepaalt of elke indiening de laatst geaccepteerde commit wordt. Dat bestandssysteem wordt geleverd door AWS S3Files, dat S3-opslag toegankelijk maakt als gewone bestanden en mappen. De opslag is verdeeld in geïsoleerde cellen, elk met een eigen bestandssysteem en eigen replica's van de Git-service. Nadat een commit is geaccepteerd, halen achtergrondworkers tekst en andere nuttige informatie uit gewijzigde documenten. Ze slaan de resultaten gescheiden van de repositorygeschiedenis op en maken ze beschikbaar wanneer agents het project laden of vernieuwen.

Hierna bespreken we de onderdelen een voor een.

Vergroten

CLI: werken met lokale bestanden in sandboxes

Agents draaien in SPACE, ons eigen sandboxplatform. Elke sandbox heeft een kleine CLI die de repository materialiseert en gesynchroniseerd houdt. Voor elke betekenisvolle eenheid werk die de agent uitvoert, dient de CLI de wijzigingen in als een commit.

Agents raken doorgaans maar een klein deel van de projectbestanden aan, dus het is niet nodig om de hele repository vooraf te materialiseren. Daarom materialiseert de CLI lazy, dus pas wanneer dat nodig is: grote en binaire bestanden die via Git Large File Storage (LFS) zijn opgeslagen, komen binnen als kleine pointerbestanden met de werkelijke grootte van het object, zodat de agent op basis van de naam en grootte kan beslissen of een download de moeite waard is. Bij documenten zoals pdf's leest de agent eerst geparste tekst en downloadt hij de bronbestanden alleen als dat nodig is.

Een andere voor de hand liggende optie zou een virtueel bestandssysteem zijn. We hebben een op FUSE gebaseerde implementatie getest, maar die was bij bestandssysteemintensieve workloads ongeveer 400 keer trager dan lokale bestanden, omdat elk verzoek een netwerkroundtrip vereist. Daarnaast vereist het doorgaans geprivilegieerde rechten van de host, waardoor elke agent in een geprivilegieerde sandbox zou moeten draaien.

Vergroten

Control plane: repository's lokaliseren en toegang verlenen

Het control plane bepaalt waar elke repository is opgeslagen en verleent er toegang toe. Wanneer een repository wordt aangemaakt, wijst het control plane deze toe aan een opslagcel: een geïsoleerde opslageenheid met eigen replica's van de Git-service. Wanneer een agent aan een project begint, vraagt de CLI het control plane waar de repository is opgeslagen. Het control plane retourneert de locatie en tijdelijke inloggegevens voor de Git-service. Het control plane leest of schrijft nooit repositorygegevens. De Git-service bepaalt wat er in een repository terechtkomt.

Git-service: gegevens verplaatsen en updates coördineren

De Git-service voert Git-bewerkingen uit en draagt repository-inhoud en versiegeschiedenis over tussen sandboxes en opslag. Het is een dunne wrapper rond de eigen servercommando's van Git. De service ondersteunt ref discovery om de client te vertellen waar de head van de repository zich bevindt, upload-pack voor klonen en ophalen, en receive-pack voor het ontvangen van nieuwe objecten en een verzoek om de head van de repository te verplaatsen. Daarnaast bedient de service de Git LFS-API: voor grote en binaire bestanden geeft ze kortlevende links uit, zodat sandboxes die bestanden rechtstreeks naar en van S3 kunnen uploaden en downloaden.

We zijn begonnen met een kant-en-klare forgeserver, zodat we de interfaces voor agents en gebruikers konden prototypen terwijl we parallel onze eigen lichtgewicht forge bouwden, uitsluitend gericht op de Git-bewerkingen die we nodig hebben.

De service bestaat uit een vloot replica's, die elk een actieve instantie van dezelfde server zijn. Een cel groepeert gedeelde opslag met een set replica's en hun ondersteunende services. Replica's binnen een cel hebben zo toegang tot hetzelfde gedeelde bestandssysteem, in plaats van elk onafhankelijke kopieën van elke repository bij te houden.

Dankzij deze gedeelde opslag kunnen de replica's stateless blijven. Elke replica in de cel kan elk van de repository's van die cel bedienen, dus voor het vervangen of toevoegen van replica's hoeven geen repositorygegevens tussen servers te worden verplaatst. Verzoeken voor een repository gaan normaal gesproken naar dezelfde replica, zodat de caches nuttig blijven, maar de repository is er niet van afhankelijk dat die specifieke instantie beschikbaar blijft.

De acceptatiestap controleert repository-invarianten om te garanderen dat een geaccepteerde commit een geldige repositorystatus is. We definiëren voor elke repository een expliciet contract, zodat mechanische controles kunnen voorkomen dat deze te groot wordt. Grote en binaire bestanden, zoals pdf's en afbeeldingen, worden via Git LFS opgeslagen in plaats van als onbewerkte Git-blobs. Compactie houdt recente geschiedenis beschikbaar en beperkt tegelijk de omvang van de repository. Na een geslaagde indiening vraagt de CLI de Git-service of de repository gecompacteerd moet worden. Als het aantal bewaarde commits een drempelwaarde overschrijdt, bewaart de Git-service alleen een kleinere set van de meest recente commits. Oudere geschiedenis wordt vervangen door één startsnapshot, en de recente commits worden opnieuw afgespeeld om de commit-ID's bij te werken.

Vergroten

Een eenvoudige synchronisatiestap houdt rekening met gelijktijdige schrijvers. Die stap houdt de laatst geaccepteerde commit bij, oftewel de head. Wanneer de stap een indiening ontvangt, wordt die alleen geaccepteerd als ze op die head is gebouwd. Zo niet, dan stuurt de stap een gestructureerde stale-base-respons; de verliezer moet zijn wijziging dan opnieuw afspelen bovenop de nieuwe head en opnieuw indienen. Dit ontwerp zorgt ervoor dat gelijktijdige agents elkaar niet ongemerkt overschrijven, zonder noemenswaardige vertraging te veroorzaken. In onze productieworkflows wordt minder dan 2% van de indieningen als verouderd afgewezen. Over het geheel genomen ligt de mediane indieningslatentie onder 1,7 seconde en de p99-latentie onder 8 seconden.

Vergroten

De Git-service registreert ook elke geaccepteerde wijziging. Voor elke geaccepteerde schrijfbewerking voegt de service een item toe aan een outbox: een logboek met de repository, de nieuwe commit, de gebruiker die de wijziging heeft aangebracht en de gewijzigde paden. Downstreamservices zoals de parser lezen dit logboek om nieuw werk te vinden.

Samen vormen deze onderdelen een laag voor repositorybeheer, zonder de onderdelen die agents niet nodig hebben. Pull requests zijn overbodig, omdat geen mens elke wijziging beoordeelt. In plaats daarvan controleert de Git-service het contract bij het indienen, past de agent die een race verliest zijn eigen wijziging opnieuw toe en legt de commitgeschiedenis vast wie wat heeft gewijzigd. Deterministische controles houden elke repository binnen zijn contract, in plaats van te vertrouwen op een menselijke beheerder om de groei te beheersen.

Opslag: werk duurzaam bewaren

De opslaglaag bewaart repositorygegevens duurzaam, onafhankelijk van de sandboxes en de replica's van de Git-service. Repository's staan op AWS S3Files, dat S3-opslag beschikbaar maakt via een bestandssysteeminterface die standaard-Git zonder aanpassingen kan gebruiken. Elke repository is een bare Git-repository op het gedeelde bestandssysteem, met de objecten en referenties van de repository in plaats van een uitgecheckte werkkopie.

Door opslag en rekenkracht te ontkoppelen, kunnen sandboxes kortstondig blijven. Elke agent krijgt een eigen sandbox, en veel agents kunnen aan hetzelfde project werken zonder een machine te delen. Als een sandbox crasht, loopt alleen werk dat nog niet is ingediend risico.

We zouden elk project ook een langlevende sandbox kunnen geven die door al zijn agents wordt gedeeld, zodat de projectbestanden op de schijf van die machine staan. Dat zou de rekenkracht van de agents echter koppelen aan de plek waar die machine draait, en de machine zou moeten zijn afgestemd op de drukste periodes. Ook zou ze maandenlang gezond moeten blijven, met back-ups en herstel die worden beheerd als onderdeel van het opslagsysteem van het project.

Vergroten

Downstreamverwerking: documenten leesbaar maken voor agents

Het belangrijkste downstreamonderdeel is een parserpijplijn die tekst en metadata uit nieuw toegevoegde of bijgewerkte documenten haalt, zodat agents de projectbestanden gemakkelijk kunnen lezen. Een parserworker verwerkt updates uit de wachtrij van de wijzigingsstroom, leidt de gewijzigde bestanden af uit de commitmetadata en haalt de onbewerkte bytes op met behulp van de inhoudshash. Vervolgens parseert de worker het document om de geëxtraheerde tekst en documentmetadata te produceren.

Geparste uitvoer staat buiten de repository, in een opslag met de hash van het brondocument als sleutel. Deze artefacten worden nooit teruggecommit naar de repository, omdat dat de geschiedenis onnodig zou vervuilen en het aantal gelijktijdige schrijfbewerkingen zou verhogen. In plaats daarvan bereikt de geparste uitvoer een sandbox via checkout en synchronisatie. Elke checkout bevat een gereserveerde map die de CLI gebruikt om artefacten te materialiseren. Parsen gebeurt asynchroon, zodat een parserworker op de achtergrond checkouts niet blokkeert.

Hoe agents de werkruimte gebruiken

Agents verkennen met standaard bestandssysteemtools de repositoryversie die in de sandbox is geladen. In plaats van een vaste pijplijn van eerst zoeken en dan lezen te volgen, bekijken ze de inhoud van mappen, doorzoeken ze bestandsinhoud met grep, lezen ze relevante passages en gebruiken ze wat ze vinden om te bepalen waar ze vervolgens kijken.

Net als Computer gebruikt Search dezelfde aanpak via de standaard bestandstools. Een aparte verkenningsagent doorzoekt het project binnen een beperkter budget en retourneert relevante bestandspaden en ondersteunende fragmenten. Het antwoordmodel leest vervolgens de geselecteerde bestanden en genereert het antwoord. Het hergebruiken van een bestaande projectsandbox verkort de opstarttijd: koppelen aan een warme checkout duurt ongeveer 2,9 seconden, tegenover ongeveer 8 seconden bij een koude start.

Vergroten

Dankzij geparste tekst zijn grotere documenten zoals pdf's en Office-bestanden doorzoekbaar met dezelfde tools. De agent controleert eerst een manifest, een lijst die aangeeft voor welke documenten geëxtraheerde tekst beschikbaar is, en doorzoekt en leest die tekst vervolgens als gewone bestanden. Het originele document wordt alleen gedownload als de tekst niet volstaat, bijvoorbeeld om afbeeldingen, de opmaak of ingesloten gegevens te bekijken.

We hebben deze aanpak gebenchmarkt tegen semantisch zoeken in een index, met 150 financiële vragen over één document binnen hetzelfde corpus. De verkenningsagent scoorde 0,867 op het vinden van het juiste document en 0,627 op het correct beantwoorden, tegenover ongeveer 0,39 en 0,37 voor semantisch zoeken: ongeveer 1,7 keer beter bij antwoorden en 2 keer beter bij het ophalen, met een circa 25% lagere latentie. De verkenningsagent werkt voornamelijk met geëxtraheerde tekst en downloadt zelden de originele pdf's.

Vergroten

Eén gedeelde infrastructuur

Het persistente geheugen van Computer gebruikt dezelfde bestandssysteeminfrastructuur. Perplexity Brain, de kenniswiki van Computer, slaat geheugen op in kennisrepository's met een eigen geschiedenis en eigen beleid. Doordat kennis gescheiden blijft van projectbestanden, concurreren geheugenupdates op de achtergrond niet met bewerkingen van die bestanden. Een sessie die beide nodig heeft, laadt beide repository's.

Agents op de achtergrond lezen bestaande kennis, verwerken nieuwe informatie en slaan bijgewerkte pagina's op als commits. Andere agents lezen die pagina's met gewone bestandstools, en mensen kunnen ze ook bewerken. Schrijvers delen hun werk via de repository in plaats van rechtstreeks met elke lezer te coördineren. De commitgeschiedenis legt vast wie wat heeft gewijzigd, terwijl de outbox geaccepteerde updates doorgeeft aan downstreamservices. Mensen en agents kunnen voortbouwen op elkaars werk, met een overzicht van hoe de kennis zich heeft ontwikkeld.

Conclusie

Wanneer mensen en agents een project delen, doet de werkruimte meer dan bestanden opslaan. Ze biedt een gemeenschappelijke plek om bijdragen samen te voegen en bij te houden wat er is gewijzigd. Git levert al een groot deel van die basis. Wij voegen coördinatie en geautomatiseerde controles toe, zodat agents werk kunnen indienen zonder dat een persoon elke update hoeft goed te keuren. Het resultaat is een forge die is teruggebracht tot de essentie, want samenwerking tussen agents en softwareontwikkeling met meerdere bijdragers zijn in de kern hetzelfde probleem.

Agents werken in onafhankelijke, tijdelijke sandboxes en dragen tegelijk bij aan duurzame repository's. Repositorylimieten houden de groei beheersbaar, expliciete downloads laten agents kiezen wat ze ophalen en gewone bestanden laten hen verkennen met vertrouwde tools. Achtergrondupdates, interactieve bewerkingen en geplande taken kunnen voortbouwen op elkaars werk zonder directe coördinatie.

Naarmate meer agents autonoom binnen Projecten werken, moet hun gedeelde werkruimte betrouwbaar en begrijpelijk blijven voor mensen. Het doel is eenvoudig: elke wijziging moet duurzamer zijn dan de agent die haar heeft gemaakt, beschikbaar komen voor de volgende bijdrager en een duidelijk overzicht achterlaten van wat er is gewijzigd.

Bronvermelding

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