# Workspace and manifest

A workspace contains an agent and its conversations, contacts, knowledge,
secrets, and channel connections. Its deployable configuration lives in a
directory containing `vatio.yml`:

```text
support-agent/
  vatio.yml          # required
  tools/*.yml        # tools
  identity.pub       # public key that verifies your JWT (see Authentication)
```

Only create the files you need. The CLI finds the nearest `vatio.yml` at or
above the current directory and reads `workspace` to select the remote.
Deployment commands have no `--workspace` flag or `VATIO_WORKSPACE` override.
Your user credentials live separately in `~/.vatio/config.json`.

The guides below show configuration fragments. Merge them into your existing
manifest, keeping one copy of each root key and preserving the instructions
and tool assignments you still need.

## Root keys

These are the supported root keys. Unknown root keys fail validation.

| Key | Purpose |
|---|---|
| `workspace` | Remote slug: lowercase letters and digits separated by hyphens |
| `agent` | The agent definition; requires non-empty `instructions` |
| `auth` | Public key that verifies your JWT, or your Supabase project; see [Authentication](https://vatio.ai/docs/authentication/) and [Supabase](https://vatio.ai/docs/integrations/supabase) |

`business`, `widget` and `allowed_origins` — and `hours` inside `agent:` — are
still accepted but ignored: the push succeeds and prints a warning with a link.
The business name, description and opening hours are set on the
[Business](https://vatio.ai/docs/channels/inbox#business) page of the inbox, the widget's look in
**Channels → Web widget** in the inbox, and each publishable token has its own
allowed origins, edited in that page's tokens section or with
[`vatio tokens`](https://vatio.ai/docs/cli/tokens). Remove the blocks when convenient.

`knowledge` and `links` are not root keys: the agent declares its own, inside
the `agent:` block. `identity` is `auth`. `agents` and `entry` are gone: a
workspace runs one agent, under `agent:`, and private tools behind `auth:`
cover what a second, signed-in agent was for. A manifest still carrying any of
these fails the push with the migration to make.