Matt Brockman is an AI engineer whose work spans browser-based writing assistance, AI data analysis, and execution environments for agents. At E2B, his work has focused on sandboxes that let agents run code, manipulate files, and retain a workspace across multiple steps. A recurring concern is making generated code useful in practice: giving it somewhere to run, making its results inspectable, and managing the resources it leaves behind.
From browser assistants to executable analysis
Earlier in his career, Brockman worked at OthersideAI, the company behind HyperWrite. His public browser experiments include a November 2022 script for improving Twitter search, accompanied by an invitation to help build HyperWrite’s Chrome extension and bring language models into webpages. This placed AI assistance inside an interface people already used.
Infrastructure mattered alongside the interface. At OthersideAI, Brockman emphasized reducing deployment overhead so the team could concentrate on building services while retaining quick startup, low latency, and access to GPU capacity. HyperWrite’s infrastructure combined managed Kubernetes deployments with nearby inference services to reduce the distance between the application and its compute.
Brockman subsequently worked as a software engineer at Julius, helping build an AI data analyst. Julius combined files and natural-language instructions with code execution, file manipulation, and search to produce analyses and visualizations. Its users included financial analysts, scientists, and researchers with different levels of technical experience. Making generated code useful meant turning its execution into a result those users could understand and use.
Persistent agent workspaces: An agent can edit files and run commands while retaining temporary state between steps. A longer task has a working environment to return to as it progresses.
Reviewable generated artifacts: A website-building agent serves its output at a live preview URL and applies patches as it iterates. Developers can inspect the result while the work is still in progress.
Parallel sandbox execution: Separate agents can generate website variants in independent environments, each with its own preview, so developers can run and compare alternatives.
Keeping persistent workspaces manageable
In How I Learned to Stop Worrying and Love the Sandbox, Brockman connects those capabilities to their operational costs. E2B templates can preserve a running system’s memory and filesystem so work resumes where it stopped. That convenience also restores forgotten background processes. His deliberately broken lab environments make the consequences tangible: a runaway process consumes 99.7% of a sandbox’s CPU, while other challenges expose memory pressure and a full disk. Isolating each challenge lets participants reset a mistake without destroying the rest of their work.
As deployments grow from a few sandboxes to hundreds or thousands, workspace identity and resource lifetimes become central design decisions. Brockman demonstrates mapping users to sandbox IDs so each person returns to the same workspace, and adjusting idle timeouts so a task has time to finish without leaving unused resources running. Persistence requires keeping track of what runs where, what it can access, and when to clean it up.
Matt Brockman’s E2B workshop turns broken environments into lessons in resource debugging, snapshots, workspace identity and lifecycle management—and shows why restoring state also restores the mess you left behind.
Snapshots preserve RAM, files and running processes. That makes resumption convenient, but also carries forgotten background work into later sessions.
Resource cleanup and access control remain application responsibilities: track abandoned environments, direct writes to writable locations, and restrict outbound access when secrets are present.
▶ Watch ↗