# 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](https://www.zavu.dev/docs/guides/functions/quickstart) |
| **eve** | `agent/instructions.md` | [Deploy an eve project](https://www.zavu.dev/docs/guides/functions/deploy-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:

```bash
npx zavudev import acme/platform --root apps/agent
```

```bash
npx zavudev fn git link acme/platform
# then set the root directory from the function's Git tab
```

In 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](https://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](https://www.zavu.dev/docs/api-reference) or an [SDK](https://www.zavu.dev/docs/sdks/overview) — what the adapters add is
deploying and hosting the agent itself.