> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vendo.run/llms.txt
> Use this file to discover all available pages before exploring further.
# How Vendo works
> A question goes in, your own API does the work, a screen comes back.
## The picture
Every request walks the same five boxes, in the same order.
```mermaid theme={null}
flowchart LR
U["Your user
asks in plain language"]
S["Vendo surface
sandboxed, in your brand"]
A["Agent
picks tools from tools.json"]
G["Guard
risk · approval · audit"]
P["Your API
your routes, your auth"]
U --> S --> A --> G --> P
P -. "generated UI" .-> U
classDef yours fill:#ffffff,stroke:#c9c5d6,stroke-width:1px,color:#15141b
classDef vendo fill:#f5f1ff,stroke:#ddd0ff,stroke-width:1px,color:#4a22bd
class U,P yours
class S,A,G vendo
```
Three boxes are Vendo. The two on the ends are yours.
Vendo Cloud runs the managed pieces behind those boxes: the hosted store, model gateway, sandbox, and broker.
## One request, end to end
The same five boxes, with one real turn moving through them. A user types
*"show me what I spent on travel last quarter."*
The panel sends it to a route inside **your own app** — the one file `vendo init`
wrote. It does not go to Vendo's servers.
Your own auth resolves the signed-in user. A visitor your resolver cannot place
is refused the turn.
It reads `.vendo/tools.json` and chooses `host_transactions_list` with a date
range. The prompt carries your instructions, your theme and knowledge index, the
user's messages, and the tool schemas — which model answers it, and whose
servers it runs on, is set by
[your model credential](/production/model-credentials).
A read like this one runs. Anything destructive, and anything extraction could
not grade, stops and parks the turn on an approval card showing the exact
request. Approve it and the same turn resumes.
The call reaches your own endpoint as the person who is signed in. The agent can
do what that person could already do by clicking, and nothing more.
The agent calls `vendo_make`. The screen's code runs in a WebAssembly VM that
can't touch anything — no DOM, no network, no clock — and your surface renders
what comes out, in your brand, bound to the rows your own API just returned.
## What runs where
Your repo, your API, and your auth stay on your side. Vendo Cloud runs the managed pieces.
Never leaves your side.
* your repo and code
* `.vendo/`
* your API and routes
* your auth
The pieces Vendo runs for you.
* hosted store
* model gateway
* sandbox
* broker
* sharing
### The questions everyone asks
Your own server does. Every tool call runs inside your process, through the route `init` wired. Vendo's servers never call your API and never hold your users' credentials.
The signed-in user's own headers, forwarded only to the API origin you configured. For unattended runs, a short-lived token your server mints from your own secret, naming the user who set the automation up.
Wherever your composition points them. Select a model object — `models: { default: anthropic("claude-sonnet-4-6") }`, which is what `vendo init` writes when you bring your own key — and the prompt goes straight to that provider. Vendo's servers never see it. Leave the slot unset and the `VENDO_API_KEY` in your environment answers it over Vendo's Cloud gateway. [Model credentials](/production/model-credentials) covers both.
A prompt carries your instructions, your theme and knowledge index, the user's messages, and tool schemas. The agent never sees your audit log.
Threads and audit rows live in Vendo Cloud's hosted store. Delete any of it through the erase API, which drops the rows for good.
A screen the model writes never runs in your page. Its code runs in a WebAssembly VM that can't touch anything — no DOM, no network, no clock — and your surface renders what comes out. A full generated app runs in a sandbox whose network is an allowlist: it reaches only domains you approved, one approval per domain.
Their tool calls come back through your server, under the same guard and the same approvals as a call from your own chat.
Every slot also accepts your own adapter, with no key at all. Self-hosting docs are coming.
## The pieces
Five names to know. Each one has its own group in these docs.
A sandboxed panel that renders in your brand.
Mount the surface →
Your API routes, extracted by `vendo init`.
API tools →
Risk grade, approval, audit log on every call.
Approvals →
Real screens built from your own data.
Generated apps →
Runs the store, models, sandbox, and broker.
Vendo Cloud →
## Where things live
init writes the `.vendo` folder. You paste one route.
```text your repo focus={2-4} theme={null}
├─ .vendo/
│ ├─ tools.json the API calls your agent may make
│ ├─ theme.json your fonts, colors, radii
│ └─ brief.md what your product is, in your words
└─ app/api/vendo/[...vendo]/
└─ route.ts the one route you pasted
```
Edit these by hand any time. init prints the change instead of overwriting a file you already have.
## Where to go next
Same setup so far. The code differs from here.
Vendo runs the loop and renders screens in your brand.
``
Quickstart →
Keep your loop. Vendo adds tools and renders the result.
`vendoTools(vendo)`
Quickstart →
Your own agent, acting as the signed-in user.
`createVendo({ mcp: true })`
Quickstart →