;
};
You already have an agent: its own loop, its own model, its own chat UI.
Vendo does not replace any of it. One tool pack, spread into your agent's
tools, adds guarded host actions, generated UI, and approvals to the loop
you already run. Start with your framework's quickstart:
`vendo init`, one spread into `streamText`, one embed component.
The same three steps in Mastra's `Agent({ tools })` shape.
The pack adds three things:
1. **Guarded tools.** Your host actions and connected-account tools, with
every call routed through policy, approval, and audit. The pack wraps the
same guard-bound registry Vendo's own loop uses, so no tool reachable from
your loop has an unguarded route.
2. **Generated UI in your chat.** A `vendo_create_app` tool builds live,
interactive apps that render inline in your own chat surface via embed
components.
3. **Vendo as a delegate.** A `vendo_delegate` tool hands Vendo's agent a
whole task and returns the run report.
## The composition
You run `createVendo` and mount the wire route exactly as the
[quickstart](/quickstart) describes. What you drop is Vendo's chat loop and
chat UI. The wire keeps serving apps, approvals, and connected accounts to
the embeds: Vendo minus the conversation.
```ts theme={null}
// lib/vendo.ts: the same composition as any Vendo host
import { createVendo } from "@vendoai/vendo/server";
import { serverActions } from "./vendo-actions";
export const vendo = createVendo({
policy: "cautious",
serverActions, // the map vendo init generates from your host actions
});
```
Then build the tool pack per framework and spread it into your agent:
* `@vendoai/vendo/ai-sdk` exports `vendoTools(vendo, { principal })`, an
AI SDK `ToolSet` for `streamText` and `generateText`. Built per request,
because tool execution needs a principal-scoped context.
* `@vendoai/vendo/mastra` exports `vendoMastraTools(vendo)`, the same pack in
Mastra `createTool` shape for `Agent({ tools })`. Mastra agent definitions
are static, so the caller's principal resolves per call from Mastra's
request context instead.
Both return a Promise. Both are thin format shims over one framework-neutral
tool pack, so the semantics below hold for either.
## The tool pack
Every pack tool is namespaced `vendo_*` to avoid collisions with your own
tools. A registered host action `host_x` ships as `vendo_host_x`; two
built-ins are already prefixed:
| Tool | What it does |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `vendo_` | one per registered host action, guard-wrapped per call |
| `vendo_create_app` | generates UI; returns fast with an app ref while the build streams over the wire, so your loop never blocks on generation |
| `vendo_delegate` | hands Vendo's own agent a whole task via the runner seam; returns `{ status, summary, refs }` |
`include` and `exclude` filter the pack by final (namespaced) tool name,
exact match. `include` unset means the whole pack; `exclude` wins over
`include`.
## Approvals in your loop
A guarded call that needs approval does not throw and does not block your
loop. The tool returns the approval-ref envelope immediately, so your model
sees "pending, the user must approve in the UI". The pending call parks
server-side. When the user approves in ``, the wire
executes the parked call and the embed resolves in place to the executed
result. Deny resolves it to "declined" and discards the parked call.
Parked calls expire on a TTL sweep, 60 minutes by default. Tune it with
`createVendo({ approvals: { parkedCallTtlMs } })`; `0` disables expiry. An
expired call resolves the embed to "expired" and never runs.
Your agent learns the outcome on a later turn if it matters. This is the
same eventual consistency Vendo's own thread uses for abandoned approvals,
in a new venue.
See [Embeds and envelopes](/existing-agents/embeds) for the envelope
contract and the three `@vendoai/ui` embed components that render it inside
your own chat.
## Two models, deliberately
Your agent keeps its own model. Vendo's `model` seam still powers app
generation and the delegate: an explicit `createVendo({ model })` wins, and
when you omit it Vendo resolves one through the
[dev-mode credential ladder](/connect/dev-mode). In the common case that
means zero extra model config.
## In-process vs. the MCP door
This seam is for your own agent running in your own backend, in process
with `createVendo`. If you want third-party agents (Claude, ChatGPT,
Cursor) to reach your product from outside, that is the
[MCP door](/capabilities/mcp).