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

# Building an agent's parts

> Every build resource follows the same six verbs. Scope calls to a project and environment, and see how playbooks, tools, functions, and variables relate.

The build endpoints create and change the parts an agent is made of: playbooks,
tools, functions, variables, and knowledge base documents. They share one shape
and one scoping rule, and the pieces relate to each other in ways worth knowing
before you write the first call.

## How the build endpoints are shaped

Every resource follows the same six-verb pattern, so learning one teaches the
rest:

| Verb     | Path                | Purpose                        |
| -------- | ------------------- | ------------------------------ |
| `GET`    | `/{resource}`       | list everything in the project |
| `POST`   | `/{resource}`       | create one                     |
| `POST`   | `/{resource}/batch` | create many in a single call   |
| `GET`    | `/{resource}/{id}`  | fetch one                      |
| `PATCH`  | `/{resource}/{id}`  | change part of one             |
| `DELETE` | `/{resource}/{id}`  | remove one                     |

The `batch` variant matters when you are importing. Creating fifty variables
one call at a time is fifty round trips and fifty chances to end up half
migrated; one batch call is atomic from your side.

## Scoping every call

Build endpoints act inside one environment of one project, so both are
required query parameters:

```bash theme={null}
curl "https://realtime-api.voiceflow.com/v1/stable/function?projectID=$VF_PROJECT_ID&environmentAlias=main" \
  -H "Authorization: Bearer $VF_PAT"
```

Editing `main` changes what your team sees in the Creator. To stage changes
without touching it, clone an environment first, build against the clone, and
[merge](/api-reference/environment/merge-environments) when you are satisfied.

## How the pieces relate

* A **playbook** is the unit of agent behaviour. It holds instructions and the
  tools it may call.
* **Tools** are what a playbook can do. An **API tool** calls an HTTP endpoint;
  a **function** runs your own code; an **MCP server** contributes a set of
  **MCP tools** discovered from that server.
* **Function paths** are the branches a function can exit through, and
  **function variables** are its inputs and outputs. Both belong to a function
  and are managed separately, so you can add a branch without rewriting the
  function.
* **Variables** are project state that persists across a conversation.
* **Knowledge base documents** are the corpus the agent retrieves from. Create
  them from a URL, from text, or by uploading a table.

## Where to go next

Once an agent is built, [publish it](/api-reference/sections/publishing) to make
the changes live, and [run a conversation](/api-reference/sections/test) against
it to see how it behaves.