> ## Documentation Index
> Fetch the complete documentation index at: https://vendo-mintlify-24213046.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# How the panel works
> One question in the panel, end to end: your route, your identity, your API, and the screen that streams back.
The panel is the only Vendo code in your browser. Every turn goes to a route
inside your own app and streams back to that panel.
## The path of one question
The panel sends `POST /api/vendo/threads` and reads the reply as a stream.
`baseUrl` on the provider decides that path. The body carries the question and
a snapshot of what the user is looking at, and nothing else leaves the browser.
`vendo init` writes two files, both ordinary source you can read and change: a
composition module that calls `createVendo`, and a thin route that serves it.
```ts lib/vendo.ts theme={null}
import { clerk } from "@vendoai/vendo/auth/clerk";
import { createVendo, guard } from "@vendoai/vendo/server";
export const vendo = createVendo({
auth: clerk(),
guard: guard({ policy: {} }),
});
```
```ts app/api/vendo/[...vendo]/route.ts theme={null}
import { nextVendoHandler } from "@vendoai/vendo/server";
import { vendo } from "@/lib/vendo";
export const { GET, POST, PUT, PATCH, DELETE } = nextVendoHandler(vendo);
```
`auth` is the one key everything identity-shaped hangs off. Init detects Auth.js,
Clerk, Supabase, or Auth0 and writes the matching preset there, or the same
object with a `principal` for you to fill in when it finds no library. Vendo
mints no identity of its own, so a visitor your resolver cannot place is refused
the turn.
The harness runs the loop in your own process, and its tools are your API
(extracted into `.vendo/tools.json` by `vendo init`, refreshed by `vendo sync`)
plus Vendo's own tools for building screens. `VENDO_API_KEY` answers the model
over the Vendo Cloud gateway, and a `models:` selection sends the call to your
own provider instead. [Model credentials](/production/model-credentials) has both.
Every tool call passes the guard before it runs. Reads and writes run;
destructive calls, and anything sync could not grade, park the turn on an
approval card showing the exact request, and approving it resumes that same
turn. The decision is server-side, and [approvals](/howto/approvals) has the
rules.
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.
When the answer is one to look at, the agent calls `vendo_make` and Vendo
assembles a screen — or, with the person's yes, builds a small app once in a
disposable Cloud sandbox and seals the result. It streams into the transcript
as it forms and lands interactive, bound to live data from your own tools,
ready to pin into a
[`VendoSlot`](/product/mount-the-surface#slots) on your page.
## What runs where
| Piece | Where it runs |
| ----------------------------- | ------------------------------------------------------------------------------------------------ |
| Panel, slots | Your browser, out of your own bundle |
| The route and the composition | Your server, in your process |
| Your API and your database | Yours, untouched |
| The model | The Vendo Cloud gateway keyed by `VENDO_API_KEY`, or your own provider when `models` selects one |
| Threads, apps, grants, audit | Hosted Postgres behind the same key |
| Building a generated app | A disposable Cloud sandbox behind the same key |
One key fills the model, store, and sandbox slots your composition left unset —
nothing to provision, and nothing to run.
## What the agent can see
Each send carries a small `[Context]` bundle for that turn only.
* The accessibility tree of the visible page, with the URL and title on top,
capped at 8 KB.
* Anything you publish yourself with [`useVendoContext`](/customize/context).
* It rides the request and never enters the transcript.
* Elements marked `data-vendo-ignore` are left out, and
`captureScreen={false}` on the provider turns the page snapshot off entirely.