Skip to main content

The eve layout

eve keeps an agent on the filesystem: a markdown file for the instructions, an optional config file, and one file per tool.
agent/instructions.md is the whole detection rule. Zavu compiles the project at deploy time into the same registry a native project declares directly, so what runs afterwards is an ordinary Zavu agent. No file of yours is edited.

What carries over

A file under agent/tools/ counts as a tool only when it default-exports defineTool(...). One that does not is named in the report before the deploy starts, so the tool count is always the number of tools actually created.

What does not

Every eve capability without an equivalent is listed explicitly before the deploy runs, one line each — nothing is dropped in silence. Today that includes channels, schedules, subagents, the sandbox, connections, evals, and approval gates. A voice block in agent.ts is not translated either: the agent deploys as text only. To give it a voice, configure it on the Zavu side. Every key agent.ts declares that Zavu does not read is reported by name, including keys we have never heard of, so a config that quietly does nothing is visible rather than assumed.

Deploying

Compiling locally needs esbuild in the project (npm install -D esbuild); zavudev import installs it for you, and deploying through a GitHub link needs nothing at all, because that build happens on Zavu. The agent reads SENDER_ID at runtime, or takes --sender at deploy time:

One thing worth knowing

An eve project declares no HTTP handler and no event handler, only an agent and its tools. Its public URL answers 404, and an event trigger on it invokes a function with nothing to run. That is expected: the agent replies because it is attached to a sender, and its tools run when the agent calls them. For the deeper walkthrough, see Deploy an eve project.