Vercel Just Dropped EVE. Here's Everything It Is

A tour of Vercel's new Eve agent framework, then a real build: an open-source agent that reads our code and answers questions, wired through Agent Vault so it never holds a single API key.

Vercel Just Dropped EVE. Here's Everything It Is
Vercel just released a new agent framework called Eve, and it is one of the cleanest ways to build an agent today. Think Next.js, but for AI agents. Your whole agent is a folder of files, and the folder structure is the mental model. This walkthrough covers what Eve is and then puts it to work: a real, open-source agent for our community that reads our code and answers questions, wired so that it holds zero API keys but still has full access to everything it needs.
Your agent is a folder of files
Most agent SDKs feel primitive. You end up tracking a lot of moving pieces by hand, and it becomes a lot to build on top of. Eve flips that around. Everything is straightforward because a file's location is what it does. `instructions.md` is the agent's personality. `agents.ts` picks the model. Drop a file into `connections` and it is wired to an external server. The repo itself reads like the architecture diagram, which makes the whole thing easy to reason about as it grows.
Model-agnostic with one line
Eve is model-agnostic. A single line in `agents.ts` picks the model, so you can run Sonnet in one place and Opus in another, swap providers, or route through a gateway without touching the rest of the agent. That flexibility is standard for any serious agent you would build, and Eve keeps it to one line instead of a configuration sprawl.
Skills are markdown playbooks loaded on demand
Agent skills in Eve are markdown playbooks that the agent loads only when they are relevant. You can hand the agent a real procedure, like how your team triages a bug report, without cramming that procedure into the context of every prompt. The agent pulls the playbook the moment it actually needs it, which keeps the working context lean.
Tools are the agent's hands, and most are built in
Tools are the typed functions an agent can actually call, and most of the ones you reach for are already built in: web search, reading and writing files, fetching URLs, running shell commands. Out of the box, the agent can look things up and do real work without you defining anything. When you need something specific, you add it as a TypeScript function with `defineTool`, and the model only ever sees the results. It never sees the code or your keys. A simple example is a `getSupportLinks` tool that hands back canonical docs and real GitHub links so the agent does not hallucinate them.
Connections replace hand-written MCP tools
Connections were a genuine relief coming from the raw agent SDK, where every Model Context Protocol (MCP) tool had to be written by hand. In Eve, a connection is one file pointing at a server, and the agent discovers the whole tool set on demand. The GitHub connection later in the build is a good example: one file, and the agent gets the entire GitHub tool set without a single tool written by hand.
Sub-agents keep the main agent lean
Sub-agents are easy to set up in Eve, and they keep your main agent lean. You delegate specialized work to agents that have their own prompt, their own tools, and even their own sandbox. The build uses a `codeResearcher` sub-agent that digs through our repos from inside its own sandbox. You can also choose which model each agent runs on, so the code specialist can run on a stronger model like Opus while the main agent runs on a lighter one. You only pay for the big model on the hard problems.
Channels are the front door
Channels are how people interact with the agent. Out of the box you get a plain HTTP endpoint you can hit from curl or a backend, a web chat UI you can drop straight into a Next.js site, and platform channels like Slack and Discord where the agent answers mentions and direct messages. You define the agent once, including its personality, tools, schedules, and sub-agents, and a channel is just a file that exposes it on a new service. The agent answers the same way whether the question comes from a terminal or a Slack thread.
Sandboxes, approvals, schedules, and evals
These agents do not just chat. They run real commands, like cloning a repo or grepping through code. Eve does not run those on your machine or inside your app. It spins up an isolated sandbox, essentially a throwaway computer and file system, and runs the commands there, so the agent can get its hands dirty without ever holding execution rights in your environment. Eve also includes human-in-the-loop approvals, where any tool can pause and wait for sign-off before it runs anything risky or expensive. Schedules let you drop in a cron expression so the agent runs a daily report or nightly sync on its own. Evals are scored test suites that run on every deploy, so a quiet regression from a prompt tweak gets caught before it ships. And sessions are durable, surviving crashes and restarts without you writing any of that logic.
The demo: an agent that reads our code, with no keys
Before the demo, a quick reframe of the hard part. An agent needs real credentials to do real work: a model key, a GitHub token, and so on. Normally those sit in a file the agent process reads, in plain text the agent can read and potentially leak. Instead, this build stands up an open-source credential broker called Agent Vault. The agent's file holds only dummy values. The real keys live in the vault and get injected on the wire on the way out, so the agent never actually holds a key. If you want to set up Agent Vault, it is quick, and the steps are walked through in the Agent Vault setup video.
Starting the agent is one command. The Eve command itself is `eve dev`, and it gets wrapped in the Agent Vault CLI so the agent's traffic routes through the broker. Asking the agent what the Infisical CLI does returns the right answer: the Infisical CLI injects secrets from Infisical into any application. The agent is working, and the credential plumbing is invisible to it.
How brokering keeps keys out of the agent's hands
The GitHub connection shows the payoff. Asking the agent to list open issues in a private repo, it searches its connections, finds the GitHub list-issues tool, and returns the issues, even though the repo is private. The GitHub token never lived in the agent. It was put into Agent Vault and swapped in on the wire. The sub-agent piece works the same way: a question like where the Infisical CLI reads its token from gets handed to the `codeResearcher`, which greps the real source from its own sandbox and comes back with the file and line.
Asking the agent to print its own Anthropic key and `cat` its env file makes the point. Models are trained not to dump credentials, which is good, but the real proof is that the file holds only dummies. The GitHub token is a dummy. The Anthropic key is a dummy. The repo is private, on a test account, and the agent has no token that could open it. It works only because the credential broker sits between the agent and its upstream services. This pattern, where a credential broker holds the real secrets and the workload is just a machine identity that never sees them, is the direction the industry is converging on to keep API keys and tokens out of agents' hands. It means there is nothing for a compromised agent to leak, even through something like prompt injection. Every model call is brokered too, so the brain key is not in the agent's config or an environment variable either.
Sandboxes, caching, and durability under the hood
Eve picks the best sandbox it can in order. On Vercel it is a hardware-isolated microVM. Locally it walks down a list: Docker if you have it, then a lighter VM, then a pure-JS fallback. The first time the code researcher runs, it clones the relevant repos and bakes them into a cached template image, around 5 GB with all the repos in it. After that, every new session spins up a fresh sandbox from that template, and the per-session containers are copy-on-write, so they are a few kilobytes each. You clone once and get small, cheap sandboxes forever. Because sessions are durable, stopping the process or redeploying mid-task picks back up where it left off.
Shipping to Vercel
Deploying is the story you would expect. Download the Vercel CLI, run `vercel deploy`, and you get the sandbox, durable sessions, cron schedules, and hosted channels like Slack set up for you. The full deploy, plus wiring the agent into our community Slack, is the subject of a follow-up.
Wrapping up
That is Eve. Your agent is a clean folder of files, model-agnostic, with tools, connections, sub-agents, and channels, plus a sandbox, durable execution, and batteries included, deployable to Vercel in one command. It is open source, and well worth trying. The no-keys trick was Agent Vault, a single Go binary that is also open source and can run on your own device. Every agent we ship to production, whether it is on a VPS, on Render, or on a Mac Mini locally, gets brokered through Agent Vault so it never has access to any keys. Next time, we get it fully deployed and plug it into Slack.
Starting with Infisical is simple, fast, and free.