#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:
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 and 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 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. 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.