> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/zerve-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/zerve-docs/getting-started/how-zerve-works.md).

# How Zerve works

How Zerve's agents, notebooks and compute fit together.

Zerve combines agents that plan and do the work, notebooks where the work happens, and compute that runs it. This page explains how the pieces fit together.

## The agents

Zerve's agents come in layers, and each layer builds on the one below it.

| Agent                         | Where it runs           | What it does                                                                                                               |
| ----------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Ask, Plan and Build modes** | In a thread or notebook | Answer questions, propose a plan for you to approve, or make and run changes directly                                      |
| **Evolve Mode**               | In a thread or notebook | Plans the work, delegates it to specialist agents working in parallel, verifies the results and keeps persistent learnings |
| **Superagent**                | Above notebooks         | Owns a mission over time and manages a team of agents working toward it                                                    |

The most important relationship is between Evolve Mode and superagents. **Every worker on a superagent's team is a full Evolve Mode agent** with its own notebook. A superagent never writes code itself; it coordinates many Evolve Mode agents, checks what they produce and decides what to do next.

To learn more, see [Agent modes](/zerve-docs/agents-in-the-workspace/agent-modes.md), [Evolve Mode](/zerve-docs/agents-in-the-workspace/evolve-mode.md) and [What is a superagent?](/zerve-docs/superagents/superagents.md)

## Notebooks

A notebook is where code, data and results live. Whether you write the code yourself or an agent writes it, the work is organized as **blocks** connected in a graph: each block takes inputs from the blocks before it and passes its outputs on.

Two things make Zerve notebooks different from traditional ones:

**Each block runs on its own.** Every time a block runs, Zerve starts a separate **block run** on the compute you choose for it. One notebook can mix fast serverless blocks with a GPU block for model training.

**Results are saved as you go.** Each block's outputs and variables are stored, so later blocks can reuse them without rerunning everything upstream. This is also what lets agents inspect intermediate results as they work, and what lets you check every step afterwards.

To learn more, see [The notebook and canvas](/zerve-docs/notebooks/notebook-and-canvas.md) and [Blocks](/zerve-docs/notebooks/blocks.md).

## Compute

Zerve provisions compute for each block run automatically, from quick serverless runs to large-memory machines and GPUs. To run the same block many times in parallel, for example across hundreds of inputs, you use [Fleet](/zerve-docs/compute/fleet.md).

To learn more, see [How code runs](/zerve-docs/compute/compute.md).

## Where Zerve runs

You can use Zerve in Zerve's cloud, or run it inside your own AWS, Google Cloud or Azure account, or on your own infrastructure. When Zerve runs in your environment, your code, data, results and deployed apps stay there.

To learn more, see [Deployment options](/zerve-docs/self-hosting/self-hosting.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zerve.ai/zerve-docs/getting-started/how-zerve-works.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.