> 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/agents-in-the-workspace/best-practices.md).

# Best practices

How to get the best results from Zerve's agent in threads and notebooks.

These practices will help you get reliable results from Zerve's agent, and use your credits well.

## Choosing a mode

**Match the mode to the task.** Use **Ask** for questions, **Plan** when you want to agree the approach first, **Build** for clear, contained changes, and **Evolve Mode** for anything substantial. See [Agent modes](/zerve-docs/agents-in-the-workspace/agent-modes.md).

**Use Plan for anything you'll need to defend.** Reviewing the plan first means the approach is one you've agreed to, which matters when results go to a PM, a client or a committee.

## Writing requests

**Say what it's for.** "For the Monday risk meeting" or "to send to the investment committee" tells the agent the level of detail and rigor you need.

**Say what good looks like.** "A signal only counts if it holds up out of sample" or "keep turnover below 300% a year" gives the agent a bar to work toward.

**Name your data.** Point the agent at the right source, such as "our positions data in Snowflake," rather than letting it find its own.

**Give one instruction at a time while it's working.** New messages are queued, and if a new message changes an earlier one, the latest instruction wins. Clear, single changes are easier for the agent to follow.

## Building on earlier work

**Reference earlier notebooks.** Rather than re-explaining past work, [reference the notebook](/zerve-docs/agents-in-the-workspace/giving-the-agent-context.md#referencing-notebooks) so the agent can read its code and Learnings.

**Capture what works as a skill.** When you've worked out a good way of doing something, ask the agent to turn it into a [skill](/zerve-docs/agents-in-the-workspace/skills.md) so your whole team can reuse it.

**Keep Learnings accurate.** [Learnings](/zerve-docs/agents-in-the-workspace/learnings.md) carry over between sessions. If an assumption in them is wrong, tell the agent, so it doesn't build on it.

## Checking results

**Open the notebook.** Everything the agent does is in a notebook, with real code and outputs. For any important result, look at how it was produced.

**Check the sources.** When findings come from research, check the [sources](/zerve-docs/agents-in-the-workspace/sources-and-citations.md) the agent cited.

**Ask it to review its own work.** For important work, ask Evolve Mode to have the result peer reviewed before it reports back.

## Managing credits

**Use the lightest mode and model that will do.** A quick question doesn't need Evolve Mode or high reasoning effort. See [Models and effort](/zerve-docs/agents-in-the-workspace/models-and-effort.md).

**Set a credit cap that fits.** For a big task, raise the [credit cap](/zerve-docs/agents-in-the-workspace/evolve-mode/credit-caps.md) deliberately rather than letting runs pause repeatedly; for exploratory work, keep it low.

**Pick the right compute.** Long-running or memory-hungry blocks run better on larger compute, which can also be cheaper than retrying on the wrong one. See [Compute types](/zerve-docs/compute/compute-types.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/agents-in-the-workspace/best-practices.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.