> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zavu.dev/llms.txt
> Use this file to discover all available pages before exploring further.

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

<CodeGroup>
  ```bash CLI theme={null}
  npx zavudev import acme/platform --root apps/agent
  ```

  ```bash Existing function theme={null}
  npx zavudev fn git link acme/platform
  # then set the root directory from the function's Git tab
  ```
</CodeGroup>

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](/api-reference) or an [SDK](/sdks) — what the adapters add is
deploying and hosting the agent itself.