Coding agents that verify their ownpayment flowbefore the PR.

No, it fills them. E2B, Daytona, Docker, or your own Kubernetes give the agent compute: a filesystem and a shell. Veris provides what that compute talks to: the stateful databases, payment APIs, CRMs, and queues the code under test depends on. Point the sandbox's environment variables at Veris endpoints and keep everything else exactly as it is. Bring your own compute; Veris supplies the dependency environment.

A mock returns canned responses and holds no state: write a row, and there's nothing to read back. Vendor test modes are real but limited: you can't trigger an outage on cue, async failure paths often depend on webhooks, and the shared account accumulates state across runs. A Veris Dependency Sandbox is stateful and vendor-true, with failure states configurable as data, and every run starts from a fresh reset. In our benchmark, agents with Veris caught every planted integration bug in every run; no other environment achieved full coverage.

Staging is one shared environment: it drifts from production, accumulates state, and usually still touches something real, so a fleet of agents mutating it concurrently is a non-starter. Veris gives every agent its own stack: stateful, isolated, reset in milliseconds, destroyed when the branch merges. Nobody queues, nobody collides, and a destructive test costs nothing.

Environment variables or MCP. A Dependency Sandbox is an API call: create it, get per-service endpoints back, export them as DATABASE_URL / STRIPE_API_BASE / whatever your code already reads. The agent's own loop can create, reset, and destroy sandboxes as it works. No SDK to embed, no proxy to install in your app.

Yes. Hand Veris an API spec, or point it at the repo, and it builds a stateful twin of the service: endpoints that hold state between calls, respond like the real implementation, and fail on cue when you want the unhappy paths tested. That gives your agents an integration target for systems that have no vendor test mode at all, without touching the real deployment.

More than 70 twins are ready today: CRMs, billing, ticketing, databases, queues, clouds. The /twins catalog lists what each one speaks and what it holds state for. For anything else, hand Veris an API spec and it builds the twin, the same way it does for your internal services.

Twins are built vendor-true: the same endpoints, status codes, webhook timing, and edge-case behavior as the service they mirror, and they're maintained centrally, so when a vendor ships a change your tests track the service rather than a snapshot of it.

Every twin starts from a seed you control: bring your own fixtures, or let Veris compose production-shaped synthetic data for you, drawing on your product descriptions and docs, subject-matter-expert input, schemas, and exploration of your code. The seed is part of the sandbox definition, so every reset returns to the same known baseline, which is what makes a failing run reproducible instead of a flake.

The sandboxes don't care who calls them. The same veris.yaml serves three consumers: agents verifying their work in-loop, CI running the integration suite on every pull request, and developers pointing a local .env at a personal stack instead of a shared staging environment. Most teams start with one and end up using all three.

No. Every endpoint is a twin, so there is nothing real to leak: zero live keys handed to any agent. Compare that with testing against a vendor's real test mode, where the agent needs an actual key with actual permissions. Destructive tests, injected outages, and hostile inputs all stay inside a disposable Dependency Sandbox.

Yes, that's the point of one full stack per agent. Each Dependency Sandbox is isolated with its own endpoints and its own state, so a hundred agents can drop tables and refund charges concurrently without sharing a staging environment. Sandboxes spin up in seconds and reset in milliseconds, inside the agent loop rather than a ticket queue.