Perplexity SPACE: το runtime που κρατά τους AI agents ζωντανούς χωρίς μόνιμα sandboxes

Η Perplexity παρουσίασε στις 15 Ιουλίου 2026 το SPACE, συντομογραφία του Sandboxed Platform for Agentic Code Execution. Πρόκειται για τη νέα υποδομή εκτέλεσης πίσω από το Perplexity Computer, σχεδιασμένη για agents που γράφουν και τρέχουν κώδικα, επεξεργάζονται αρχεία και συνεχίζουν μια εργασία για ώρες ή ημέρες. Η βασική ιδέα δεν είναι απλώς ένα ταχύτερο sandbox. Είναι ο διαχωρισμός του μακρόβιου session από το προσωρινό execution environment που το εξυπηρετεί.

Στο Computer, κάθε task εκτελείται σε απομονωμένο Firecracker microVM με δικό του guest kernel. Το συγκεκριμένο VM μπορεί να παύσει ή να καταστραφεί, χωρίς να χάνεται αναγκαστικά η ταυτότητα και η πρόοδος του session. Το state διατηρείται με snapshots, ώστε η εργασία να μπορεί να συνεχιστεί σε άλλο sandbox, να επιστρέψει σε προηγούμενο σημείο ή να διακλαδωθεί. Αυτό μετατρέπει το sandbox από μόνιμο «σπίτι» του agent σε αναλώσιμο compute resource.

Γιατί οι μακροχρόνιοι agents χρειάζονται διαφορετικό runtime

Τα παραδοσιακά sandboxes είναι συνήθως βελτιστοποιημένα για σύντομα, stateless jobs: ξεκινούν ένα environment, εκτελούν μια εντολή και το απομακρύνουν. Ένας agent, όμως, μπορεί να εγκαταστήσει dependencies, να δημιουργήσει αρχεία, να κρατά διεργασίες ενεργές και να περιμένει ανθρώπινη έγκριση πριν συνεχίσει. Αν το environment χαθεί, η ανακατασκευή του από το μηδέν κοστίζει χρόνο και μπορεί να αλλάξει το αποτέλεσμα.

Η Perplexity αντιμετωπίζει αυτό το πρόβλημα με ένα ρητό lifecycle που περιλαμβάνει create, pause, resume, suspend και restore. Προσθέτει επίσης rollback, forking και crash recovery. Έτσι, ένα session που περιμένει input δεν χρειάζεται να δεσμεύει CPU και RAM επ’ αόριστον, ενώ ένα αποτυχημένο βήμα δεν υποχρεώνει τον agent να ξαναρχίσει ολόκληρη την εργασία.

Η αρχιτεκτονική του SPACE σε τρία επίπεδα

Το πρώτο επίπεδο είναι το control plane. Το API gateway πιστοποιεί και εξουσιοδοτεί τα αιτήματα, ενώ η διαρκής κατάσταση αποθηκεύεται σε κοινή βάση δεδομένων. Το control plane συγκρίνει το επιθυμητό state με αυτό που πραγματικά τρέχει στο cluster και προσπαθεί να τα φέρει σε συμφωνία. Οι λειτουργίες είναι idempotent, ώστε ένα restart ή μια μερική αστοχία να μην αφήνει το σύστημα σε ακαθόριστη κατάσταση.

Το δεύτερο επίπεδο αποτελείται από node-local services. Αυτά προετοιμάζουν templates, ξεκινούν sandboxes, συνδέουν το networking και διαχειρίζονται snapshots. Ο sandbox manager τρέχει χωρίς αυξημένα δικαιώματα και αναθέτει τις privileged λειτουργίες σε έναν ξεχωριστό node manager. Παράλληλα, ένας network gateway εφαρμόζει κανόνες για την εξερχόμενη κίνηση και ένας credential manager ελέγχει πότε και πώς χρησιμοποιούνται μυστικά.

Το τρίτο επίπεδο είναι το ίδιο το sandbox VM. Διαθέτει δικό του kernel και ένα μικρό in-guest service, το space daemon, το οποίο χειρίζεται filesystem και process operations μέσα από ιδιωτικό κανάλι επικοινωνίας με τον host. Η κανονική δικτύωση του guest προορίζεται για το outbound traffic του workload και δεν χρησιμοποιείται ως ανεξέλεγκτη γέφυρα προς το trusted platform.

Δύο είδη snapshot, όχι μία γενική «μνήμη»

Η πιο σημαντική τεχνική λεπτομέρεια είναι ότι το SPACE δεν βασίζεται σε ένα μόνο είδος snapshot. Ο scheduler δημιουργεί συχνά disk snapshots, δηλαδή point-in-time αντίγραφα του filesystem, και αραιότερα full snapshots ολόκληρου του paused VM. Τα πρώτα επιτρέπουν γρήγορο rollback αρχείων χωρίς να χρειάζεται pause. Τα δεύτερα περιλαμβάνουν το state της virtual machine και μπορούν να επαναφέρουν ένα session πιο κοντά στο ακριβές σημείο εκτέλεσης.

Όταν ένα sandbox γίνεται suspend, το VM παγώνει, δημιουργείται full snapshot και τα artifacts ανεβαίνουν σε object storage. Μόνο όταν ολοκληρωθεί η αποθήκευση όλων των τμημάτων χαρακτηρίζεται το snapshot ως restorable. Έπειτα, οποιοδήποτε κατάλληλο node μπορεί να κατεβάσει τα artifacts, να εφαρμόσει το filesystem delta πάνω στο template και να επαναφέρει το VM. Το αρχικό node δεν χρειάζεται να παραμένει διαθέσιμο.

Αυτό το μοντέλο κάνει δυνατά το pause και το resume, αλλά και το branching: δύο επόμενες εκτελέσεις μπορούν να ξεκινήσουν από κοινό προηγούμενο state. Για έναν developer agent, αυτό μπορεί να σημαίνει δοκιμή δύο διαφορετικών διορθώσεων πάνω στο ίδιο repository χωρίς πλήρη ανακατασκευή του περιβάλλοντος.

btrfs, copy-on-write και warm pools

Για να μην αντιγράφεται κάθε φορά ένα ολόκληρο machine image, το SPACE χρησιμοποιεί btrfs στον τοπικό αποθηκευτικό χώρο των nodes. Τα reflink copies μοιράζονται τα ίδια extents και γράφουν νέα δεδομένα μόνο όταν κάτι αλλάξει. Τα atomic snapshots δημιουργούν νέο filesystem root κυρίως με αλλαγές metadata, περιορίζοντας τόσο τον χρόνο όσο και τον επιπλέον χώρο.

Η Perplexity διατηρεί επίσης warm pools από pods στα οποία συνηθισμένα templates έχουν ήδη γίνει materialize. Αν υπάρχει έτοιμο συμβατό template, ένα νέο request παίρνει writable copy-on-write clone αντί να περιμένει πλήρη αντιγραφή. Αν δεν υπάρχει, το template κατεβαίνει κατά απαίτηση, ενώ τα ταυτόχρονα αιτήματα για το ίδιο image συγχωνεύονται ώστε να μη γίνεται η ίδια δουλειά πολλές φορές.

Ασφάλεια: το microVM είναι μόνο η πρώτη γραμμή

Το Firecracker χρησιμοποιεί KVM-based microVMs και δίνει σε κάθε workload ξεχωριστό guest kernel. Αυτό προσφέρει ισχυρότερο boundary από ένα απλό container που μοιράζεται τον kernel του host. Δεν αρκεί, όμως, από μόνο του για να χαρακτηριστεί ασφαλής ένας agent που μπορεί να τρέξει λανθασμένο ή κακόβουλο κώδικα.

Το SPACE προσθέτει process isolation στον host, ελεγχόμενο guest-host channel, κεντρικό egress gateway και credential store έξω από το sandbox. Σύμφωνα με την Perplexity, τα credentials εισάγονται στο network layer ή συμπληρώνονται από browser agent μόνο όταν χρειάζονται, αντί να αποθηκεύονται μέσα στο guest. Υποστηρίζεται επίσης Bring Your Own Key για externally stored enterprise data, με τα encryption keys να μην εισέρχονται στο sandbox.

Η διάκριση έχει σημασία για κάθε ομάδα που σχεδιάζει AI agents σε εταιρικά περιβάλλοντα: η απομόνωση του compute πρέπει να συνοδεύεται από περιορισμένο egress, βραχύβια credentials, audit logs, approvals και σαφή πολιτική ανά εργαλείο. Ένα microVM περιορίζει το blast radius· δεν αποδεικνύει ότι η ενέργεια που επέλεξε ο agent ήταν σωστή.

Τι δείχνουν οι μετρήσεις της Perplexity

Η εταιρεία αναφέρει ότι άρχισε να αναπτύσσει το SPACE ως sandbox layer του Computer τον Ιούνιο και ότι, κατά την ανακοίνωση, το 100% των Computer sessions εκτελούνταν ήδη στη νέα υποδομή. Μέσα στην εβδομάδα του rollout, το σύστημα φέρεται να εξυπηρέτησε εκατομμύρια sandbox creations και δεκάδες εκατομμύρια reconnects.

Σύμφωνα με το production comparison της Perplexity, το median create latency μειώθηκε από 185 ms σε 60 ms, βελτίωση 3,1 φορές. Στο P90, ο χρόνος έπεσε από 447 ms σε 89 ms, δηλαδή περίπου 5 φορές. Η εταιρεία λέει ότι η σύγκριση έγινε παράλληλα με τον προηγούμενο sandbox provider πάνω στο ίδιο production traffic.

Οι αριθμοί είναι εντυπωσιακοί, αλλά πρέπει να διαβαστούν ως vendor-reported αποτελέσματα. Δεν δημοσιεύτηκε ανεξάρτητο benchmark, αναλυτική μεθοδολογία, κατανομή hardware ή dataset που να επιτρέπει σε τρίτους να αναπαράγουν τη μέτρηση. Επιπλέον, το create latency δεν καλύπτει μόνο του το κόστος ενός πλήρους suspend, upload, cross-node restore ή μιας μακροχρόνιας session.

Τα snapshots έχουν και δύσκολες γωνίες

Η επίσημη τεκμηρίωση του Firecracker επιβεβαιώνει ότι ένα snapshot μπορεί να αποθηκεύσει guest memory και emulated hardware state και να επαναφέρει το workload σε διαφορετικό Firecracker process. Επισημαίνει όμως περιορισμούς: οι ενεργές network και vsock συνδέσεις δεν είναι εγγυημένο ότι θα επιβιώσουν, η συμβατότητα εξαρτάται από CPU και host configuration, ενώ η επαναφορά του ίδιου state περισσότερες από μία φορές χρειάζεται ειδική φροντίδα για random values, identifiers και cryptographic tokens που πρέπει να παραμένουν μοναδικά.

Αυτό εξηγεί γιατί το πραγματικό προϊόν δεν είναι απλώς το snapshot API του hypervisor. Χρειάζονται state machine, storage protocol, atomicity, reconnection logic, credential rotation και έλεγχος μοναδικότητας. Το SPACE είναι κυρίως η ενοποίηση αυτών των μηχανισμών σε ένα production control plane για agents.

Τι αλλάζει για τους developers

Το πιο ενδιαφέρον μήνυμα δεν είναι ότι η Perplexity επέλεξε Firecracker ή btrfs. Είναι ότι το session γίνεται ανεξάρτητη, durable οντότητα, ενώ το sandbox μετατρέπεται σε προσωρινό worker. Το ίδιο pattern επιτρέπει human-in-the-loop εργασίες χωρίς μόνιμη κατανάλωση compute, ασφαλέστερη ανάκτηση από crashes και παράλληλη εξερεύνηση διαφορετικών λύσεων.

Για ομάδες που χτίζουν δικούς τους agents, η αρχιτεκτονική προσφέρει ένα χρήσιμο checklist: διαχωρισμός control plane και execution plane, idempotent lifecycle operations, ξεχωριστά disk και full checkpoints, εξωτερικό secret store, egress policy, durable object storage και σαφής στρατηγική reconnect. Το δύσκολο σημείο δεν είναι να ξεκινήσει ένα microVM. Είναι να διατηρηθεί σωστό και ασφαλές το session όταν αλλάζουν nodes, διακόπτεται το δίκτυο ή ο χρήστης επιστρέφει μετά από ημέρες.

Προς το παρόν, η Perplexity παρουσιάζει το SPACE ως εσωτερική πλατφόρμα που ήδη τροφοδοτεί το Computer και ως μελλοντικό ενιαίο layer για Linux microVMs, Windows guests και τοπικά μηχανήματα χρηστών. Δεν έχει ανακοινωθεί δημόσιο standalone SPACE API, τιμολόγηση ή ημερομηνία γενικής διάθεσης για τρίτους developers. Επομένως, η σημερινή αξία της ανακοίνωσης είναι κυρίως αρχιτεκτονική: δείχνει πώς ένα agent product περνά από προσωρινά sandboxes σε durable, recoverable sessions.

Πηγές

• Perplexity Research — Making SPACE: Secure and Efficient Runtimes for Long-Running Agents
• Perplexity — How we built security into Computer
• Firecracker — επίσημη τεκμηρίωση snapshotting
• Firecracker — επίσημη παρουσίαση της τεχνολογίας microVM
• SiliconANGLE — ανεξάρτητη κάλυψη της ανακοίνωσης του SPACE