Eve explained: building AI agents you can operate

An AI model can explain an alert. Giving it a reliable place to keep working takes more engineering. Someone has to connect the monitoring system, preserve the investigation, deliver the answer to the right thread and decide which actions need a person involved.

Eve is Vercel's open-source TypeScript framework for assembling those pieces. You describe an agent in files, connect its capabilities and run it through a runtime that manages the conversation and its work. You can deploy on Vercel or operate the service yourself. The project is currently in beta, so its APIs and behavior can change. [1][2]

For SRE teams, the useful question is what this makes possible beyond another chat window. Eve offers a foundation for an assistant that can participate in an operational workflow, including the parts where it waits, resumes and calls another system. Your team still builds the knowledge and integrations that make that assistant useful.

What Eve actually builds

An agent combines a model with instructions and tools it can choose to use. The model decides what to ask or call next; the surrounding software executes permitted operations and returns results. Eve supplies that surrounding structure.

Its authoring interface is an ordinary project directory. An agent/instructions.md file describes the job. Optional TypeScript files select the model and implement tools. Other directories hold reusable skills, communication channels, connections and subagents. A skill supplies a procedure when relevant; a tool performs an operation. A subagent is a separate agent given a specialized part of the work. [2]

That layout makes an operational assistant inspectable in a familiar way. A runbook change can be reviewed beside the tool that gathers its evidence. A pull request can show that someone added a deployment lookup or changed the agent's instructions. The repository captures what you authored, although the model's responses still need evaluation.

Eve also has a terminal interface. The distinction is that this interface is one way to talk to the agent, while the agent itself can be connected to channels such as Slack or a web application. Its purpose extends beyond helping someone write code at a terminal. [1][2]

Follow one alert through the machinery

Consider a hypothetical assistant investigating elevated latency in a checkout service. You give it tools that retrieve request metrics and recent deployments, plus a skill explaining how your team investigates that service. None of those service-specific capabilities arrives merely because Eve is installed.

An engineer asks in Slack, “What changed before checkout latency rose?” The channel delivers the request to the agent. The model reads the instructions, selects an available tool and receives its result. It might compare the deployment timestamp with the latency window, fetch a second signal and then explain the evidence in the thread.

Here is how the responsibilities could divide in that implementation:

Piece	Its job in the checkout example
Instructions	Define the assistant's scope and how it should distinguish evidence from a hypothesis.
Investigation skill	Explain which checkout signals are useful and how to interpret them.
Tools	Retrieve the selected metrics and deployment records.
Connection	Authenticate access to an external service and expose its supported operations.
Channel	Carry the engineer's request and the assistant's response.
Durable session	Preserve the conversation and checkpoint progress through its work.

Eve supports connections to MCP and OpenAPI services. MCP lets a service advertise callable tools and their input schemas; OpenAPI describes HTTP operations from which a connection can expose tools. Either way, the integration supplies access to operations. The investigation still needs the right data and an explanation that follows from it. [6]

For example, a deployment occurring just before latency rises gives the assistant a lead. It has not established the cause. A useful response would identify the overlap, show what changed and explain which observation would strengthen or weaken that hypothesis. That is the behavior your instructions, tools and evaluations should encourage.

The conversation can wait without starting over

Operational work often stops while someone finds an answer or approves an action. Eve models the conversation as a durable session, with turns for incoming messages and checkpoints inside the work each turn triggers. Its Workflow SDK foundation records progress so the runtime can resume from completed steps after an interruption. [4]

In the checkout example, the assistant could gather evidence and propose a rollback through a tool configured to require human approval. The workflow can wait for the decision and continue afterward. Tool approval is an explicit runtime capability; writing “ask first” in the prompt alone does not configure that gate. [5]

The following is an illustrative workflow built with those capabilities, rather than a diagram of Eve's internal implementation:

The approval boundary belongs around a specific operation. For this example, the person should see the target service, proposed deployment and evidence behind the request. A vague approval to “fix checkout” leaves too much of the actual decision unresolved.

There is another detail worth slowing down for. Eve reuses the recorded results of completed steps, but a step interrupted during execution can run again. Suppose a rollback request reaches the deployment service and the worker crashes before its step is recorded as complete. A retry can submit that operation again. [4][5]

The deployment integration therefore needs a way to recognize the same requested operation, such as a stable idempotency key supported by the upstream service. Approval answers whether an operation is authorized. Deduplication answers whether a retry has already performed it. A reliable workflow needs both answers when an operation can repeat. [5]

Where the code and credentials live

Eve separates its trusted application runtime from the agent's sandbox. The application runtime handles orchestration, authored tool code and integration credentials. The sandbox provides an isolated filesystem and processes for operations such as shell commands and file work. [4]

That distinction matters when designing the checkout tools. A tool that calls a deployment API runs trusted integration code with the access you gave it. Putting other agent activity in a sandbox does not narrow that API credential's authority. The tool itself needs to enforce the allowed service, environment and operation.

A small read-only tool can be especially useful here. It can accept a service name and a time window, then return only the deployment records needed for that investigation. The model gets a focused answer, and the team gets a capability whose scope is easier to understand than unrestricted access to the deployment system.

Running it yourself means operating another service

Self-hosting is a documented path. Eve builds a Node service using Nitro, and you provide the hosting, authentication, persistent workflow storage and sandbox backend. You can also configure direct model-provider access. Owning the runtime does not mean inference happens locally. [7]

The deployment details affect reliability immediately. The default local workflow store needs persistent storage. Its queue delivery is tied to the process that created the work, so placing several default instances behind a load balancer does not automatically produce a shared worker pool. Eve's documentation calls for an appropriate Workflow world, its backend abstraction, when scaling shared delivery across replicas. [7]

Schedules need attention too: each eve start process runs authored schedules unless you disable them on the additional instances. Otherwise, adding capacity can also add duplicate scheduled work. [7]

These are familiar platform problems. Eve reduces how much agent orchestration you assemble yourself, while leaving decisions about availability, capacity, upgrades and service ownership with the team running it. Its self-hosted session recovery also has version compatibility limits, which deserve attention before an upgrade of an assistant with long-running conversations. [7]

A useful first agent has something specific to prove

The framework can support more than incident investigation. A scheduled assistant could assemble an on-call handoff from approved sources. Another could gather evidence for a postmortem or answer service questions through a web interface. Those are implementation ideas, and their value depends on how well the integrations retrieve and preserve the relevant information.

For a first checkout assistant, read-only investigation gives you a clear result to assess: can it gather the right evidence and explain what that evidence supports?

Eve's eval framework exercises actual agent sessions and can assert on tool calls and responses. Tool stubs let you supply controlled results. [8] You could give an eval a deployment that predates the latency change, then check that the assistant does not describe the timing as proof of causation. A second case could return no deployment at all and check whether it investigates another explanation instead of inventing a release.

Those cases test a meaningful behavior. A response containing the word “deployment” would be a much weaker check, because an incorrect explanation could contain that word just as easily.

To explore the project, the current getting-started guide requires Node.js 24 or newer, npm and a supported model credential. Initialization creates the project and opens the terminal interface:

npx eve@latest init checkout-assistant

After initialization, edit agent/instructions.md. For later development sessions, enter the generated directory and run:

cd checkout-assistant
npm run dev

That gets you an agent project. To investigate checkout, you would still add the metrics and deployment tools described above. The getting-started guide explains the supported model connections and next steps. [3]

Eve becomes interesting when the assistant has a job that lasts beyond one answer: gather evidence, preserve progress, wait for a decision and continue in the same conversation. The checkout example shows where that can help. An engineer can return to an investigation with its evidence and decisions still connected, while the team maintains the assistant as software it can inspect, test and operate.

Sources

Documentation checked October 26, 2026. This is an explanation of documented capabilities, with illustrative implementation examples, rather than a hands-on product review.

1. Eve overview.

2. Vercel Eve repository, project structure, license and beta notice.

3. Getting started.

4. Execution model and durability.

5. Tools, approval and idempotency.

6. Connections.

7. Self-hosting Eve.

8. Evaluations.