What is an embedded agent?

An embedded agent is an AI agent that lives inside another company’s product and acts through that product’s own API as the signed-in user. It does not answer questions about the product from the outside. It operates the product: reading the data the customer can already see, calling the endpoints they can already call, and rendering the result as working UI in the product’s own design.

How is an embedded agent different from a chatbot?

A chatbot talks about your product; an embedded agent operates it. A chatbot’s output is text, and the customer still has to go do the work. An embedded agent’s output is the work: a view that did not exist an hour ago, a record updated through your API, an automation that runs every Monday morning. If the agent can only tell your customer which button to press, it is not embedded.

How is an embedded agent different from a copilot?

A copilot helps your customer finish the tasks you already shipped; an embedded agent lets them build the task you never shipped. Copilots are scoped to features on the roadmap: summarize this thread, draft this reply, fill in this form. An embedded agent is scoped to your API, so the ceiling is what your product can do, not what your UI exposes today.

What does it take to build one?

Three hard parts, and none of them is the model: authority, surface, and guardrails. The agent has to act as the customer without borrowing more power than that customer has. It needs somewhere safe to render code it wrote seconds ago. And every action it takes needs one place to be checked, approved, and logged. The rest of this page takes them in order.

How should an embedded agent act on the customer’s behalf?

Through your existing API, with the signed-in customer’s identity, and no authority of its own. In practice that means the agent’s tools are generated from endpoints you already ship, and every call carries that customer’s session, so nobody can reach data or actions they could not reach by clicking. The shortcut people reach for instead is a service account with broad access and a prompt telling the model to behave, which turns every permission rule in your product into a suggestion.

Why does generated UI have to be sandboxed?

Because UI written at runtime is untrusted code, even when your own agent wrote it. Generated components belong in an isolated frame that cannot open network connections of its own, so a bad or manipulated generation cannot leak a session or call out to a third party. The sandbox is also what makes the output feel native: inside it the agent composes the components you registered, so what your customer gets looks like your product instead of a generic AI panel.

What guardrails does an embedded agent need?

One choke point that every tool call passes through, carrying policy, approvals, per-tool grants, breakers, and an append-only audit log. Checks spread across handlers drift apart; a single execution point does not. Two rules make it real: anything irreversible stops and asks a human, and every call the agent made is answerable from a log rather than reconstructed after the fact.

Who needs an embedded agent?

Products whose customers keep asking for features that only make sense for one of them. The pattern earns its keep when your backlog fills with requests that are real but unshippable: the report three accounts want, the workflow that matches one team’s process, the integration that unblocks a single renewal. Those requests never stop, and building them one at a time is how a product team turns into a services team. That problem, and the alternatives teams try first, is the subject of letting your customers customize your product.

How does Vendo implement an embedded agent?

Vendo is this pattern shipped as an npm package. An open-source customization layer. Your users build their own features and micro-apps, right on top of your product.

• Install and wire. npm install @vendoai/vendo, then npx vendo init scans your app and proposes the wiring as permission-gated diffs. vendo doctor checks the result, and every error code links to its exact fix.
• Act as the customer. Vendo extracts your OpenAPI, tRPC, GraphQL, Next.js server actions, and host routes into tools the agent executes as the signed-in user.
• Render in your brand. Generated apps compose the host components you register and run in an iframe jail with connect-src 'none', escalating to a sandboxed server only when they need one. Your theme is extracted from the repo, so the surfaces match the product.
• Guard every call. Policy, approvals, grants, breakers, and audit sit at one execution choke point, and app machines reach host tools only through the guarded tool proxy.
• Keep it running. Automations fire on cron schedules, host events, or verified external webhooks with app-bound grants. PGlite at .vendo/data is the zero-config store; production runs the same schema on Postgres.
• Own it. Apache-2.0. Vendo Cloud adds hosted sharing, publishing, org overlays, and pinning when you set VENDO_API_KEY; the open-source blocks stay self-hosted either way.

vendo initruns nightly against 16 real open-source apps, so the install path is tested on other people’s code, not only ours.

Where do you start?

Run npx vendo init in your app, or read the quickstart first: it is one command and one component. The home page shows an agent assembling an app in place, and pricing lists what each plan includes, with a bring-your-own path on every meter.