E2B + Veris: Give Coding Agents a Computer and a World to Work Against

Coding agents are getting very good at writing code.

But writing code is only half the job. To actually build and verify software, an agent needs somewhere safe to run that code and realistic systems for that code to interact with. Today, E2B and Veris are partnering to bring those two pieces together.

E2B gives AI agents their own secure cloud computers. Veris gives those computers a simulated version of the external world: APIs, databases, SaaS services, state, and failures. Together, coding agents can build and test software end to end in isolated environments, without touching production or depending on a shared staging environment.

E2B: a computer for every agent

E2B provides secure, isolated cloud sandboxes built specifically for AI agents. An agent gets a Linux environment where it can clone a repository, edit files, install packages, run commands, start servers, execute tests, and inspect the result. E2B sandboxes are powered by Firecracker microVMs and can be created programmatically as part of an agent workflow.

Instead of giving a coding agent access to your laptop or production infrastructure, you give it its own disposable machine. That solves a fundamental problem: where should agent-generated code actually run?

But there is another half of the development environment. What happens when that code calls Stripe? Salesforce? Slack? Postgres? An internal API? That is where Veris comes in.

Veris: a simulated world for agents to build against

Veris creates isolated, stateful simulations of the systems software depends on.

Instead of a static mock that returns the same canned response, a Veris twin behaves like a real service and holds state. Create a customer and that customer exists when you fetch it later. Update a record and subsequent calls see the new state. Trigger a workflow and the downstream systems can respond accordingly.

Veris can simulate databases, payment systems, CRMs, messaging services, internal APIs, and other dependencies without giving the coding agent access to the real systems.

In other words:

How does it work?

The new E2B + Veris integration connects those layers directly. The @veris-ai/e2b SDK is a drop-in extension of E2B's Sandbox. When a sandbox starts, Veris provisions a corresponding twin of the services your application depends on and connects the E2B environment to it. Existing E2B functionality continues to work normally.

Your application can continue calling the same production hostname and using the same SDK it normally uses. The network layer routes those requests to the corresponding Veris simulation instead. No real customer gets charged, no production record gets modified, no shared staging environment gets polluted, and the agent gets to exercise the actual integration path.

Example: building against Stripe

The example in the E2B Cookbook demonstrates the integration with Stripe.

Sandbox.create() starts an E2B sandbox and provisions a Veris twin containing the simulated Stripe environment.

Inside the sandbox, the coding agent is asked to create a Stripe customer and confirm that the customer was persisted. The code calls https://api.stripe.com just as it normally would, but the request is intercepted and answered by the Veris twin. When the agent creates a customer, the simulated Stripe service changes state. When the agent reads that customer back, it gets the customer it just created.

That distinction matters. A coding agent can easily produce a test that looks successful without actually exercising the dependency you care about. So Veris adds another primitive: receipts.

At the end of the run, developers, or the agent itself, can inspect what the simulated service actually received:

  stripe: 3 request(s)
    GET  /v1/customers/cus_… -> 200
    POST /v1/customers       -> 200

And the test can explicitly require that an expected call occurred:

await sbx.veris.assertTouched(
  'stripe',
  { method: 'POST', path: '/v1/customers' }
)

If the agent claimed it created a customer but never actually called Stripe, the assertion fails.

Why does this matter for coding agents?

Human developers have historically relied on local environments, mocks, test accounts, and shared staging systems. Those approaches start to break down when hundreds of coding agents can operate simultaneously.

You don't want 100 agents competing for the same staging database. You don't want to create 100 Salesforce accounts with carefully constructed test data. And you definitely don't want autonomous agents experimenting against your production Stripe account.

Each agent needs its own disposable environment: not only its own computer, but its own stateful copy of the systems surrounding the application.

E2B and Veris together make that possible. An agent can get its own machine, its own dependencies, its own data and state, run destructive tests, verify the result, and then throw the entire environment away.

And because the environment is programmable, the same pattern can eventually go far beyond happy-path integration testing: specific database states, failed payments, API errors, webhook flows, race conditions, and other scenarios that are difficult to reliably reproduce against real services.

Build, test, verify, repeat

Coding agents are changing the speed at which software gets written. The infrastructure around them has to change too.

Giving an agent a shell is a start. Giving it a safe, realistic world in which it can build, break things, observe the consequences, and verify its own work is the next step. That's what we're building together with E2B.

E2B gives every agent a computer. Veris gives it a world to build against.

Check out the working integration in the E2B Cookbook, then bring your own dependencies into the sandbox.