Frameworks
Deploy an agent written in the framework you already use. Zavu adapts it, without changes to your project.
Bring the framework you already use
Zavu runs agents written in more than one authoring format. You keep your
project as it is; Zavu adapts it at deploy time and the result is a first-class
Zavu agent, with the same inbox, the same executions log, and the same billing
as one written directly against @zavudev/functions.
The principle behind every adapter: standard authoring format, Zavu runtime. An adapter never asks you to move a file or rename a folder, and it never pretends to support something it cannot run. Anything in your project that has no equivalent on Zavu is listed explicitly before the deploy starts.
Supported today
| Framework | Recognized by | Guide |
|---|---|---|
| Zavu | index.ts at the root | Quickstart |
| eve | agent/instructions.md | Deploy an eve project |
Those two files are exactly what Zavu looks for, whether you deploy from the CLI, from the dashboard, or on a push to GitHub. A repository with neither is refused before anything is created, rather than failing halfway through a build.
Monorepos
The check runs at the root of the repository. If your agent lives in a subfolder, point Zavu at it with a root directory:
npx zavudev import acme/platform --root apps/agentIn the dashboard, the import dialog offers a root directory field as soon as it cannot find a project at the root.
What every adapter guarantees
- Your files are not edited. The adaptation happens at deploy time.
- Gaps are reported, never silently dropped. Every capability your framework declares that Zavu cannot run is named before the deploy, one line each.
- The same deploy pipeline. Whatever the format, what runs afterwards is a Zavu function: same secrets, same logs, same rollback, same deploy-on-push.
Your framework is not here yet
The list grows. An adapter is a compiler from a project layout to the Zavu
registry (defineAgent and defineTool), plus an honest compatibility report,
so adding one is a contained piece of work rather than a platform change.
If you want one for the framework you use, open an issue on github.com/zavudev describing the layout, or write to support with a link to a repository we can look at. A public sample project is the single most useful thing you can send.
In the meantime, an agent in any language can still reach Zavu through the REST API or an SDK — what the adapters add is deploying and hosting the agent itself.