Vendo: an embedded agent that acts through your own API

The bespoke feature request Vendo is built to absorb

The README states the target plainly: Vendo is for B2B SaaS teams whose customers keep asking for bespoke features. That is a specific and familiar shape of work. A customer wants a spending view that combines their billing data with a deadline tracker. Another wants a morning reminder that chases documents across three tools. Each request is small, each one is only valuable to one account, and each one competes with roadmap work that serves everyone. The usual answers are to build it, to decline it, or to hand the customer an integration platform and let them wire it up themselves. Vendo proposes a fourth: ship an agent inside the product that the customer drives with plain language, acting through the API your application already exposes. The agent is embedded, so it is not a separate console the customer has to visit. It acts as the signed-in user, which means your existing permission model is the boundary rather than a parallel one. And the README is explicit that your source code is never touched, which is the claim that separates this from code-generation approaches that write files into your repository.

Extract, generate, guard: the three stages named in the README

The README describes three stages and they are worth taking literally because each one carries a constraint. Extract: Vendo reads your API and turns it into tools the agent executes as the signed-in user. This is the stage that determines whether the product works for you at all, and it is the stage with the least detail in the supplied material. How the API is read, and what description format produces good tools, is not specified in the README beyond the link to docs.vendo.run. Generate: the agent composes views and user-owned apps from a format-tagged UI document, and generated components run in an iframe jail with connect-src 'none'. That content security policy is the concrete mechanism. A generated component cannot open a network connection of its own; it escalates to a sandboxed server only when needed. Guard: policy, approvals, grants, breakers and audit all sit at one execution choke point, and app machines reach host tools only through the guarded tool proxy. The phrase one execution choke point matters more than it looks. It means the enforcement code is not scattered across each tool implementation, so an audit record and an approval check happen in the same place for every call. Storage is PGlite at .vendo/data as the zero-config default, with production running the same schema on Postgres.

Install commands and the agent-readable playbook

The README gives two commands for the default path: npm install @vendoai/vendo followed by npx vendo init. There is also an install route driven by a coding agent. The README supplies a canonical prompt to paste inside your app's repo, which instructs the agent to read https://vendo.run/agents.md and follow it exactly, to relay Vendo's setup questions back to you, and to ask before creating any account or key, with Vendo Cloud named as the recommended option. The stated definition of done is narrow and testable: your app runs and the agent answers from your own API. The README also mentions vendo doctor as an optional checkup, and says every code it prints links to its exact fix. The package table shows the composition options. @vendoai/vendo is the default composition and vendoai is a thin alias. @vendoai/vendo/core holds shared types, schemas, formats, validators, seams and the browser-safe app-generation contract at @vendoai/vendo/core/apps. @vendoai/vendo/ui holds headless React hooks, optional chrome, tree rendering and the in-jail component kit. The default package also carries the vendo bin plus the app-generation, sandbox, persistence, actions, telemetry, automations, knowledge, MCP-door, guard and harness blocks. The README routes four reader types to four different quickstarts: existing agent, no agent, expose over MCP, and backend-hosted agent.

The iframe jail is a real boundary, and a real limit

Generated UI running under connect-src 'none' cannot fetch anything on its own. That is a deliberate trade. The benefit is that a component produced by a language model cannot exfiltrate data or call an endpoint you did not sanction, because the browser will refuse the request before it leaves. The cost is that any generated view needing live data must go through the host, and the README says escalation to a sandboxed server happens only when needed. Every escalation is therefore a design decision someone has to make, not a default. The same pattern shows up in the approval model. The README describes standing automations where every tool is gated by approval, and the guard stage lists approvals, grants, breakers and audit together. A breaker implies that a repeatedly failing or misbehaving tool can be cut off, though the README does not give thresholds or configuration keys for it. This is where the supplied material runs thin. The README names the mechanisms but does not document their parameters, so anyone evaluating Vendo should treat the guard layer as something to verify against docs.vendo.run rather than something to assume from the README.

Where Vendo is the wrong tool

Two cases stand out. First, a product without a meaningful API surface. Vendo's entire premise is that it acts through your product's own API as the signed-in user. If the actions a customer wants are not reachable through an API call, the agent has nothing to call, and no amount of prompt engineering fixes that. Second, a team that wants generated code in its own repository. The README frames the iframe jail and the untouched source tree as features, and for a SaaS vendor protecting a codebase they are. But if your goal is to produce a component your engineers will review, refactor and commit, Vendo's model is the opposite of what you want: the artifact lives in the sandboxed surface, not in your source. There is also a maturity signal worth naming without overreading it. The repository shows no releases retrieved, so installation currently means tracking the main branch or an npm version rather than pinning to a tagged release. The README's own honesty about this is limited; it presents the install as a 60-second path without discussing version pinning.

How this differs from building on a general agent framework

The obvious alternative is to assemble the same capability from a general agent framework such as the AI SDK or Mastra and write the tool definitions yourself. The README acknowledges this path directly: the existing-agent quickstart offers one tool pack for your AI SDK, Mastra, or homegrown loop. So the difference is not agent versus no agent. It is what comes pre-built. With a general framework you write the tool schemas, build the approval flow, choose and operate the sandbox, and add the audit trail. Vendo's claim is that those pieces ship as blocks: the guard choke point, the iframe jail with its content security policy, the persistence layer, the automations, the knowledge block and the MCP door. The trade is control for assembly time. A hand-rolled loop lets you shape every tool definition and every approval rule exactly as you like. Vendo gives you a fixed shape and asks you to fit your API into it. Teams with unusual authorization models or non-HTTP action surfaces should weigh that carefully, because the guard layer assumes tools are the unit of execution.

Licence, cloud gating and what to check before you commit

The repository is Apache-2.0, which permits commercial use and modification, and the README says the open-source blocks remain self-hosted. It also states that cloud-gated sharing, publishing, org overlays and pinning activate with VENDO_API_KEY. That is the line to understand before planning a deployment: the self-hosted core and the cloud-activated features are separate concerns, and the README does not enumerate which of your intended features fall on which side. This is not legal advice; read the licence text and the docs for your own situation. On maintenance, the honest position is that the supplied material does not show a release history, so there is no evidence here about upgrade cadence or breaking-change policy. What the README does show is a commitment to a single source of truth for the agent prompt, noting that the canonical text lives in packages/vendo/src/agent-prompt.ts and is mirrored by the docs card, with the instruction to change it there first. That is a small but real signal about how the project manages drift between documentation and code. Verify the guard configuration keys, the tool-extraction format, and the cloud-gated boundary against docs.vendo.run before you size the work.

Editorial conclusion

Vendo is worth adopting if you run a B2B SaaS product with a stable, well-documented API and a steady stream of customer-specific feature requests, and if you can accept that generated apps run inside an iframe jail rather than in your source tree. It is the wrong tool if your product has no API surface for the agent to act through, or if you need generated code merged into your own repository. Before committing, run vendo doctor and read every code it prints, then confirm whether VENDO_API_KEY is required for the features you actually plan to ship, because sharing, publishing, org overlays and pinning are cloud-gated while the remaining blocks are self-hosted.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. runvendo/vendo on GitHub